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

[Nathan Stratton <[e-mail]>]

Looks good.

Sent from my iPhone

On Nov 21, 2011, at 1:05 PM, Hadriel Kaplan <[e-mail]> wrote:

> 
> 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?