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

On 10/27/11 4:55 AM, Magnus Westerlund wrote:
> On 2011-10-25 20:01, Hadriel Kaplan wrote:
>>
>> 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.
>>
>
> That is much better. I think the only "controversial" from my
> perspective is the "ignore" part. It is clearly an error.

Yeah. Normally we don't specify the behavior in error cases.
Doing a behavior is recommended that allows things to proceed in a 
useful way, it is in effect "allowing" the error.

(Specifying *which* error to report, when there is a choice, seems 
reasonable.)

	Thanks,
	Paul

> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>