Re: [MMUSIC] Difficulties accepting and rejecting with bundling

The direction attribute is one that needs to be preserved for each m line to indicate direction of the media associated with that m line.  It is just not available for other purposes.  Furthermore, inactive does not disable ICE or RTCP, which would still be expected to proceed.

From: Suhas Nandakumar [mailto:suhasietf@gmail.com]
Sent: Wednesday, March 13, 2013 2:38 PM
To: Dale R. Worley
Cc: Ejzak, Richard P (Richard); mmusic@ietf.org
Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling

I am just curios ... instead of playing with connection address and port numbers for indicating accepting/rejecting a m=line in BUNDLE O/A, would making a particular m=line direction inactive make things simpler ....
since for m=lines with direction as inactive would mean no ICE setup , no reject port needed , no resource allocation on intermediary(?)

Any thoughts ?

./Suhas
On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley <worley@ariadne.com<mailto:worley@ariadne.com>> wrote:
> From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com<mailto:richard.ejzak@alcatel-lucent.com>>
>
> This is the only compatibility concern identified with the
> asymmetric use of the unspecified address, but this concern is
> clearly misplaced for rtcweb applications where ICE and consent are
> mandatory.
I'm not limiting my attention to WebRTC only.  Even in situations
where WebRTC is gatewayed to existing SIP infrastructure these
problems appear.  If we restrict ourselves to WebRTC, then we have
even more freedom, and in that case, I'd simply remove the rule
regarding rejects MDs as members of groups.

Dale
_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic