Subject: [rtcweb] Working group last call resolutions/Consensus call

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Jan 2017 13:49:36 -0800

Howdy,

As you can see below, there is a new version of JSEP, which responds to
many of the matters raised during Working Group Last Call.  Please review
it carefully, noting particularly the change log in Appendix C.  If you
raised an issue, please confirm that you believe it has been addressed or
explain why it has not been.  The chairs do not plan on issuing individual
consensus calls on most issues, but will instead issue a new working group
last call after the next update, which will address the issues remaining in
the github repo (https://github.com/rtcweb-wg/jsep/issues).

The one exception to this is Appendix B.  The chairs are hereby issuing a
two week consensus call on the algorithm contained in Appendix B, so that
this working group can positively affirm that it meets the needs of the
WebRTC development community when it is considered by MMUSIC or the wider
IETF community.

If you do not believe it meets the needs of the WebRTC community, the
chairs ask that you respond by explicitly indicating  what changes to the
algorithm are required or what replacement algorithm you propose.
Responses that do not indicate clearly what the algorithm should be will be
weighted accordingly.

Thanks, and happy reading,

Ted, Cullen, and Sean

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Jan 16, 2017 at 4:08 PM
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-18.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Real-Time Communication in WEB-browsers of
the IETF.

        Title           : Javascript Session Establishment Protocol
        Authors         : Justin Uberti
                          Cullen Jennings
                          Eric Rescorla
        Filename        : draft-ietf-rtcweb-jsep-18.txt
        Pages           : 99
        Date            : 2017-01-16

Abstract:
   This document describes the mechanisms for allowing a Javascript
   application to control the signaling plane of a multimedia session
   via the interface specified in the W3C RTCPeerConnection API, and
   discusses how this relates to existing signaling protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-18

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jan 2017 11:01:10 +0100

Den 2017-01-17 kl. 22:49, skrev Ted Hardie:
> The one exception to this is Appendix B.  The chairs are hereby issuing
> a two week consensus call on the algorithm contained in Appendix B, so
> that this working group can positively affirm that it meets the needs of
> the WebRTC development community when it is considered by MMUSIC or the
> wider IETF community.
>

Hi,

Here is my feedback on Appendix B. I am sorry that sickness,
holiday vacations has prevented me to be more proactive on this subject.

There was feedback on the proposal Colin Perkins and I put together, 
which we failed to respond to yet. I have reviewed the emails before 
responding now. I will attempt to respond to what I consider the high 
level issues and my views that was brought up in those emails.

Regarding PT based routing:

RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of 
packets are not required for any WebRTC endpoint. PT based routing works 
only in some constrained usages, thus my view is that it needs to remain 
a hint, and an optional hint at most. It must be clear that it is not 
something that is reliable. I also struggle to see in what non-WebRTC 
interop use cases this arises. The non-WebRTC endpoint needs to be 
capable of multi media source, and multi stream (SSRC) RTP sessions, but 
not implement BUNDLE. Or is it a aggregating gateway, that is to lazy to 
add MIDs?

On the packet level routing description: The issue I have had previously 
and to some degree also with the current appendix B is that it is 
described in a fashion that appears to match a particular RTP stack 
implementation. And I have to note that it is not like the two RTP stack 
implementations I have been involved designing. Thus, the description at 
its level of specificity does not fit what I would do. It also does not 
let the RTP concepts work for you, instead this is injected in the 
bottom of the stack.

The text I talk about is the following:

   For each RTP packet received, the following steps MUST be followed to
    route the packet to the correct "m=" section within a BUNDLE group.
    Note that the phrase 'deliver a packet to the "m=" line' means to
    further process the packet as would normally happen with RTP/RTCP, if
    it were received on a transport associated with that "m=" line
    outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd),
    including dropping an RTP packet if the packet's PT does not match
    any PT in the "m=" line.

       If the packet has a MID and that MID is not in the table mapping
       MID to "m=" line, drop the packet and stop.

       If the packet has a MID and that MID is in the table mapping MID
       to "m=" line, update the incoming SSRC mapping table to include an
       entry that maps the packet's SSRC to the "m=" line for that MID.

       If the packet's SSRC is in the incoming SSRC mapping table, route
       the packet to the associated "m=" line and stop.

       If the packet's payload type is in the payload type table, update
       the the incoming SSRC mapping table to include an entry that maps
       the packet's SSRC to the "m=" line for that payload type.  In
       addition, route the packet to the associated "m=" line and stop.

       Otherwise, drop the packet.

If I would write this packet level routing it would work with the 
concepts of the RTP protocol:

This the bullet list would look like this instead:

      1. Reception of an RTP packet for a SSRC with an existing
         association to an m= line, with a MID RTP header extension, the
         MID value is checked. If it matches the existing association,
         then the processing continues in that m= line context. If
         the value is a new value, then the association to the m= line
         is updated, and then the packet is processed in the new m= line
         context.

      2. Reception of an RTP packet with an SSRC that has
         an existing mapping to an m= line is processed in that
         m= line context.

      3. Reception of an RTP packet with a previously unknown SSRC that
         contains an MID RTP header extension, will result in that SSRC
         be associated with the corresponding m= line. The packet is
         then processed in this m= line context.
	
      4. Reception of an RTP packet with an SSRC that has no association
         to any m= line is processed by the RTP protocol implementation
         for statistics, etc. but is then dropped.

I would not route on PT, but in this style of description the PT routing 
would look like the below bullet, but I would prefer to skip it. It 
should be inserted second to last of the bullets, i.e. between 3 and 4.

       3.5 Reception of a previously unknown SSRC that
         contains an PT value that exists in the payload type mapping
         table, will result in that SSRC be associated with the
         corresponding m= line.

However, the above is not sufficient, it also needs an amendment to 
bullet 2, where if the PT value does not match the m= line context the 
association needs to be updated.

For the RTCP part the appendix B description is even more foreign to my 
implementations. As the implementations will process the information of 
the incoming RTCP compound packet and then provide API that notifies the 
higher layer of the changes of interest. Like for example the reception 
of a Feedback Request, or the change to a SDES item for a particular 
SSRC. Thus the actions related to RTCP becomes even more abstract. Where 
the description says "deliver a copy of the RTCP packet to the "m=" line 
associated with that SSRC" I would say "Process the information in the 
context of the m= line that is associated with the SSRC".

So my conclusion is that the current issue is how we find a specific 
enough description that at the same time does not restrict how you 
implement your RTP stack.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Jan 2017 11:07:18 +0100

2017-01-18 11:01 GMT+01:00 Magnus Westerlund <[email-masked]>:
> PT based routing works only in some constrained usages, thus my view is that
> it needs to remain a hint, and an optional hint at most.

Fully agreed. It has no value other than receiving stream(s) from a
single remote media source per RTP session (transport).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Jan 2017 07:52:50 -0700

> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> 
> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agree with what I say next.... WebRTC browsers are required to interoperate with "legacy" things that don't do bundle and things that may do bundle but try not to use MIDs in cases where they are a gratuitous waste of bandwidth. 

> PT based routing works only in some constrained usages, thus my view is that it needs to remain a hint, and an optional hint at most.
> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correct so perhaps you could explain the where they don't work. I seen lots of projects ship this and work fine. The algorithm in appendix B make it clear PT are only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than are available in the PT space. A huge percentage of of real world use cases for SDP easily fit inside the current PT space. One of the cases I care about if a low peak bandwidth phone (not average) for places like parts of Africa that uses a 700 bps codec. Most single stream of audio and video "video phone call" type cases also easily work. Yes, I understand one could construct some single audio/video where enough things were the SDP offer needs more PTs than there was space for but if you look at the SDP from just about every major manufacture of VoIP audio phones, you see what they are currently doing can easily be done with unique PT values. Anyway, for these case where you don't run out of PT, please please explain why PT routing is so broken that is should be an optional hint. In practice it seems to work fine. 

Anyways, I'm just not seeing what you think the problem is here. I don't see a problem so I feel pretty strongly that the algorithm in Appendix B is fine. Convince me on why is "not reliable" and and "only in some constrained usages"

> I also struggle to see in what non-WebRTC interop use cases this arises. The non-WebRTC endpoint needs to be capable of multi media source, and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggregating gateway, that is to lazy to add MIDs?
> 

People want to avoid the media gateway between WebRTC and and an SIP endpoint where they can. The media gateway adds latency - huge amounts in the case where both endpoints require a satellite hop to get to the gateway - and it add the bandwidth expenses of running gateway. 

On all of this, I want to be clear, for people that want to do something where the PT space is not large enough, obviously they can use MID, I'm just saying that for things that don't use MID, and can fit in the PT space, it should be an option to use PT and know it will work.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 18 Jan 2017 15:57:15 +0100

2017-01-18 15:52 GMT+01:00 Cullen Jennings <[email-masked]>:
> please please explain why PT routing is so broken that is should be an optional hint. In practice it seems to work fine.

Multi-stream.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 Jan 2017 07:45:06 -0800

Magnus said:

"RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of
packets are not required for any WebRTC endpoint."

[BA] BUNDLE (and RTP/RTCP mux) is very popular in WebRTC applications.  But
apparently so is PT-based routing.  Bugs are showing up even in basic
audio/video applications (where the PT is unique).

Since MID is not yet implemented, no existing applications support it.
Since many mobile application developers sync infrequently to updated
source bases, once MID is implemented it may take several years for
applications to incorporate it.  It would not even surprise me if some very
popular mobile applications currently using PT-based routing do not
transition to MID.

"PT based routing works only in some constrained usages, thus my view is
that it needs to remain a hint, and an optional hint at most. It must be
clear that it is not something that is reliable."

[BA] While it's not necessary to handle every conceivable scenario,
defining the behavior in the "constrained usages" would help.

"I also struggle to see in what non-WebRTC interop use cases this arises.
The non-WebRTC endpoint needs to be capable of multi media source, and
multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a
aggregating gateway, that is to lazy to add MIDs?"

[BA] There are basic scenarios where an audio and a video stream are
BUNDLEd which do not behave consistently today.  Looking at the bug
reports, it would appear to me that the problems originated in inconsistent
implementation of basic RFCs such as 3264 and 5576.

On Wed, Jan 18, 2017 at 2:01 AM, Magnus Westerlund <
[email-masked]> wrote:

> There was feedback on the proposal Colin Perkins and I put together, which
> we failed to respond to yet. I have reviewed the emails before responding
> now. I will attempt to respond to what I consider the high level issues and
> my views that was brought up in those emails.
>
> only in some constrained usages, thus my view is that it needs to remain a
> hint, and an optional hint at most. It must be clear that it is not
> interop use cases this arises. The non-WebRTC endpoint needs to be capable
> of multi media source, and multi stream (SSRC) RTP sessions, but not
> implement BUNDLE. Or is it a aggregating gateway, that is to lazy to add
> MIDs?
>
>
> and to some degree also with the current appendix B is that it is described
> in a fashion that appears to match a particular RTP stack implementation.
> And I have to note that it is not like the two RTP stack implementations I
> have been involved designing. Thus, the description at its level of
> specificity does not fit what I would do. It also does not let the RTP
> concepts work for you, instead this is injected in the bottom of the stack.
>
> If I would write this packet level routing it would work with the concepts
> of the RTP protocol:
>
> would look like the below bullet, but I would prefer to skip it. It should
> be inserted second to last of the bullets, i.e. between 3 and 4.
>
> However, the above is not sufficient, it also needs an amendment to bullet
> 2, where if the PT value does not match the m= line context the association
> needs to be updated.
>
> implementations. As the implementations will process the information of the
> incoming RTCP compound packet and then provide API that notifies the higher
> layer of the changes of interest. Like for example the reception of a
> Feedback Request, or the change to a SDES item for a particular SSRC. Thus
> the actions related to RTCP becomes even more abstract. Where the
> description says "deliver a copy of the RTCP packet to the "m=" line

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 Jan 2017 09:34:07 -0800

Cullen said:

"Look, I don't see it this way and I suspect you are going to agree with
what I say next.... WebRTC browsers are required to interoperate with
"legacy" things that don't do bundle and things that may do bundle but try
not to use MIDs in cases where they are a gratuitous waste of bandwidth."

[BA] +1.   There is definitely an expectation on the part of developers
that WebRTC will behave like the "legacy" SDP they are used to - even if
they are not interoperating with legacy applications.  Since those
applications worked without MIDs, developers will expect them to continue
to work when MID support is introduced in future.

"I seen lots of projects ship this and work fine. The algorithm in appendix
B make it clear PT are only used if they are unique across all the m-lines.
So clearly it can not be used if you need more PT than are available in the
PT space. A huge percentage of of real world use cases for SDP easily fit
inside the current PT space."

[BA] +1.  My experience is that *most* of the developers shipping WebRTC
applications that run on multiple browsers are using PT-based routing, so
they'd be very surprised to learn that it isn't supported (and they would
probably push back vigorously at such a notion).

"Anyways, I'm just not seeing what you think the problem is here. I don't
see a problem so I feel pretty strongly that the algorithm in Appendix B is
fine."

[BA] The algorithm in Appendix B includes PT routing and I'd like it to
continue to cover that.  The algorithm appears to resolve a number of bugs
filed by both WebRTC and ORTC developers. It will take a bit more review to
confirm that it doesn't cause any regressions.

On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings <[email-masked]> wrote:

> packets are not required for any WebRTC endpoint.
>
> Look, I don't see it this way and I suspect you are going to agree with
> what I say next.... WebRTC browsers are required to interoperate with
> "legacy" things that don't do bundle and things that may do bundle but try
> not to use MIDs in cases where they are a gratuitous waste of bandwidth.
>
> > PT based routing works only in some constrained usages, thus my view is
> that it needs to remain a hint, and an optional hint at most.
> You keep asserting this but I'm not convinced you are are correct so
> perhaps you could explain the where they don't work. I seen lots of
> projects ship this and work fine. The algorithm in appendix B make it clear
> PT are only used if they are unique across all the m-lines. So clearly it
> can not be used if you need more PT than are available in the PT space. A
> huge percentage of of real world use cases for SDP easily fit inside the
> current PT space. One of the cases I care about if a low peak bandwidth
> phone (not average) for places like parts of Africa that uses a 700 bps
> codec. Most single stream of audio and video "video phone call" type cases
> also easily work. Yes, I understand one could construct some single
> audio/video where enough things were the SDP offer needs more PTs than
> there was space for but if you look at the SDP from just about every major
> manufacture of VoIP audio phones, you see what they are currently doing can
> easily be done with unique PT values. Anyway, for these
>   case where you don't run out of PT, please please explain why PT routing
> is so broken that is should be an optional hint. In practice it seems to
> work fine.
>
> Anyways, I'm just not seeing what you think the problem is here. I don't
> see a problem so I feel pretty strongly that the algorithm in Appendix B is
> fine. Convince me on why is "not reliable" and and "only in some
> constrained usages"
>
> > I also struggle to see in what non-WebRTC interop use cases this arises.
> aggregating gateway, that is to lazy to add MIDs?
> >
>
>
> People want to avoid the media gateway between WebRTC and and an SIP
> endpoint where they can. The media gateway adds latency - huge amounts in
> the case where both endpoints require a satellite hop to get to the gateway
> - and it add the bandwidth expenses of running gateway.
>
>
>
> On all of this, I want to be clear, for people that want to do something
> where the PT space is not large enough, obviously they can use MID, I'm
> just saying that for things that don't use MID, and can fit in the PT
> space, it should be an option to use PT and know it will work.
>
>
>
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 Jan 2017 12:53:15 -0800

A comment on the RTP matching rules:

" If the packet's SSRC is in the incoming SSRC mapping table, route the
packet to the associated "m=" line and stop."

[BA] In the situation where the packet's Payload Type does not match any
PTs for the "m=" line, the packet should be dropped.

I have submitted PR https://github.com/rtcweb-wg/jsep/pull/511 to fix this.

A comment on the RTCP matching rules:

      If the packet is of type RTPFB or PSFB, as defined in [RFC4585
<https://tools.ietf.org/html/rfc4585>],
      and the media source SSRC for the packet is found in the outgoing
      SSRC table, deliver the packet to the "m=" line associated with
      that SSRC.

[BA] This does not handle APP, FIR or LRR packets.

Some suggested edits are provided here:

https://github.com/rtcweb-wg/jsep/pull/512

On Tue, Jan 17, 2017 at 1:49 PM, Ted Hardie <[email-masked]> wrote:

> This draft is a work item of the Real-Time Communication in WEB-browsers
> of the IETF.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Jan 2017 11:01:21 +0100

Den 2017-01-18 kl. 15:52, skrev Cullen Jennings:
>> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing
>> of packets are not required for any WebRTC endpoint.
>
> Look, I don't see it this way and I suspect you are going to agree
> with what I say next.... WebRTC browsers are required to interoperate
> with "legacy" things that don't do bundle and things that may do
> bundle but try not to use MIDs in cases where they are a gratuitous
> waste of bandwidth.
>
>> PT based routing works only in some constrained usages, thus my
>> view is that it needs to remain a hint, and an optional hint at
>> most. It must be clear that it is not something that is reliable.
>
> projects ship this and work fine. The algorithm in appendix B make it
> clear PT are only used if they are unique across all the m-lines. So
> clearly it can not be used if you need more PT than are available in
> the PT space. A huge percentage of of real world use cases for SDP
> easily fit inside the current PT space. One of the cases I care about
> if a low peak bandwidth phone (not average) for places like parts of
> Africa that uses a 700 bps codec. Most single stream of audio and
> video "video phone call" type cases also easily work. Yes, I
> understand one could construct some single audio/video where enough
> things were the SDP offer needs more PTs than there was space for but
> if you look at the SDP from just about every major manufacture of
> VoIP audio phones, you see what they are currently doing can easily
> be done with unique PT values. Anyway, for these case where you don't
> run out of PT, please please explain why PT routing is so broken that
> is should be an optional hint. In practice it seems to work fine.

I will not contest that it does work as long as you ensure that PT 
values are unique across all m= lines in one RTP session. My objection 
is on an architectural level here. As the PT requirement is not unique 
one needs to implement a=MIDs. Thus, the PT routing rules becomes a 
crutch that gets embedded into also the standards implementation not 
only the legacy and carried forward. What I fail to understand is what 
this legacy is that does multiple m= lines within a single RTP session 
is. For how many deployed devices are we ensuring interop with?

>
> Anyways, I'm just not seeing what you think the problem is here. I
> don't see a problem so I feel pretty strongly that the algorithm in
> Appendix B is fine. Convince me on why is "not reliable" and and
> "only in some constrained usages"

I accept that the PT association rules needs to stay in. And this is a 
diversion from the part that I have real issue with. The style of the 
rules that places the routing below the RTP stack, rather than above it. 
And you may note that I did explain how my proposed description format 
would take PTs into account. My question is would you and others have 
objections with rules as I wrote them?

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Jan 2017 11:33:21 +0000

Hi,

If things work fine using PT, why do we mandate MID in the first place? Why would people implement MID in the future if PT works?

Unless I remember wrong, Adam is the one who said that the PT space is not big enough, and that we therefor need something else – which made us mandate SSRC, specify the tools for MID transport, etc.

Also, I am not sure what is meant by a “hint”. If there are applications that don’t support MID, and need to use PT, then it has to be more than a “hint”. It must be a testable rule.

Regards,

Christer

From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 18 January 2017 at 19:34
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B

Cullen said:

"Look, I don't see it this way and I suspect you are going to agree with what I say next.... WebRTC browsers are required to interoperate with "legacy" things that don't do bundle and things that may do bundle but try not to use MIDs in cases where they are a gratuitous waste of bandwidth."

[BA] +1.   There is definitely an expectation on the part of developers that WebRTC will behave like the "legacy" SDP they are used to - even if they are not interoperating with legacy applications.  Since those applications worked without MIDs, developers will expect them to continue to work when MID support is introduced in future.

"I seen lots of projects ship this and work fine. The algorithm in appendix B make it clear PT are only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than are available in the PT space. A huge percentage of of real world use cases for SDP easily fit inside the current PT space."

[BA] +1.  My experience is that *most* of the developers shipping WebRTC applications that run on multiple browsers are using PT-based routing, so they'd be very surprised to learn that it isn't supported (and they would probably push back vigorously at such a notion).

"Anyways, I'm just not seeing what you think the problem is here. I don't see a problem so I feel pretty strongly that the algorithm in Appendix B is fine."

[BA] The algorithm in Appendix B includes PT routing and I'd like it to continue to cover that.  The algorithm appears to resolve a number of bugs filed by both WebRTC and ORTC developers. It will take a bit more review to confirm that it doesn't cause any regressions.

On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
>
>

> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correct so perhaps you could explain the where they don't work. I seen lots of projects ship this and work fine. The algorithm in appendix B make it clear PT are only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than are available in the PT space. A huge percentage of of real world use cases for SDP easily fit inside the current PT space. One of the cases I care about if a low peak bandwidth phone (not average) for places like parts of Africa that uses a 700 bps codec. Most single stream of audio and video "video phone call" type cases also easily work. Yes, I understand one could construct some single audio/video where enough things were the SDP offer needs more PTs than there was space for but if you look at the SDP from just about every major manufacture of VoIP audio phones, you see what they are currently doing can easily be done with unique PT values. Anyway, for these
  case where you don't run out of PT, please please explain why PT routing is so broken that is should be an optional hint. In practice it seems to work fine.

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jan 2017 14:19:39 -0800

It's not big enough for every use case but it's in use for certain limited
use cases now. Hence the need to support PT now and MID in the future

-Ekr

On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg <
[email-masked]> wrote:

>
> Hi,
>
> If things work fine using PT, why do we mandate MID in the first place?
> Why would people implement MID in the future if PT works?
>
> Unless I remember wrong, Adam is the one who said that the PT space is not
> big enough, and that we therefor need something else – which made us
> mandate SSRC, specify the tools for MID transport, etc.
>
> Also, I am not sure what is meant by a “hint”. If there are applications
> that don’t support MID, and need to use PT, then it has to be more than a
> “hint”. It must be a testable rule.
>
> Regards,
>
> Christer
>
>
>
>
>
> From: rtcweb <[email-masked]> on behalf of Bernard Aboba <
> [email-masked]>
> To: Cullen Jennings <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> "I seen lots of projects ship this and work fine. The algorithm in
> appendix B make it clear PT are only used if they are unique across all the
> m-lines. So clearly it can not be used if you need more PT than are
> available in the PT space. A huge percentage of of real world use cases for
> SDP easily fit inside the current PT space."
>
>>   case where you don't run out of PT, please please explain why PT
>> routing is so broken that is should be an optional hint. In practice it
>> seems to work fine.
>>
>> > I also struggle to see in what non-WebRTC interop use cases this
>> arises. The non-WebRTC endpoint needs to be capable of multi media source,
>> and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jan 2017 14:25:42 -0800

>         is updated, and then the packet is processed in the new m= line

I don't understand how this point is different from points #1 and #2 above.

Is your problem with the talk of a table versus an association? Routing
to an m= line versus "processed in the m= line context"? Can you help me
understand
how these are semantically different? Specifically what implementation
technique would
be allowed by your text that is not allowed by the existing text (and that
couldn't be
solved by requiring implementations to have the same external behavior).

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Jan 2017 15:06:32 -0800

Magnus said:

"What I fail to understand is what this legacy is that does multiple m=
lines within a single RTP session is. For how many deployed devices are we
ensuring interop with?"

[BA] Here is an example of a scenario which utilizes PT routing rules.
This is not theoretical - it arises from a bug report that landed on my
desk.

The bug is showing up in a basic application which appears to be using both
RTP/RTCP mux and BUNDLE (as the vast majority of WebRTC applications do).
I don't know if this application is using SIP signaling or not, or trying
to interop with a legacy (non-WebRTC) implementation, but since PT-routing
seems to be implemented so widely by developers, the bug could easily show
up in a new application that had no legacy-interop requirements.

The application is not signaling SSRCs or MIDs, just PTs.  When the SSRC
changes (PT remains the same), the developer is expecting the RTP packets
to be routed to the same receiver based on a PT match, without having to
signal the new SSRC.

The JSEP Appendix B routing rules will produce this behavior.  Chrome also
apparently exhibits this behavior and the developer filing the bug expects
all WebRTC browsers to behave the same way.

On Fri, Jan 20, 2017 at 2:01 AM, Magnus Westerlund <
[email-masked]> wrote:

> I will not contest that it does work as long as you ensure that PT values
> are unique across all m= lines in one RTP session. My objection is on an
> architectural level here. As the PT requirement is not unique one needs to
> implement a=MIDs. Thus, the PT routing rules becomes a crutch that gets
> embedded into also the standards implementation not only the legacy and
> carried forward. What I fail to understand is what this legacy is that does
> multiple m= lines within a single RTP session is. For how many deployed
> devices are we ensuring interop with?
>
>
> diversion from the part that I have real issue with. The style of the rules
> that places the routing below the RTP stack, rather than above it. And you
> may note that I did explain how my proposed description format would take
> PTs into account. My question is would you and others have objections with
> rules as I wrote them?
>
> Cheers
>
> Magnus Westerlund
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 Jan 2017 13:32:04 +0000

Hi,

>It's not big enough for every use case but it's in use for certain limited use cases >now. Hence the need to support PT now and MID in the future

In that case there should be a clear rule saying that, if the PTs are unique, they can be used. No “hints” :)

Regards,

Christer

On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Cullen said:

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Jan 2017 09:31:01 -0800

Yes, I agree. And I think that's what appendix B currently says.

-Ekr

On Sat, Jan 21, 2017 at 5:32 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> >It's not big enough for every use case but it's in use for certain
> limited use cases >now. Hence the need to support PT now and MID in the
> future
>
>
>
> *From: *rtcweb <[email-masked]> on behalf of Bernard Aboba <
> [email-masked]>
> *Date: *Wednesday 18 January 2017 at 19:34
> *To: *Cullen Jennings <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [rtcweb] Working group last call resolutions/Consensus
> call: Appendix B
>
>
>
> Cullen said:
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 Jan 2017 19:46:55 +0000

Hi,

>Yes, I agree. And I think that's what appendix B currently says.

My comment was more on what has been discussed on this list.

Regarding Appendix B in general: if the idea is to eventually place the text in draft-bundle, I think we should move it there BEFORE the publication request for draft-jsep is done. I see no reason to have the text in two places. Perhaps that’s the intention, but it’s not clear when reading the draft…

Regards,

Christer

On Sat, Jan 21, 2017 at 5:32 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Hi,

Regards,

Christer

Cullen said:

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Jan 2017 12:12:28 -0800

On Sat, Jan 21, 2017 at 11:46 AM, Christer Holmberg <
[email-masked]> wrote:

> Regarding Appendix B in general: if the idea is to eventually place the
> text in draft-bundle, I think we should move it there BEFORE the
> publication request for draft-jsep is done. I see no reason to have the
> text in two places. Perhaps that’s the intention, but it’s not clear when
> reading the draft…
>

This seems like a question for the chairs.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 21 Jan 2017 18:43:56 -0700

> On Jan 20, 2017, at 3:01 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> I will not contest that it does work as long as you ensure that PT values are unique across all m= lines in one RTP session. My objection is on an architectural level here. As the PT requirement is not unique one needs to implement a=MIDs. Thus, the PT routing rules becomes a crutch that gets embedded into also the standards implementation not only the legacy and carried forward. What I fail to understand is what this legacy is that does multiple m= lines within a single RTP session is. For how many deployed devices are we ensuring interop with?
> 

So I agree with you that this is not likely to go away and thus why "legacy" may be a somewhat misleading way of labeling it. Consider a simple audio call that has the ability to turn on video at any point that is running with low bit rate codecs over a satellite connection that reserves the bandwidth for the audio portion (but not the video). That works today and when you go to those people and tell them they need to increase the reservation size to support MID but it it will have some benefit of speeding up call set up, they say "no thanks". However, I view this architecturally as simply when you use cases can not fit in the "legacy" address space of PT, then use MID to get an expanded address space. Even if we mandated everything do MID, it's not like we could remove the PT from the packet or from the code. So much stuff is built at this point which does this that I think we are really in the document how it works stage. 

> I accept that the PT association rules needs to stay in. And this is a diversion from the part that I have real issue with. The style of the rules that places the routing below the RTP stack, rather than above it. And you may note that I did explain how my proposed description format would take PTs into account. My question is would you and others have objections with rules as I wrote them?

If we have two descriptions of this packet demux stuff and they both result in implementors needing to write the same code, then I have no strong opinions about which one we use. Not 100% sure but I think I understand what you are suggesting and I think that is the case we are in here. At that point I tend to favor the one that has the best odds that when implementors read it, that they will write interoperable code. I think others feel strong than me about how it is described but I mostly just care what algorithm I can count on the person I am sending packets to implementing.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jan 2017 10:51:50 +0100

Hi,

See inline below.

Den 2017-01-20 kl. 23:25, skrev Eric Rescorla:

> be allowed by your text that is not allowed by the existing text (and
> that couldn't be

So the issue I have is that it describes the processing like this 
routing needs to occur in the bottom of the RTP protocol implementation. 
If I would utilize any of my implementations for WebRTC that would not 
work. Because I do the association on the upper API of the RTP 
implementation. So it becomes a question of knowing where the RTP 
stream, i.e. the RTP packets with a particular SSRC should be delivered 
to. Thus, see a need for generalized formulation that doesn't dictates 
how one implements one RTP stack in relation to the routing.

I have continued working on a proposal for this text to something that I 
think covers all the cases of the current -18 appendix B text for RTP. I 
am still working on the RTCP text.

I would also like to note that this text is intended for BUNDLE. I think 
there are still need for some text for JSEP. Especially if we want to 
include anything about on the various different RTCP extensions in use. 
Because, I think it doesn't make sense for BUNDLE to dive into all of 
the various RTCP feedback formats etc that RTCWeb includes, some 
examples of the principle should be sufficient. Then JSEP could select 
to expand on that.

10.2.  Associating RTP/RTCP Streams With Correct SDP Media Description

    As described in [RFC3550], RTP packets are associated with RTP
    streams [RFC7656].  Each RTP stream is identified by an SSRC value,
    and each RTP packet carries an SSRC value that is used to associate
    the packet with the correct RTP stream.  RTCP packets also uses SSRCs
    to identify on which RTP streams any report or feedback relate to.
    Thus, an RTCP packet will commonly carry multiple SSRC values, and
    might therefore be providing feedback or report on multiple RTP
    streams.

    In order to be able to process received RTP/RTCP packets correctly it
    must be possible to associate an RTP stream with the correct "m="
    line, as the "m=" line and SDP attributes associated with the "m="
    line contain information needed to process the packets.

    As all RTP streams associated with a BUNDLE group are part of the
    same RTP session and using the same address:port combination for
    sending and receiving RTP/RTCP packets, the local address:port
    combination cannot be used to associate an RTP stream with the
    correct "m=" line.  In addition, multiple RTP streams might be
    associated with the same "m=" line.

    Also, as described in Section 10.1.1, the same payload type value
    might be used by multiple RTP streams, in which case the payload type
    value cannot be used to associate an RTP stream with the correct "m="
    line.  However, there are cases where each "m=" line has unique
    payload type values, and then the payload type could serve as
    indicator to the relevant "m=" line the RTP stream is associated
    with.

    An offerer and answerer can inform each other which SSRC values they
    will use for an RTP stream by using the SDP 'ssrc' attribute
    [RFC5576].  However, an offerer will not know which SSRC values the
    answerer will use until the offerer has received the answer providing
    that information.  Due to this, before the offerer has received the
    answer, the offerer will not be able to associate an RTP stream with
    the correct "m=" line using the SSRC value associated with the RTP
    stream.  In addition, the offerer and answerer may start using new
    SSRC values mid-session, without informing each other using the SDP
    'ssrc' attribute.

    In order for an offerer and answerer to always be able to associate
    an RTP stream with the correct "m=" line, the offerer and answerer
    using the BUNDLE extension MUST support the mechanism defined in
    Section 14, where the offerer and answerer includes the
    identification-tag (provided by the remote peer) associated with an
    "m=" line in the RTP Streams and in RTCP SDES packets part of a
    BUNDLE group.

    The mapping from an SSRC to an identification-tag is carried in RTCP
    SDES packets or in RTP header extensions (Section 14).  Since a
    compound RTCP packet can contain multiple RTCP SDES packets, and each
    RTCP SDES packet can contain multiple chunks, an RTCP packet can
    contain several SSRC to identification-tag mappings.  The offerer and
    answerer maintain tables mapping RTP streams identified by SSRC to
    "m=" lines identified by the identification-tag.  These tables are
    updated each time new information that affects how packets should be
    processed and routed are received.

    To prepare for demultiplexing RTP streams to the correct "m=" line,
    the following steps MUST be followed for each BUNDLE group based on
    the SDP signalling information.

       Construct a table mapping MID to "m=" line for each "m=" line in
       this BUNDLE group.  Note that an "m=" line may only have one MID.

       Construct a table mapping incoming RTP streams (SSRCs) to their
       "m=" line for each "m=" line in this BUNDLE group and for each RTP
       stream explicitly signalled for receiving in that "m=" line.

       Construct a table mapping payload types to "m=" line for each "m="
       line in the BUNDLE group and for each payload type configured for
       receiving in that "m=" line.  If any payload type is configured
       for receiving in more than one "m=" line in the BUNDLE group, do
       not it include it in the table.

    Note that for each of these tables, there can only be one mapping for
    any given key (MID, SSRC, or PT).  In other words, the tables are not
    multimaps.

    As "m=" lines are added or removed from the BUNDLE groups, or their
    configurations are changed, the tables above MUST also be updated.

    Received RTP packets that are syntactically correct are processed by
    the RTP/RTCP protocol implementation for statistics etc.  After this
    processing they need to be routed to the higher layer context
    associated with the "m=" line within the BUNDLE group.  Somewhere in
    the process where an received RTP packet is processed to be delivered
    to the higher layer by RTP the matching step below MUST be performed:

    1.  Reception of an RTP packet for an RTP stream that has an existing
        mapping in the RTP stream to m= line table.  Before proceeding in
        delivering the packet to the higher layer context according to
        the RTP stream to "m=" line mapping table the following checks
        MUST be performed:

        A.  If the packet carries an RTP header extension with a SDES MID
            value that is not in the table mapping MID to "m=" line, then
            do not deliver the RTP packet to higher layers.

        B.  If the packet carries an RTP header extension with a SDES MID
            value that is in the table mapping MID to "m=" line, and the
            value indicates a different "m=" line than the current RTP
            stream to "m=" line mapping table, then update the RTP stream
            to "m=" line mapping.

    2.  Reception of an RTP packet for an RTP stream that has no existing
        mapping to an m= line.  In this case the following actions MUST
        be performed:

        A.  If the packet carries an RTP header extension with a SDES MID
            value that is in the table mapping MID to "m=" line, then
            create an entry in the RTP stream to "m=" line mapping table
            for this RTP stream (SSRC).  Then deliver the RTP packet to
            the "m=" line context of the created mapping and stop.

        B.  If the packet carries a Payload Type that is in the payload
            type table, then create an entry in the RTP stream to "m="
            line mapping table for this RTP stream (SSRC).  Then deliver
            the RTP packet to the "m=" line context of the created
            mapping and stop.

        C.  Otherwise do not deliver the RTP packet to higher layers.
            Note, this includes unknown MID values.

[Here the RTCP part will be added later]

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jan 2017 14:38:08 +0100

Den 2017-01-20 kl. 23:19, skrev Eric Rescorla:
> limited use cases now. Hence the need to support PT now and MID in the
> future

Hi,

I get worried by this text. I have accepted that PT mapping is a 
necessary function to deal with interop of non-WebRTC endpoints. 
However, I don't think MID is something a WebRTC endpoint can wait with 
implementing. BUNDLE mandates MID support, and if one doesn't implement 
it another WebRTC endpoint could attempt to use MIDs and don't provide 
different PTs for two bundled m= audio lines with PT reuse.

So I hope that RTCWEB WG has no intention of softening the need for MID 
support? I think that would invite additional interoperability issues 
and hamper the evolution and usage of WebRTC.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jan 2017 15:24:10 -0800

On Mon, Jan 23, 2017 at 5:38 AM, Magnus Westerlund <
[email-masked]> wrote:

> I get worried by this text. I have accepted that PT mapping is a necessary
> function to deal with interop of non-WebRTC endpoints. However, I don't
> think MID is something a WebRTC endpoint can wait with implementing. BUNDLE
> mandates MID support, and if one doesn't implement it another WebRTC
> endpoint could attempt to use MIDs and don't provide different PTs for two
> bundled m= audio lines with PT reuse.
>
> support? I think that would invite additional interoperability issues and
> hamper the evolution and usage of WebRTC.

That's not what I'm saying. I'm simply saying that we are not in a world
where it is going to MID only and will not be for quite some time.

-Ekr