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

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

Mo

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Tuesday, March 19, 2013 5:03 AM
To: Mo Zanaty (mzanaty)
Cc: mmusic@ietf.org; rtcweb@ietf.org
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

mmusic@ietf.org<mailto:mmusic@ietf.org>

https://www.ietf.org/mailman/listinfo/mmusic