Re: [rtcweb] [MMUSIC] Is bundle just a port override?

["Mo Zanaty (mzanaty)" <[e-mail]>]

Hi Emil,

Those drafts use the SDP grouping framework (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity and ambiguity for something which can be solved in a much simpler and clearer way with a single attribute: a=port <port>. (Or, if we want to warn humans about RTP muxing, then name it a=rtp-mux:<port>, but machines won't care about the name, and their RTP implementations already know how to deal with muxing if they use this attribute, so stronger warnings are unnecessary.)

Regarding the concern about non-use of the discarded RTP ports confusing SBCs, see this part of my original message [with clarifications], which is what the current bundle draft also suggests:

> Either end can re-offer without lies about ports on the m-line after
> confirming the peer is not confused by muxing, if they want to avoid
> confusing intermediaries [that may monitor the unused ports].

To summarize the (long) history of RTP mux / bundle problems and solutions:

1. We want to multiplex everything on one port: audio/video/RTP/RTCP/SCTP.

2. But we hit a red light in RTP, which says we SHOULD NOT multiplex on the same port using PT/SSRC, so drafts were written to relax the restrictions. (Note that RFC 3550 RTP also says MUST NOT multiplex RTP and RTCP, so RFC 5761 a=rtcp-mux was written. We should continue to remove obsolete and unnecessary restrictions in old specs.)

3. With a green light from RTP, we now turn to SDP to signal the same port on multiple m-lines.

4. We hit a red light in SDP since this is technically undefined behavior, so we fear legacy peers or intermediaries will choke on it.

5. We lie about our desired ports on the m-line, using unique ports to avoid confusing legacy peers or intermediaries.

6. We signal our truly desired ports in some way outside the m-line.

7. If the peer understands 6, it signals back in some way, and we think we're good to mux.

8. We hit a red light in intermediaries that monitor ports but don't understand 6/7, so we re-offer with the actually used ports (not lies) in the m-line to avoid confusing them.

I'm just asking why 6/7 decided to use complex grouping semantics instead of a simple attribute. Was a simple port override attribute already considered and dismissed? Or just overlooked?

Cheers,
Mo

-----Original Message-----
From: Emil Ivov [mailto:[e-mail]] 
Sent: Tuesday, March 19, 2013 1:03 PM
To: Mo Zanaty (mzanaty)
Cc: Harald Alvestrand; [e-mail]; [e-mail]
Subject: Re: [MMUSIC] Is bundle just a port override?

Hey Mo,

On 19.03.13, 16:28, Mo Zanaty (mzanaty) wrote:
> I understand the RTP session rules, but they are a matter for AVTCORE,
> and several drafts already detail the RTP considerations for
> multiplexing streams, of potentially different media types, over the
> same port (using plain RTP not SHIM). Bundle does not need to solve that
> (solved) problem, it just needs to signal which port(s) to use. If we
> feel we should signal some sort of human-level warning about RTP mux
> rules when signaling ports, the attribute can be named a=rtp-mux:<port>
> instead of a=port <port>.
> 
>  
> 
> I don't see how any grouping semantics help with any of the rules.
> Actually, I think grouping semantics hurt, not just due to complexity,
> but also due to ambiguity about which attributes are inherited or
> overridden from other m-blocks. Keeping all the m-block attributes
> independent seems simpler and clearer. If an attribute needs to be
> consistent across m-blocks, repeating it seems simpler and clearer than
> inheritance/override rules across m-blocks. (Of course, if all m-blocks
> need the same attribute, it can be defined at session level instead of
> repeating in all media levels.)
> 
>  
> 
> In my simple (perhaps too simple) mind, all we're trying to do in bundle
> is temporarily lie on the m-line port to avoid confusing
> peers/intermediaries. In the process, I think we have confused ourselves
> about what is truly needed to accomplish this deception. Or maybe I'm
> the only one confused...

In your original mail you seemed to be suggesting something similar to:

http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-00

(Sometimes referred to Cundle for Cullen's Bundle)

or this

http://tools.ietf.org/html/draft-alvestrand-one-rtp-01

(Also known as One RTP)

Both would start by offering multiple ports and fall back to a single
port if bundling is supported.

The concern that has been expressed with them is that in case of
bundling, non-use of the discarded RTP ports would cause some SBCs to
believe that there's a problem with the session which may lead to the
SBC tearing down the call.

Hope this helps,
Emil

> 
>  
> 
> Mo
> 
>  
> 
> *From:*Harald Alvestrand [mailto:[e-mail]]
> *Sent:* Tuesday, March 19, 2013 5:03 AM
> *To:* Mo Zanaty (mzanaty)
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [MMUSIC] Is bundle just a port override?
> 
>  
> 
> On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
> 
>     Does bundle imply anything beyond a simple port override of the
>     m-line port? If not, then why not just directly signal the port
>     override in an attribute without any grouping semantics?
> 
> 
> No, it's not just a port override.
> 
> BUNDLE shoves things into the same RTP session, which means that one has
> to obey the rules for being in the same RTP session:
> - Security done consistently
> - RTCP-mux done consistently
> - No SSRC collision
> - No payload type collision
> So it's a good deal more than just a port override.
> 
> Magnus argued in favour of a solution that inserted a multiplex layer,
> so that one could use the same ports but still have stuff in different
> RTP sessions, but that did not appeal to many.
> 
> 
>  
> 
> Offer to mux audio and video on the same port:
> 
> m=audio 10000 RTP/AVP 0
> 
> m=video 10002 RTP/AVP 31
> 
> a=port 10000
> 
> i=I really want 10000, but lied on the m-line for fear of confusing you.
> Confused yet?
> 
>  
> 
> Answer supports the port override attribute and agrees to mux audio and
> video:
> 
> m=audio 40000 RTP/AVP 0
> 
> m=video 40000 RTP/AVP 31
> 
> a=port 40000
> 
> ...so audio and video ports are 10000<->40000.
> 
>  
> 
> Answer supports the port override attribute but doesn't want to demux on
> his end:
> 
> m=audio 40000 RTP/AVP 0
> 
> m=video 40002 RTP/AVP 31
> 
> a=port 40002
> 
> ...so audio ports are 10000<->40000 and video ports are 10000<->40002.
> 
>  
> 
> Answer doesn't support the port override attribute, or doesn't want
> either end to mux:
> 
> m=audio 40000 RTP/AVP 0
> 
> m=video 40002 RTP/AVP 31
> 
> ...so audio ports are 10000<->40000 and video ports are 10002<->40002.
> 
>  
> 
> Either end can re-offer without lies about ports on the m-line after
> confirming the peer is not confused by muxing, if they want to avoid
> confusing intermediaries.
> 
>  
> 
> Has this approach been tried yet? Dismissed?
> 
>  
> 
> Mo
> 
>  
> 
> 
> 
> 
> _______________________________________________
> 
> mmusic mailing list
> 
> [e-mail] <mailto:[e-mail]>
> 
> https://www.ietf.org/mailman/listinfo/mmusic
> 
>  
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org