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

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 19 Mar 2013 04:19:06 +0000

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?

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Mar 2013 10:03:10 +0100

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.

> 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.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 19 Mar 2013 15:28:48 +0000

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:[email-masked]]
Sent: Tuesday, March 19, 2013 5:03 AM
To: Mo Zanaty (mzanaty)
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Is bundle 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:

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.

Mo

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 19 Mar 2013 18:02:59 +0100

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:[email-masked]]
> *Sent:* Tuesday, March 19, 2013 5:03 AM
> *To:* Mo Zanaty (mzanaty)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [MMUSIC] Is bundle just a port override?
> 
>  
> 
>     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?
> 
> 
> …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.
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> 

-- 
https://jitsi.org

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 19 Mar 2013 18:43:52 +0000

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:

> 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:[email-masked]] 
Sent: Tuesday, March 19, 2013 1:03 PM
To: Mo Zanaty (mzanaty)
Cc: Harald Alvestrand; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Is bundle just a port override?

Hey Mo,

On 19.03.13, 16:28, Mo Zanaty (mzanaty) wrote:
> I don't see how any grouping semantics help with any of the rules.
> In my simple (perhaps too simple) mind, all we're trying to do in bundle
> about what is truly needed to accomplish this deception. Or maybe I'm
> the only one confused...

or this

(Also known as One RTP)

Hope this helps,
Emil

-- 
https://jitsi.org

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 19 Mar 2013 15:36:46 -0400 (EDT)

> From: "Mo Zanaty (mzanaty)" <[email-masked]>
> 
> 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:
> 

It's messier than that, unfortunately.

One requirement is that after negotiation is completed, the negotiated
transport associations (as seen by a legacy intermediary) must match
the actual media flows.

Another requirement is that two media descriptions shouldn't use the
same port (because a lot of legacy SBCs can't handle that).  This
applies to offer/answer updates as well as original offers/answers.

So what we want is a way for a media description to say, "I'm
reporting port zero so SBCs think this MD is rejected, but I'm
actually using port 1234 (which is officially reported in another
MD)."

There are also situations where the we want to signal perferences as
to which media descriptions share ports with which other media
descriptions.

Dale

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Mar 2013 23:19:54 +0100

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

To me, what you're describing is a grouping (the ports with the same 
a=rtp-mux:port attribute form a single RTP session), so it seems to me 
that using the grouping framework and using matching a=rtp-mux:port 
attribute have exactly the same level of complexity - but in the case of 
a=rtp-mux:port, you lose the ability to use ICE attributes to negotiate 
the actual ports, addresses and network interfaces actually used - so 
the a=rtp-mux:port mechanism will actually turn out to be *more* complex 
than the grouping framework once you've added all the other features you 
need to take advantage of ICE and so on.

So - after I've thought about it for a while - I think calling it a 
"port override" is not just misleading, the implementation you're 
suggesting will be more complex than using the grouping framework.

Why invent square wheels when the pentagonal ones are doing just fine?

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 21 Mar 2013 04:43:27 +0000

Hi Dale,

In your draft (and Richard's), I understand your motivation to answer with port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that sniff ports so they don't smell anything fishy. I won't comment on whether they will react better to nostril-plugging than fishy smells, because I don't know, but that is orthogonal to what I'm describing here.

Your bundle alternatives (and Richard's) also work fine with a simple attribute without complex grouping semantics.

Answer supports the port override attribute and agrees to mux audio and video:
m=audio 40000 RTP/AVP 0
m=video 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
a=port 40000
...so audio and video ports are 10000<->40000.
 
Answer doesn't support the port override attribute, or doesn't want 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.

Cheers,
Mo

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 3:37 PM
To: Mo Zanaty (mzanaty)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

Dale

---

From: Justin Uberti <[email-masked]>
Date: Wed, 20 Mar 2013 22:11:12 -0700

The point of the different ports is not just to make intermediaries happy,
but to ensure that we're successful when talking to an endpoint who doesn't
support BUNDLE. There are a litany of problems that have been identified
when the same ports are used on the offerer side and the answerer is
BUNDLE-unaware.

On Wed, Mar 20, 2013 at 9:43 PM, Mo Zanaty (mzanaty) <[email-masked]>wrote:

> Hi Dale,
>
> In your draft (and Richard's), I understand your motivation to answer with
> port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that sniff
> ports so they don't smell anything fishy. I won't comment on whether they
> will react better to nostril-plugging than fishy smells, because I don't
> know, but that is orthogonal to what I'm describing here.
>
> Your bundle alternatives (and Richard's) also work fine with a simple
> attribute without complex grouping semantics.
>
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 21 Mar 2013 05:59:35 +0000

Hi Harald,

You're right, both are essentially groupings, and all of our wheels have ugly angles. To me, the ugly angles in bundle are unnecessary indirection by grouping with artificial bindings (mid), and that it pretends to be more than it is. To me, it is just a port override, but with unnecessary indirection. Why not just say the port you want to use directly?

m=audio 10000 RTP/AVP 0
m=video 10002 RTP/AVP 31
a=port 10000

vs.

a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0
a=mid:foo
m=video 10002 RTP/AVP 31
a=mid:bar

Why is the direct approach more complex? Why is ICE any different in either approach?

Cheers,
Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 21 Mar 2013 06:51:13 +0000

Hi Justin,

I understand the potential problems with legacy endpoints as described in A.2 of Christer’s draft, not just intermediaries (A.4) which I thought Dale was specifically commenting about. The constraints of legacy peers and intermediaries is obviously important to the overall solution, but orthogonal to how we signal the desired port in a new way (as a single attribute or using the grouping framework).

BTW, has anyone actually observed failures? I ask because I could not get products to fail (when simply offering the same ports) in my (limited) interop lab. SIPit 30 was on my campus last month, I wish I would have tested it there for more data points. I can try at SuperOp next month. Just checking if someone hit a real problem before starting this bundle party.

Cheers,
Mo

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, March 21, 2013 1:11 AM
To: Mo Zanaty (mzanaty)
Cc: Dale R. Worley; [email-masked]; [email-masked]
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

The point of the different ports is not just to make intermediaries happy, but to ensure that we're successful when talking to an endpoint who doesn't support BUNDLE. There are a litany of problems that have been identified when the same ports are used on the offerer side and the answerer is BUNDLE-unaware.

On Wed, Mar 20, 2013 at 9:43 PM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dale,

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 19, 2013 3:37 PM
To: Mo Zanaty (mzanaty)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

> From: "Mo Zanaty (mzanaty)" <[email-masked]<mailto:[email-masked]>>
>

Dale
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Mar 2013 13:09:37 +0100

> Why is the direct approach more complex? Why is ICE any different in either approach?
You don't know the port you'll be using ahead of time with ICE; you have 
to put ICE into all the M-lines in order to be able to negotiate ICE 
when you don't get the bundling.

So in addition to specifying the port on the m= line, you have to uglify 
your solution by stating rules that say "if you accept this alternate 
port, you also have to accept these special rules for ICE", and all the 
other stuff that Christer uncovered and is documented in his draft.

And nothing that looks as the SDP without knowing the special semantics 
of bundle can know that the fact that a=port in those 2 M-lines implies 
special treatment of ICE.

It's a grouping framework. I don't want to create new grouping 
frameworks; the one we have is bad enough.

I think your angles will produce a bumpier ride than mine :-)

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Mar 2013 13:43:54 -0700

On Wed, Mar 20, 2013 at 11:51 PM, Mo Zanaty (mzanaty) <[email-masked]>wrote:

>  Hi Justin,****
>
> ** **
>
> I understand the potential problems with legacy endpoints as described in
> A.2 of Christer’s draft, not just intermediaries (A.4) which I thought Dale
> was specifically commenting about. The constraints of legacy peers and
> intermediaries is obviously important to the overall solution, but
> orthogonal to how we signal the desired port in a new way (as a single
> attribute or using the grouping framework).****
>
> ** **
>
> BTW, has anyone actually observed failures? I ask because I could not get
> products to fail (when simply offering the same ports) in my (limited)
> interop lab. SIPit 30 was on my campus last month, I wish I would have
> tested it there for more data points. I can try at SuperOp next month. Just
> checking if someone hit a real problem before starting this bundle party.*
> ***
>
> **
>

Yes, we have observed failures directly, and Christer has identified
several cases that can cause latent malfunctions.

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Thu, 21 Mar 2013 12:15:10 +0000

Classification: UNCLASSIFIED
Caveats: NONE

So, it is ugly vs. uglier vs. ugliest ...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Alvestrand
Sent: Thursday, March 21, 2013 8:10 AM
To: Mo Zanaty (mzanaty)
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

On 03/21/2013 06:59 AM, Mo Zanaty (mzanaty) wrote:
> Hi Harald,
>
> You're right, both are essentially groupings, and all of our wheels have
ugly angles. To me, the ugly angles in bundle are unnecessary indirection by
grouping with artificial bindings (mid), and that it pretends to be more
than it is. To me, it is just a port override, but with unnecessary
indirection. Why not just say the port you want to use directly?

> Mo

Classification: UNCLASSIFIED
Caveats: NONE

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Mar 2013 15:28:43 -0400 (EDT)

> ...so audio and video ports are 10000<->40000.

Well, the analysis depends on exactly how "a=port" works.

Option 1A:  "a=port" specifies the port number for the packets.

The difficulty with this is that, at the time the offer is made, we
don't actually know what port number (or IP address) will be used,
because (commonly) ICE will be used to negotiate the transport
association, and "a=port" doesn't provide any way to specify ICE
candidates.

Worse, we don't want the video m= line to have perform an ICE
negotiation regarding "port 40000", we want the video m= line to
utilize the *same* ICE negotiation that the audio m= line will have.

So what we really want "a=port" to do is:

Option 1B:  "a=port" is a pointer to another media description, and the
packets from this media description will be multiplexed on the
transport association for the other media description.

That is, it's an indirection mechanism.  The question is how to
organize the indirection?  And the most pleasant choice is to use the
grouping mechanism that we already have.

Once we've decided that media descriptions should have a pointer to
another media description that will carry its packets if bundling is
negotiated, there are two main choices:

Option 2A:  One of the constituent media descriptions, the "master",
will be used to carry the bundled media.

Option 2B:  There is a separate "bundle" media description that
describes the bundled media.

2B has the advantage that it allows presenting an SDP description for
the bundle transport flow *as a whole*, while still presenting an SDP
description for each of the constituent media descriptions.  Otherwise
it becomes difficult to, for instance, specify the bandwidth or QoS of
the "master" constituent media flow independently of the bandwidth or
QoS of the entire bundle media flow.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Mar 2013 15:28:24 -0400 (EDT)

> BTW, has anyone actually observed failures?

My memory is that Cullen Jennings knows of a significant installed
base of SBCs that choke on SDP that contains duplicated port
references.

Dale