Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Section 5.2.2 (Subsequent Offers) says:
>
>    o  If a m= section was rejected, i.e. has had its port set to zero in
>       either the local or remote description, it MUST remain rejected
>       and have a zero port in the new offer, as indicated in RFC3264,
>       Section 5.1.
>
> That 3264 reference is to a section about the initial offer, and so is
> irrelevant to the case. The relevant section is:
>
>    8.1 Adding a Media Stream
>
>    New media streams are created by new additional media descriptions
>    below the existing ones, or by reusing the "slot" used by an old
>    media stream which had been disabled by setting its port to zero.
>
> IOW, previously rejected m-lines may be recycled.
>

Right you are.

>
> Later in 5.2.2:
>
>    o  If a m= section exists in the current local description, but has
>       its state set to inactive or recvonly, and a new MediaStreamTrack
>       is added, the previously existing m= section MUST be recycled
>       instead of creating a new m= section.  [OPEN ISSUE: Nail down
>       exactly what this means.  Should the codecs remain the same?
>       (No.)  Should ICE restart?  (No.)  Can the "a=mid" attribute be
>       changed?  (Yes?)]
>
> This seems to assume that there is no existing MediaStreamTrack for these
> m-lines.
>
> Yes. The text should state that more clearly.

> If there is, then
> - the m-line shouldn't be recycled.
> If there isn't, then
> - where do its address and port come from?
> - what is managing the RTCP?
>

The m= section will still have completed ICE negotiation, despite being
marked as inactive. So the address/port information should already be
present.

I don't follow your question about who is managing RTCP.

>
>         Thanks,
>         Paul
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>