Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16

[Hadriel Kaplan <[e-mail]>]

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?

How about this:
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.  When receiving an SDP Offer or Answer, if "recvonly" or "sendonly" is indicated for loopback, the SDP-receiving agent MAY treat it as a failure of the loopback negotiation or ignore the direction attribute. 

[This last sentence is probably controversial?]

-hadriel