Muthu ArulMozhi Perumal (mperumal) wrote:
> These look good to me and flexible enough to also request a transcoder
> to loopback a media stream. 
> 
> However, the RTP port numbers advertised by the source/mirror for the
> in/out and from/to media stream pairs would typically be the same. Is it
> legal/safe to pair m-lines that use the same IP address and port?

That's a mistake in my examples. It should be as follows:

If the same format is used for the source and the mirror, then there 
will be only one m-line used bidirectionally. In case where different 
formats are used in the two directions, then different ports should be used.

> RFC3388 (section 7.5.3) forbids such an usage for the Flow
> Identification (FID) group:
> 
> <snip>
>    FID MUST NOT be used to group "m" lines with the same 
>    IP address/port. Therefore, an SDP like the one below MUST NOT
>    be generated.
> 
>        v=0
>        o=Laura 289083124 289083124 IN IP4 six.example.com
>        t=0 0
>        c=IN IP4 131.160.1.112
>        a=group:FID 1 2
>        m=audio 30000 RTP/AVP 0
>        a=mid:1
>        m=audio 30000 RTP/AVP 8
>        a=mid:2
> 
>    The correct SDP for the session above would be the following one:
> 
>        v=0
>        o=Laura 289083124 289083124 IN IP4 six.example.com
>        t=0 0
>        c=IN IP4 131.160.1.112
>        m=audio 30000 RTP/AVP 0 8
> 
>    If two "m" lines are grouped using FID they MUST differ in their
>    transport addresses (i.e., IP address plus port).
> </snip>
> 
> Not sure, if this is applicable only to FID or there are generic SDP
> grouping/paring issue.
> 
> If this is legal, can't the directionality be derived based on
> sendonly/recvonly, instead of having to explicitly specify in/out or
> from/out?

I thought about that. It *can* be derived that way in some cases. Cases 
where it cannot are when the offerer is willing to be either the source 
or the mirror. In that case it must make both streams sendrecv.

	Thanks,
	Paul

> Offer:
>    m=audio 41352 RTP/AVP 0 8
>    a=loopback:source x
>    a=sendonly
>    m=audio 41352 RTP/AVP 112
>    a=loopback:source x
>    a=rtpmap:112 encaprtp/8000
>    a=recvonly
>    m=video 41362 RTP/AVP 116
>    a=loopback:source y
>    a=rtpmap:116 videostuff...
>    a=sendonly
>    m=video 41362 RTP/AVP 118
>    a=loopback:source y
>    a=rtpmap:118 encaprtp/8000
>    a=recvonly
> 
> Answer:
>    m=audio 54312 RTP/AVP 0
>    a=loopback:mirror x
>    a=recvonly
>    m=audio 54312 RTP/AVP 112
>    a=loopback:mirror x
>    a=rtpmap:112 encaprtp/8000
>    a=sendonly
>    m=video 51362 RTP/AVP 116
>    a=loopback:mirror y
>    a=rtpmap:116 videostuff...
>    a=recvonly
>    m=video 51362 RTP/AVP 118
>    a=loopback:mirror y
>    a=rtpmap:118 encaprtp/8000
>    a=sendonly
> 
> thanks,
> Muthu
> 
> |-----Original Message-----
> |From: Paul Kyzivat (pkyzivat)
> |Sent: Friday, April 30, 2010 7:57 PM
> |To: Muthu ArulMozhi Perumal (mperumal)
> |Cc: Paul E. Jones; kaynam.hedayat@exfo.com; mmusic@ietf.org
> |Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
> |
> |
> |Muthu ArulMozhi Perumal (mperumal) wrote:
> |> Paul,
> |>
> |> |So maybe the answer here is to always include both the "real"
> formats
> |> |*and* the encapulated formats in both the offer and the answer,
> while
> |> |using the loopback-source and loopback-mirror to determine who uses
> |> what.
> |>
> |> Are you proposing something like this?
> |>
> |> Offer:
> |>     m=audio 49170 RTP/AVP 0 112
> |>     a=loopback:rtp-pkt-loopback
> |>     a=loopback-source
> |>     a=rtpmap:0 pcum/8000
> |>     a=rtpmap:112 encaprtp/8000
> |>
> |> Answer:
> |>     m=audio 49170 RTP/AVP 0 112
> |>     a=loopback:rtp-pkt-loopback
> |>     a=loopback-mirror
> |>     a=rtpmap:0 pcum/8000
> |>     a=rtpmap:112 encaprtp/8000
> |>
> |> This looks good, except that I am wondering what will happen if the
> |> answerer doesn't support media loopback and hence doesn't understand
> the
> |> "encaprtp" encoding name. What will be the behavior if such an
> answerer
> |> is:
> |> 1) UA
> |> 2) SBC
> |
> |While putting both in "works" techically, it requires the mirror to lie
> |by claiming it is willing to receive the encapsulated format when it is
> |really only willing to send it.
> |
> |A more o/a friendly way of doing this would be:
> |
> |Offer:
> |   m=audio 41352 RTP/AVP 0 8
> |   a=loopback:source-out x
> |   m=audio 41354 RTP/AVP 112
> |   a=loopback:source-in x
> |   a=rtpmap:112 rtploopback/8000
> |
> |Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:mirror-in x
> |   m=audio 54320 RTP/AVP 112
> |   a=loopback:mirror-out x
> |   a=rtpmap:112 rtploopback/8000
> |
> |Above is just a thought off the top of my head, and carefully
> |considered. There are many changes implied in the above compared to the
> |current draft:
> |
> |- a stream to be looped can be represented by two m-lines,
> |   one for the input side and one for the output side.
> |
> |- there is no loopback-source/loopback-mirror
> |
> |- a=loopback indicates:
> |   - the role of the message sender (source or mirror)
> |   - the direction of the stream (in/out)
> |   - an identifier used to pair the two streams
> |
> |- There is no *explicit* distinction between packet and media
> |   loopback. Its implicit in the pairing of two streams and
> |   the formats that they contain. This pairing could also
> |   be used to request transcoding between regular formats.
> |   (Packet loopback can be viewed as just a special kind
> |   of transcoder.)
> |
> |In the case of media loopback without transcoding, you typically won't
> |need two m-lines. So in that case it gets simpler:
> |
> |Offer:
> |   m=audio 41352 RTP/AVP 0 8
> |   a=loopback:source
> |
> |Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:mirror
> |
> |In above, lack of in/out means both. And then the identifier to match
> |streams isn't needed.
> |
> |Another variant can handle case where choice of who to mirror is
> negotiated:
> |
> |Offer:
> |   m=audio 41352 RTP/AVP 0 8
> |   a=loopback:source/mirror
> |
> |Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:mirror
> |
> |Alternative Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:source
> |
> |If two streams are desired but mirroring is to be negotiated, then
> there
> |is need to select what formats are to be transcoded to what:
> |
> |Offer:
> |   m=audio 41352 RTP/AVP 0 8
> |   a=loopback:from x
> |   m=audio 41354 RTP/AVP 112
> |   a=loopback:to x
> |   a=rtpmap:112 rtploopback/8000
> |
> |Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:mirror-in x
> |   m=audio 54320 RTP/AVP 112
> |   a=loopback:mirror-out x
> |   a=rtpmap:112 rtploopback/8000
> |
> |Alternate Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:source-out x
> |   m=audio 54320 RTP/AVP 112
> |   a=loopback:source-in x
> |   a=rtpmap:112 rtploopback/8000
> |
> |Here is a more comprehensive example:
> |
> |Offer:
> |   m=audio 41352 RTP/AVP 0 8
> |   a=loopback:source-out x
> |   a=sendonly
> |   m=audio 41354 RTP/AVP 112
> |   a=loopback:source-in x
> |   a=rtpmap:112 rtploopback/8000
> |   a=recvonly
> |   m=video 41362 RTP/AVP 116
> |   a=loopback:from y
> |   a=rtpmap:116 videostuff...
> |   a=sendrecv
> |   m=video 41364 RTP/AVP 118
> |   a=loopback:to y
> |   a=rtpmap:112 rtploopback/8000
> |   a=sendrecv
> |
> |Answer:
> |   m=audio 54312 RTP/AVP 8
> |   a=loopback:mirror-in x
> |   a=recvonly
> |   m=audio 54320 RTP/AVP 112
> |   a=loopback:mirror-out x
> |   a=rtpmap:112 rtploopback/8000
> |   a=sendonly
> |   m=video 54382 RTP/AVP 120
> |   a=loopback:mirror-in y
> |   a=rtpmap:120 videostuff...
> |   a=recvonly
> |   m=video 54384 RTP/AVP 118
> |   a=loopback:mirror-out y
> |   a=rtpmap:112 rtploopback/8000
> |   a=sendonly
> 
>