Subject: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Mar 2016 14:23:30 +0100

Hi,

draft-ietf-mmusic-sdp-bundle-negotiation-27 in section 10.1.2 states:

   Multiple bundled "m=" lines might represent RTP based media.  As all
   RTP based media associated with a BUNDLE group belong to the same RTP
   session, in order for a given payload type value to be used inside
   more than one bundled "m=" line, all codecs associated with the
   payload type number MUST share an identical codec configuration.
   This means that the codecs MUST share the same media type, encoding
   name, clock rate and any parameter that can affect the codec
   configuration and packetization.
   [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
   attribute values must be identical for all codecs that use the same
   payload type value.

This basically states that there cannot be two different codecs with
same payloadType (or same codec with different codec parameters)
within two m= sections sharing the same "transport".

Let me please describe a "real" use-case:

* SFU server.
* Alice wants to send audio "opus" with payload 100 and SSRC 1111.
* Bob wants to send audio "g722" with payload 100 and SSRC 2222.
* Carol just wants to receive audios from Alice and Bob over a single
transport (BUNDLE).

When Carol connects with the SFU she negotiates a single ICE/DTLS
transport, and the SFU notifies Carol about two receiving audio tracks
(from Alice and Bob):

1) mid: alice-audio,  codec: opus,  payload: 100, ssrc: 1111
2) mid: bob-audio,   codec: g722,  payload: 100, ssrc: 2222

This would mean that Carol receives an SDP with two "m=audio"
sections using BUNDLE:

  m=audio [...] 100
  a=sendonly
  a=mid:alice-audio
  a=rtpmap:100 opus/48000/2
  a=ssrc:1111 cname:foo
  [...]
  m=audio [...] 100
  a=sendonly
  a=mid:bob-audio
  a=rtpmap:100 g722/48000
  a=ssrc:2222 cname:bar
  [...]

What is the problem here? Why is having the same payload type (100) a problem?

To be clear, Carol can demux the incoming RTP:

* By matching the RTP MID header (if present).
* By matching the RTP SSRC (1111 => 'alice-audio', 2222 => 'bob-audio').

There is no need to check the RTP payload in order to retrieve the
appropriate m= section. And worse: this constraint forces the SFU
developer to rewrite the payload type sent by the participants in a
SFU room so all of them are different.

IMHO there is no real justification for this constraint, it provides
nothing useful, and it limits and makes worse some common scenarios.
So I ask for such a constraint to be removed from the draft.

Thanks a lot.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Mar 2016 14:44:21 +0100

Hi Inaki,

The RTP Payload type field is defined and used under the assumption that 
is common across all SSRC within an RTP session as observed a particular 
point. This is really coming from RFC 3550 and RFC 3551. For example in 
Section 3 of RFC 3551 the following is written:

    These mechanisms
    associate the registered name of the encoding/payload format, along
    with any additional required parameters, such as the RTP timestamp
    clock rate and number of channels, with a payload type number.  This
    association is effective only for the duration of the RTP session in
    which the dynamic payload type binding is made.  This association
    applies only to the RTP session for which it is made, thus the
    numbers can be re-used for different encodings in different sessions
    so the number space limitation is avoided.

Note, I did write in a particular point, otherwise RTP middleboxes would 
not be able to translate the values for specific receivers.

And this is not only a specification issue. If you look at the RTCP 
processing one there are certain calculations that requires one to know 
the RTP payload type and things like the RTP clock rate to correctly 
process. The RTP specifications have been written under the assumption 
that these values are set on RTP session scope, rather than specific SSRCs.

I would also note that there are in existence RTP based applications 
that really utilize the fact that PT values are configured on RTP 
session level, enabling new SSRCs to be used without prior signalling.

 From my perspective, the SIP/SDP usages of RTP prior to WebRTC and CLUE 
has been so constrained that this fact that PTs are set on RTP Session 
level has not mattered at all, as one has had basically one RTP stream 
per direction and RTP session. Now we have multiple RTP streams per 
direction and RTP session and it does matter.

I don't see that we can change this without large amount of work. There 
are both specification assumptions as well as implementation assumptions 
on that PT are set on RTP session level. In addition such a change would 
make some existing RTP usages impossible. Resulting in that a change 
have significant implications, which requires both consideration and 
need for liaison with affected user groups.

I would also note that this topic if you want to continue discuss it 
should involve AVTCORE WG.

Cheers

Magnus Westerlund
AVTCORE WG chair

-- 

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: Tue, 8 Mar 2016 17:09:34 +0100

Thanks Magnus, some comments inline:

2016-03-08 14:44 GMT+01:00 Magnus Westerlund <[email-masked]>:
> processing one there are certain calculations that requires one to know the
> RTP payload type and things like the RTP clock rate to correctly process.
> The RTP specifications have been written under the assumption that these
> values are set on RTP session scope, rather than specific SSRCs.
>
> I would also note that there are in existence RTP based applications that
> really utilize the fact that PT values are configured on RTP session level,
> enabling new SSRCs to be used without prior signalling.
>
> From my perspective, the SIP/SDP usages of RTP prior to WebRTC and CLUE has
> been so constrained that this fact that PTs are set on RTP Session level has
> not mattered at all, as one has had basically one RTP stream per direction
> and RTP session. Now we have multiple RTP streams per direction and RTP
> session and it does matter.

While I understand the good rationale you provide, I think we should
evolve. WebRTC is no longer "bidirectional 1-to-1 audio streams".

> I don't see that we can change this without large amount of work. There are
> both specification assumptions as well as implementation assumptions on that
> PT are set on RTP session level. In addition such a change would make some
> existing RTP usages impossible. Resulting in that a change have significant
> implications, which requires both consideration and need for liaison with
> affected user groups.

OK, just please let me a simple question:

If 100 participants join the same SFU conference and all of them send
VP8 codec with payload 100 and same parameters, then each participant
will be provided with a SDP containing 100 (or 101) m=video sections
with a=sendonly, and each m=video MUST have a different payload type
(rewritten by the SFU) for the VP8 codec (for the same rationale given
above, as they belong to different video streams from different
participants).

...but there are just 96-127 dynamic payload values.

So in case of participants sending audio and video, should we state
that a WebRTC SFU conference can just handle (127-96+1)/2 = 16
participants?

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Mar 2016 17:39:16 +0100

2016-03-08 14:44 GMT+01:00 Magnus Westerlund <[email-masked]>:
> I would also note that this topic if you want to continue discuss it should
> involve AVTCORE WG.

Please, let me know which exact subject should I report to AVTCORE WG.
AFAIU draft-ietf-mmusic-sdp-bundle-negotiation is being done here in
MMUSIC WG.

If what I say in my previous email is true (maximum of 16 audio+video
participants in a WebRTC multi-stream SFU conference) I think there is
a big problem in BUNDLE, and hence in MMUSIC.

Thanks a lot.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2016 19:05:10 +0000

Hi,

Going back to your initial example:

  m=audio [...] 100
  a=sendonly
  a=mid:alice-audio

When we discussed payload type mappings and RTP sessions, it was said that, in a sendonly m- line, the payload type values are simply "place holders", the remote endpoint will tell you what values it want to receive.

So, in your case, you can't say "I am going to send you with PT 100". The answerer is going to say what it wants to receive, so in your case it may e.g. chose 98 for alice-audio and 99 for bob-audio.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2016 19:11:24 +0000

Hi,

>AFAIU draft-ietf-mmusic-sdp-bundle-negotiation is being done here in MMUSIC WG.
>
>If what I say in my previous email is true (maximum of 16 audio+video participants in a WebRTC multi-stream SFU conference) I think there is a big problem in BUNDLE, and hence in MMUSIC.

Why do you think this is BUNDLE specific? If you think it should be allowed to use the same PT value for different codecs within a BUNDLE group, shouldn't it then also be allowed to use the same PT value for different codecs within a single m- line? In both cases we are talking about a single RTP session, carried over a single transport.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Mar 2016 00:34:09 +0100

> So, in your case, you can't say "I am going to send you with PT 100". The answerer is going to say what it wants to receive, so in your case it may e.g. chose 98 for alice-audio and 99 for bob-audi…

So I tell you that I will send N codecs with SSRC 1234 and you tell me
which payload I should use. This makes no sense IMHO. SDP was designed
for 1-to-1 symmetric (audio) streams. When it comes to multi-stream (I
send my audio and video and receive multiple audio and video streams
from others) SDP becomes a nightmare.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Mar 2016 00:40:52 +0100

> Why do you think this is BUNDLE specific? If you think it should be allowed to use the same PT value for different codecs within a BUNDLE group, shouldn't it then also be allowed to use the same PT…

There is no way in SDP-land to specify which payload will be carried
over which SSRC within a m= section. So SSRC is the only way to
properly demux it. In fact, when we see something like:

a=rtmap:100 opus/48000/2
a=rtmap:96 rtx/9000
a=fmtp:96 apt=100
a=ssrc-group:FID 111111 222222
a=ssrc:111111 cname foo
a=ssrc:222222 cname foo

That means: opus will be sent over the SSRC 111111 or 222222, and rtx
will be sent over SSRC 222222 or 111111, but we don't even know which
SSRC will be used until the first RTP packet is received.

So, SDP does not allow sending different codecs with same PT over the
same m= section given that all the "audio/video" codecs will be
carried over the *same* SSRC stream.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Mar 2016 00:46:42 +0100

>>>If what I say in my previous email is true (maximum of 16 audio+video participants in a WebRTC multi-stream SFU conference) I think there is a big problem in BUNDLE, and hence in MMUSIC.

Let me please insist on my question, because I don't understand yet
how to implement it:

If Alice and Bob send h264 with same exact parameters, and Carol
wishes to receive both video streams over the same transport (so 2
m=audio sections using BUNDLE), how should those m=audio sections look
like? Each one will use specific SSRC values but, can both have the
same PT for h264 or not?

If not, then WebRTC 1.0 just allows SFU conferences of 16 participants
(assuming each participant sends audio and video).

If I'm wrong, please let me know how such a SDP received by Carol should look.

Thanks a lot.

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 8 Mar 2016 20:27:19 -0800

I don't understand the concern here. If both m= lines have the same H.264
parameters, the same PT can be used.

On Tue, Mar 8, 2016 at 3:46 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> participants in a WebRTC multi-stream SFU conference) I think there is a
> big problem in BUNDLE, and hence in MMUSIC.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 07:01:19 +0000

Hi,

>> When we discussed payload type mappings and RTP sessions, it was said that, in a sendonly m- line, the payload 
>> type values are simply "place holders", the remote endpoint will tell you what values it want to receive.
>>
>> So, in your case, you can't say "I am going to send you with PT 100". The answerer is going to say what it wants 
>> >> to receive, so in your case it may e.g. chose 98 for alice-audio and 99 for bob-audio.
>
> So I tell you that I will send N codecs with SSRC 1234 and you tell me which payload I should use. This makes no sense IMHO. SDP was designed for 1-to-1 symmetric (audio) streams.

Section 5.1 of RFC 3264 says:

   "For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets
   the offerer is planning to send for that codec."

...followed by:

   "However, for sendonly and sendrecv streams, the answer might indicate
   different payload type numbers for the same codecs, in which case,
   the offerer MUST send with the payload type numbers from the answer."

So, for sendonly, the offerer can indicate the values it is "planning" to use, but the answerer will have the final say.

> When it comes to multi-stream (I send my audio and video and receive multiple audio and video streams from others) SDP becomes a nightmare.

SDP Offer/Answer has been a nightmare from day one :)

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Mar 2016 11:25:38 +0100

> AFAIU draft-ietf-mmusic-sdp-bundle-negotiation is being done here in

The assumption that PTs are set on RTP session level, is an AVTCORE 
assumption, part of the RFCs that WG has responsibility for.

> a big problem in BUNDLE, and hence in MMUSIC.
<

My understanding is that this is the error in your understanding of 
BUNDLE. As long as the PT=100 all have the identical configuration they 
can share the PT over multiple m= blocks in the same BUNDLE.

Section 10.1.1 of Bundle-27 draft:

    o  A specific payload type value can be used in multiple bundled "m="
       lines if each codec associated with the payload type number shares
       an identical codec configuration [Section 10.1.2].

Cheers

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Mar 2016 11:57:18 +0100

> So, for sendonly, the offerer can indicate the values it is "planning" to use, but the answerer will have the final say.

OK. But what would happen when such a a=sendrecv becomes a=sendonly
and later a=recvonly (due "hold" feature for example)? Also note that,
depending who sends the re-offer, payload types may have to change
within the same RTP "session".

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Mar 2016 12:00:41 +0100

2016-03-09 11:25 GMT+01:00 Magnus Westerlund <[email-masked]>:
> My understanding is that this is the error in your understanding of BUNDLE.
> As long as the PT=100 all have the identical configuration they can share
> the PT over multiple m= blocks in the same BUNDLE.
>

I know that Magnus, but what you stated above basically means that
some RTP middleboxes just use the PT to match streams (ignoring the
SSRC) and also that some RTCP matching rules use the PT as well.

So, the fact that we have 20 bundled m=lines with same PT and codec
configuration still worries me, because each of those PT belongs to a
separate stream. How will the "legacy" RTP middlebox identify the
proper stream by just checking the PT if there are multiple streams
using the same PT? Why is not that a problem just because all the
codec sharing PT have the same configuration? That's what I don't yet
understand.

Thanks a lot.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Mar 2016 12:01:20 +0100

> parameters, the same PT can be used.

Hi Justin, just please check my last reply to Magnus regarding this subject.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 11:40:01 +0000

Hi,

>OK. But what would happen when such a a=sendrecv becomes a=sendonly and later a=recvonly (due "hold" feature for example)? 
>Also note that, depending who sends the re-offer, payload types may have to change within the same RTP "session".

If I could decide, endpoints would always indicate what they want to receive - even if they don't intend to receive anything (in case of inactive or sendonly).

Then, when/if you change the direction, the negotiation is already done, and you can start send/receive based on what you previously negotiated.

But, to answer your question: I don't see what the problem is. If there is an O/A where you will start receiving media, you will simply indicate what PTs you want to receive.

Regards,

Christer

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Mar 2016 23:35:56 +0000

> On 8 Mar 2016, at 23:34, Iñaki Baz Castillo <[email-masked]> wrote:
> 
> for 1-to-1 symmetric (audio) streams.

No, SDP was designed to advertise multiparty multicast conferences on the Mbone, in declarative mode, using SAP for session discovery. Use with SIP and offer/answer came later.

> When it comes to multi-stream (I

-- 
Colin Perkins
https://csperkins.org/

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 9 Mar 2016 15:51:25 -0800

On Wed, Mar 9, 2016 at 3:35 PM, Colin Perkins <[email-masked]> wrote:

> >> When we discussed payload type mappings and RTP sessions, it was said
> that, in a sendonly m- line, the payload type values are simply "place
> holders", the remote endpoint will tell you what values it want to receive.
> >>
> >> So, in your case, you can't say "I am going to send you with PT 100".
> The answerer is going to say what it wants to receive, so in your case it
> may e.g. chose 98 for alice-audio and 99 for bob-audio.
> >
> No, SDP was designed to advertise multiparty multicast conferences on the
> Mbone, in declarative mode, using SAP for session discovery. Use with SIP
> and offer/answer came later.
>
>
​So that's how we got into this m... I mean, thanks for the tidbit of
history.  It's inter​esting.  Do you have link to a place where the history
is written down?  If not, could you right it down?  I'm seriously
interested to know the history a bit to know how we got here.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Mar 2016 00:02:29 +0000

> On 9 Mar 2016, at 23:51, Peter Thatcher <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 9, 2016 at 3:35 PM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 8 Mar 2016, at 23:34, Iñaki Baz Castillo <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > 2016-03-08 20:05 GMT+01:00 Christer Holmberg <[email-masked] <mailto:[email-masked]>>:
> ​So that's how we got into this m... I mean, thanks for the tidbit of history.  It's inter​esting.  Do you have link to a place where the history is written down?  If not, could you right it down?  I'm seriously interested to know the history a bit to know how we got here.

ftp://ftp.isi.edu/isi-pubs/rs-92-293.pdf <ftp://ftp.isi.edu/isi-pubs/rs-92-293.pdf> might be an interesting starting point. Or old MMUSIC minutes (this was already ongoing discussion in MMUSIC at IETF 37, which was my first meeting).

-- 
Colin Perkins
https://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Mar 2016 10:46:53 +0100

> codec sharing PT have the same configuration? That's what I don't yet

Your middlebox will have to do rewrite of the PT numbers to align the PT 
usage between one particular conference participant (endpoint) and the 
middlebox. You have to provide a consistent configuration between all 
RTP streams in the RTP session's leg between that endpoint and the 
middlebox. Yes, this is not optimal, but SDP in Offer/Answer context is 
lacking features for forcing the different endpoints to use a common 
configuration.

Cheers

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 10 Mar 2016 23:24:30 +0100

> If I could decide, endpoints would always indicate what they want to receive - even if they don't intend to receive anything (in case of inactive or sendonly).

I don't agree. If I'm going to send something to you it is easier if I
just define what I'm gonna send. Anyhow, the "issue" is that SDP O/A
states that the offerer decides which SSRC it will use but the
answerer defines which payload types the offerer must send.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 08:34:26 +0000

Hi,

>>If I could decide, endpoints would always indicate what they want to
>>receive - even if they don't intend to receive anything (in case of
>>inactive or sendonly).
>

I agree. But, back in the days we were told that SIP and SDP O/A are so
cool, and superior to e.g. H.323, because you only need to indicate what
you can receive…

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 17 Mar 2016 09:54:16 +0100

> cool, and superior to e.g. H.323, because you only need to indicate what

Fine and cool for 1-1 bidirectional and symmetric streams. No longer
true for current more advanced needs.

I just hope that BUNDLE is a required step in order to separate each
RTP "sender" and RTP "receiver" within a RTP session, so in the future
we can get rid of SDP and design a proper RTP parameters based API for
WebRTC.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 09:09:18 +0000

Hi,

>> you can receiveŠ

That is not the purpose of BUNDLE. The purpose is to be able to negotiate
multiplexed media on a single RTP session - using existing rules and
concepts when it comes to RTP sessions, usage of PT values etc.

If we want to change the rule saying that PT values must be unique per
codec/codec configuration, I think that¹s a separate task.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 17 Mar 2016 10:30:30 +0100

2016-03-17 10:09 GMT+01:00 Christer Holmberg <[email-masked]>:
> multiplexed media on a single RTP session

- "RTP session" == stuff carried over a single transport (let's assume
rtcp-mux always).

- "media" == audio / video / data, which can be sent and/or received.

So yes, BUNDLE somehow allows defining each RTP sender and/or receiver
in a separate m= section.

> codec/codec configuration, I think that¹s a separate task.

We can't do that because there are a lot of legacy and very expensive
RTP middleboxes made in 20th century that miraculously are suitable
for WebRTC even if they don't even know what a SSRC is. And they must
work without any code update!

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 09:46:51 +0000

Hi,

>in a separate m= section.

Sure, but from a BUNDLE perspective the m- lines still only represent
multiplexed flows within a single RTP session.

Regards,

Christer

---

From: Colin Perkins <[email-masked]>
Date: Thu, 17 Mar 2016 10:30:37 +0000

> On 17 Mar 2016, at 09:30, Iñaki Baz Castillo <[email-masked]> wrote:
> 

No, RTP session == shared SSRC space [RFC 3550, Section 3, Page 10]. RTCP mux is irrelevant for whether there is a single RTP session or not, and an RTP session can span multiple transports.

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Mar 2016 11:34:32 -0400

> No, RTP session == shared SSRC space [RFC 3550, Section 3, Page 10]. RTCP mux is irrelevant for whether there is a single RTP session or not, and an RTP session can span multiple transports.

I'm not an "RTP person", so it has taken me a long time to "get" this.

What I have learned is that there is a mismatch between SDP, O/A, and 
RTP. In spite of what you might easily infer from 4566 and 3264, O/A 
does *not* negotiate the establishment of RTP Sessions (as defined in 
3550) between the offerer and the answerer. That *might* be the result. 
Or it may be that the result is one end being joined into a preexisting 
RTP session involving other participants.

Because of that, the work on better defining the rules for PT use in 
offers and answers turned out to be a lot harder than I expected. It 
can't just focus on making 3264 unambiguous in its own right. It has to 
deal with the actual rules of 3550. And IIUC, when this is done it 
appears that the result may conflict with current practice in some 
implementations. I don't see any painless way out of this.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Mar 2016 11:37:50 -0400

> we can get rid of SDP and design a proper RTP parameters based API for

It sounds like you are asking to restart the work on SDPng. I doubt that 
is going to happen. The problems it encountered haven't gone away.

Maybe it would be possible with WebRTC.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 17 Mar 2016 16:53:45 +0100

2016-03-17 16:37 GMT+01:00 Paul Kyzivat <[email-masked]>:
> It sounds like you are asking to restart the work on SDPng. I doubt that is
> going to happen. The problems it encountered haven't gone away.
>

I think that SDP is a burden for WebRTC that makes it difficult for
developers to express what they really want to express (which
basically is "I want to send this audio and this video, now tell me
what you wish to send me"). Instead on focusing on media streams being
sent and received over one or more "transports" we must deal with
"symmetric" negotiations designed for 1-1 audio communications.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Mar 2016 11:59:53 -0400

> "symmetric" negotiations designed for 1-1 audio communications.

ISTM that is what they had in mind with 3264 and SDP.

This breaks down the first time that you want to set up a conference. At 
that point it ceases to be 1:1.

	Thanks,
	Paul