Subject: [rtcweb] Multiplexing using the same port number for multiple media descritions

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2011 13:21:31 +0200

Hi,

One possible alternative solution for SDP multiplex negotiation could be based on the assumption of using the same port number in multiple SDP m- lines (yes, I know SDP does not allow it, and I will come back to that).

Something like:

SDP offer:

m=audio 10000 ...
a=rtpmap ...
a=rtpmap ...
m=video 10000 ...
a=rtpmap ...
a=rtpmap ...

SDP answer (multiplex supported/accepted):

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 20000 ...
a=rtpmap ...
a=rtpmap ...

SDP answer (multiplex not-supported/rejected):

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 30000 ...
a=rtpmap ...
a=rtpmap ...

MAYBE there is also a need to use some kind of grouping, in which case it could look something like (borrowing some terminology from Harald):

SDP offer:

a=group:TOGETHER foo bar
m=audio 10000 ...
a=mid:foo
a=rtpmap ...
a=rtpmap ...
m=video 10000 ...
a=mid:bar
a=rtpmap ...
a=rtpmap ...

SDP answer (multiplex supported/accepted):

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
a=mid:foo
m=video 20000 ...
a=mid:bar
a=rtpmap ...
a=rtpmap ...

SDP answer (multiplex not-supported/rejected):

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 30000 ...
a=rtpmap ...
a=rtpmap ...

An ISSUE with this solution is of course that SDP does not allow for it.

However, we could always say that browsers must support it, in which case it should work fine in direct browser-to-browser cases.

When interworking with legacy, I guess two things can happen:

1. The offer is acctepted, with different port number in the answer, and multiplex won't be used (see example above)

2. The offer is rejected. In this case, the fallback would be that the browser sends a new offer, with different port numbers, and multiplex won't be used.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Aug 2011 10:41:57 -0400

I think Harald's approach is cleaner, since the fallback does not require a
new offer. What do you see as problematic with Harald's suggestion?

On Tue, Aug 30, 2011 at 7:21 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> One possible alternative solution for SDP multiplex negotiation could be
> based on the assumption of using the same port number in multiple SDP m-
> lines (yes, I know SDP does not allow it, and I will come back to that).
>
> Something like:
>
> SDP offer:
>
> m=audio 10000 ...
> a=rtpmap ...
> a=rtpmap ...
> m=video 10000 ...
> a=rtpmap ...
> a=rtpmap ...
>
>
> MAYBE there is also a need to use some kind of grouping, in which case it
> could look something like (borrowing some terminology from Harald):
>
>
>
> SDP offer:
>
> a=group:TOGETHER foo bar
> m=audio 10000 ...
> a=mid:foo
> a=rtpmap ...
> a=rtpmap ...
> m=video 10000 ...
> a=mid:bar
> a=rtpmap ...
> a=rtpmap ...
>
>
> However, we could always say that browsers must support it, in which case
> it should work fine in direct browser-to-browser cases.
>
>
> 1. The offer is acctepted, with different port number in the answer, and
> multiplex won't be used (see example above)
>
> 2. The offer is rejected. In this case, the fallback would be that the
> browser sends a new offer, with different port numbers, and multiplex won't
> be used.
>
> Regards,
>
> Christer
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 30 Aug 2011 17:15:32 +0200

On 08/30/11 13:21, Christer Holmberg wrote:
> Hi,
> One possible alternative solution for SDP multiplex negotiation could 
> be based on the assumption of using the same port number in multiple 
> SDP m- lines (yes, I know SDP does not allow it, and I will come back 
> to that).
> Something like:
> SDP offer:
> m=audio 10000 ...
> a=rtpmap ...
> a=rtpmap ...
> m=video 10000 ...
> a=rtpmap ...
> a=rtpmap ...
In this case, packets flow from/to port 10000 to port 20000 for both 
media types.
> SDP answer (multiplex not-supported/rejected):
In this case, packets would presumably flow between port 10000 and port 
20000 for audio, and port 10000 and port 30000 for video.
Is that a correct interpretation of how you think this would work?

In that case, we have an RTP spec problem, not just an SDP problem: RTP 
"straight" claims to identify sessions by destination address + port 
(RFC 3550 section 5.2, for instance). In normal unicast / point-to-point 
usage, we expect all packets to come from the same address + port too, 
but RFC 3550 doesn't say that.

I don't know if this is an issue. If it is an issue, sender might have 
to start over.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2011 21:26:14 +0200

Hi Harald,

>In this case, packets flow from/to port 10000 to port 20000 for both media types.

Yes.

(The question is then whether we need something in addition, e.g. something like the TOGETHER grouping, to actually indicate that they are multiplexed. But, I guess that depends e.g. on the actual multiplex mechanism we'll use.)

>In this case, packets would presumably flow between port 10000 and port 20000 for audio, and port 10000 and port 30000 for video.

Yes.

>In that case, we have an RTP spec problem, not just an SDP problem: RTP "straight" claims to identify sessions by destination address + port (RFC 3550 section 5.2, for instance). In normal unicast / point-to-point usage, we expect all packets to come from the same 
>address + port too, but RFC 3550 doesn't say that.
>
>I don't know if this is an issue. If it is an issue, sender might have to start over.

I am not sure I understood the issue.

However, I am not saying there aren't any issues - I just think we should allow ourselves to look into different solution alternatives :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2011 21:27:33 +0200

Hi Justin,

>I think Harald's approach is cleaner, since the fallback does not require a new offer.
>
>What do you see as problematic with Harald's suggestion?

I have sent comments on Harald's draft, but my main issues are:

1. Unclear how to remove the m- line which is used for the multiplexed stream.

(Maybe Harald has indicated somewhere how it would be done, and in that case I appologise for having missed it)

2. Intermediaries that do not understand the extension would still think that there are individual streams, and reserve resources etc accordingly.

(Now, maybe there aren't such intermediaries in a web environment. But as CLUE very likely will also need some kind of a multiplex negotiation mechanism I would like to see something more general).

Regards,

Christer

On Tue, Aug 30, 2011 at 7:21 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Something like:

SDP offer:

m=audio 10000 ...
a=rtpmap ...
a=rtpmap ...
m=video 10000 ...
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 20000 ...
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 30000 ...
a=rtpmap ...
a=rtpmap ...

SDP offer:

a=group:TOGETHER foo bar
m=audio 10000 ...
a=mid:foo
a=rtpmap ...
a=rtpmap ...
m=video 10000 ...
a=mid:bar
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
a=mid:foo
m=video 20000 ...
a=mid:bar
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 30000 ...
a=rtpmap ...
a=rtpmap ...

Regards,

Christer

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Aug 2011 13:15:09 +0200

> I don't know if this is an issue. If it is an issue, sender might have

Well, that is one way to id the session a flow is supposed to end up in.
 If I understand the situation you are proposing would still allow the
inviting party to use 5-tuples to identify flows coming into each
session. This as you will learn from the ICE processing each peers
visible source address for each session through the ICE plus signaling.

And I don't think we have a spec problem if we like to use a session
transport setup that looks like this.

Session 1
A:10000 <---> B:20000

Session 2
A:10000 <---> B:30000

As this provides different 5-tuples it does fulfill for example the
following from section 5.2 of RFC3550:

   For example, in a teleconference
   composed of audio and video media encoded separately, each medium
   SHOULD be carried in a separate RTP session with its own destination
   transport address.

At least if you interpret "own destination transport address" as the
full five tuple rather than a 3-tuple of destiantion address, port and
protocol.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2011 15:35:56 +0200

Hi,

Another advantage of the same-port-number solution is that the browser doesn't need to reserve more than one port (including candidate collection etc) - no matter whether multiplexing will eventually be used or not.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30. elokuuta 2011 14:22
To: [email-masked]
Subject: [rtcweb] Multiplexing using the same port number for multiple media descritions

Hi,

Something like:

SDP offer:

m=audio 10000 ...
a=rtpmap ...
a=rtpmap ...
m=video 10000 ...
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 20000 ...
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 30000 ...
a=rtpmap ...
a=rtpmap ...

SDP offer:

a=group:TOGETHER foo bar
m=audio 10000 ...
a=mid:foo
a=rtpmap ...
a=rtpmap ...
m=video 10000 ...
a=mid:bar
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
a=mid:foo
m=video 20000 ...
a=mid:bar
a=rtpmap ...
a=rtpmap ...

m=audio 20000 ...
a=rtpmap ...
a=rtpmap ...
m=video 30000 ...
a=rtpmap ...
a=rtpmap ...

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 31 Aug 2011 16:55:53 +0200

> 2. Intermediaries that do not understand the extension would still think that there are individual streams, and reserve resources etc accordingly.
Would those intermediaries understand the double usage in your proposal?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2011 19:43:16 +0200

Hi Harald,

>> (Maybe Harald has indicated somewhere how it would be done, and in that case I appologise for having >>missed it)
>>
>>
>> 2. Intermediaries that do not understand the extension would still think that there are individual streams, and >>reserve resources etc accordingly.

The currently existing products and deployments that I am aware of would reserve different local ports for each m- line. They don't care about that fact that identical remote ports are used. So, there would be no multiplexing, but at least things would work - the correct amount of resources etc would be reserved.

Regards,

Christer