[MMUSIC] Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16

[Hadriel Kaplan <[e-mail]>]

With regards to issue #11 on the media-loopback draft, the consensus on the mailing list so far appears to be ok with the following text:

"Since media loopback requires bidirectional RTP, its normal direction mode is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or not, as per section 5.1 of [RFC3264], since it is implied by default. If either the loopback source or mirror wish to disable loopback use during a session, the direction attribute "inactive" MUST be used as per [RFC3264].  The direction mode attributes "recvonly" and "sendonly" are incompatible with the loopback mechanism and MUST NOT be indicated when generating an SDP Offer or Answer."

Does anyone object to the above text?

-hadriel


On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote:

> 11. Section 5.3
> "    Note: A loopback offer in a given media description MUST NOT
>    contain the standard mode attributes sendonly, recvonly, sendrecv,
>    or inactive. The loopback-mode attributes (loopback-source and
>    loopback-mirror) replace the standard attributes."
> 
> This appears to be a strange MUST NOT which I think might encounter
> issues. Considering that SIP proxies that looks into this SDP requires
> the direction attribute to be present and adds it, what happens now.
> And why isn't sendrecv and inactive possible values? sendrecv appears to
> be requried for loopback to work, and inactive would put media transport
> in an established session on hold. Isn't that reasonable?