Subject: Re: [rtcweb] A problem with both A and B

From: Bernard Aboba <[email-masked]>
Date: Fri, 17 May 2013 13:21:47 -0700

It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange).

"Dale R. Worley" <[email-masked]> wrote:

> From: Emil Ivov <[email-masked]>
>
> Both plan A and B currently describe semantics that would require O/A
> exchanges every time a source is added or removed from a session.
> [...]
> Does any of this make any sense?

My understanding (and I'm not tracking everything carefully) is that
this is a bad situation.  I've been accumulating desiderata, and one
that has been on the list for a long time is:

   DES F11  It must be possible to add and remove one way video flows
      within the bundle without requiring an additional offer/answer
      cycle.

Do people think that this is not important?

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 May 2013 13:50:10 -0700

>       within the bundle without requiring an additional offer/answer

I'm not sure why this speaks specifically about video...

> It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange).

This is different I think.  Responding to congestion only requires
that it be possible to stop sending a given stream.  (Or maybe crank
down resolution or frame rate.)

This item talks about addition.  That's an entirely different
proposition.  As long as we assume constraints (you don't need to
re-ICE a new transport for the stream, you don't use new packet types
and codec profiles), this could be possible.  But to get WebRTC to
support this requires API changes.

---

From: "Roni Even" <[email-masked]>
Date: Sat, 18 May 2013 01:33:12 +0300

I agree that it is important and I that it is a reason to look at
http://tools.ietf.org/html/draft-westerlund-mmusic-max-ssrc-01 for adding
RTP steams without having to signal the SSRC in the SDP while using RTCP or
RTP headers for mapping the new streams.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: 17 May, 2013 11:22 PM
To: Dale R. Worley
Cc: [email-masked]
Subject: Re: [rtcweb] A problem with both A and B

It is important. In fact, I would argue it is critical for congestion
control (e.g. removal of simulcast or layered streams by the sender should
not require an O/A exchange).

> Does any of this make any sense?

My understanding (and I'm not tracking everything carefully) is that this is
a bad situation.  I've been accumulating desiderata, and one that has been
on the list for a long time is:

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 06:48:09 +0000

Hi,

I don't think it's a BUNDLE issue whether adding/removing of streams require an O/A exchange or not. It's an SDP, and SDP O/A, issue.

BUNDLE is about sharing a 5-tuple.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 17. toukokuuta 2013 23:50
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [rtcweb] A problem with both A and B

> It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange).

This is different I think.  Responding to congestion only requires that it be possible to stop sending a given stream.  (Or maybe crank down resolution or frame rate.)

This item talks about addition.  That's an entirely different proposition.  As long as we assume constraints (you don't need to re-ICE a new transport for the stream, you don't use new packet types and codec profiles), this could be possible.  But to get WebRTC to support this requires API changes.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 May 2013 12:17:30 -0400

> BUNDLE is about sharing a 5-tuple.

I don't agree.

RTP is already able to support multiple RTP streams sharing an RTP 
session (and 5-tuple).

What BUNDLE is about is describing that in SDP.
And that includes how SDP O/A works.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 07:20:18 +0000

Hi,

> RTP is already able to support multiple RTP streams sharing an RTP session (and 5-tuple).
>

Multiple RTP streams can already share an RTP session today, using multiple SSRCs per m- line :)

If adding a new stream means adding a new m- line, then an SDP O/A is obviously needed - bundle or no bundle.

If adding a new stream means adding a new SSRC, within an existing m-, then it is also an SDP O/A issue - bundle or no bundle.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 May 2013 10:31:52 +0300

> If adding a new stream means adding a new SSRC, within an existing m-, then it is also an SDP O/A issue - bundle or no bundle.

Why is that?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 07:38:37 +0000

Hi,

>> If adding a new stream means adding a new SSRC, within an existing m-, then it is also an SDP O/A issue - bundle or no bundle.

Because, even WITHOUT bundle, you have to answer whether adding a new SSRC (or, whatever mechanism we use to identify a stream) within an existing m- line requires an SDP O/A transaction or not.

Of course, IF we are going to define a BUNDLE specific way of signalling RTP streams, then we of course also need to cover the procedures for adding/removing streams, whether it requires an SDP O/A transaction or not, etc.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 May 2013 10:45:23 +0300

On 21.05.13, 10:38, Christer Holmberg wrote:
> Hi,
> 
>>> If adding a new stream means adding a new SSRC, within an
>>> existing m-, then it is also an SDP O/A issue - bundle or no
>>> bundle.
>> 
>> Why is that?
> 
> Because, even WITHOUT bundle, you have to answer whether adding a new
> SSRC (or, whatever mechanism we use to identify a stream) within an
> existing m- line requires an SDP O/A transaction or not.

OK, I guess I took your statement to mean that adding and removing SSRCs
to m= lines is a matter that cannot be handled without SDP O/A which I
think it isn't (and which is what this thread started with).

I obviously agree that it is not a bundle-specific issue.

Emil

-- 
https://jitsi.org

---

From: Kevin Dempsey <[email-masked]>
Date: Tue, 21 May 2013 09:31:37 +0100

In cases where each m= line has a different port, when a new SSRC is
received usually it is either discarded (when latched to a pre exisiting
SSRC stream that does not stop) or is treated as replacing the previous
SSRC.

When multiplexing is being used it is not obvious whether the new SSRC is
replacing a previous one, or is another separate stream.

I think that in the multiplex case we need something like a virtual
destination port in each RTP packet, such as a RTP header extension or even
UDP over UDP!

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 08:57:30 +0000

Hi,

> In cases where each m= line has a different port, when a new SSRC is received usually it is either discarded (when latched to a pre exisiting SSRC stream that does not stop) or is treated as replacing the previous SSRC.
>
> When multiplexing is being used it is not obvious whether the new SSRC is replacing a previous one, or is another separate stream.
>
> I think that in the multiplex case we need something like a virtual destination port in each RTP packet, such as a RTP header extension or even UDP over UDP!

Perhaps.

But, then we talk more about how to identify/demux a stream, once it has been added.

We would still need to answer whether the actual addition of a new stream requires a SDP O/A transaction :)

Regards,

Christer

Emil

---

From: Kevin Dempsey <[email-masked]>
Date: Tue, 21 May 2013 10:18:25 +0100

Clearly adding a new m= line needs a SDP O/A. So in the multiplex case I
would think that adding another m= line equivalent to a bundle would also
need a SDP O/A.

In the non multiplex case changing to a different source doesn't require a
SDP O/A. However,  unless there is some identifier in the RTP packets that
the receiver knows already, such a change would need to be signalled in the
multiplex case.

On 21 May 2013 09:57, Christer Holmberg <[email-masked]>wrote:

> > When multiplexing is being used it is not obvious whether the new SSRC
> is replacing a previous one, or is another separate stream.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 09:29:22 +0000

Hi,

>Clearly adding a new m= line needs a SDP O/A.

Correct. 

>So in the multiplex case I would think that adding another m= line equivalent to a bundle would also need a SDP O/A.

Yes. In my opinion, adding a new m- line requires an SDP O/A - bundle or no bundle.

> In the non multiplex case changing to a different source doesn't require a SDP O/A. However,  unless there is 
> some identifier in the RTP packets that the receiver knows already, such a change would need to be signalled in the multiplex case.

What do you mean by "non-multiplex"?

1) No bundle, but possibly multiple SSRCs per m- line; or

2) No bundle, and only one SSRC per m- line

Regards,

Christer

On 21 May 2013 09:57, Christer Holmberg <[email-masked]> wrote:
Hi,

Perhaps.

Regards,

Christer

Emil

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 May 2013 12:36:34 +0300

On 21.05.13, 12:18, Kevin Dempsey wrote:
> would think that adding another m= line equivalent to a bundle would
> also need a SDP O/A.
> 
> In the non multiplex case changing to a different source doesn't require
> a SDP O/A.

Note that, unless your are relying on RTCP BYEs, this is due to the
application _assuming_ that the new SSRC is a change. Even if implicit,
this can still be regarded as application specific signalling.

> However,  unless there is some identifier in the RTP packets
> that the receiver knows already, such a change would need to be
> signalled in the multiplex case.

The same assumption and opposite implicit signalling can also work here.
This also seems to be the default assumption suggested by RTP.

Anyways, the point is that it is up to apps to handle this, rather than
having browsers taking care of it through O/A.

Emil

> 
> On 21 May 2013 09:57, Christer Holmberg <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     > In cases where each m= line has a different port, when a new SSRC
>     is received usually it is either discarded (when latched to a pre
>     exisiting SSRC stream that does not stop) or is treated as replacing
>     the previous SSRC.
>     >
>     > When multiplexing is being used it is not obvious whether the new
>     SSRC is replacing a previous one, or is another separate stream.
>     >
>     > I think that in the multiplex case we need something like a
>     virtual destination port in each RTP packet, such as a RTP header
>     extension or even UDP over UDP!
> 
>     Perhaps.
> 
>     [email-masked] <mailto:[email-masked]>

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 May 2013 16:13:52 -0400

> If adding a new stream means adding a new SSRC, within an existing m-, then it is also an SDP O/A issue - bundle or no bundle.

AFAIK there is wide agreement that an RTP *session* can carry multiple 
RTP streams.

An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP 
session. There is disagreement whether it is permissible for the 
resulting RTP session to carry multiple RTP streams. The specs are 
ambiguous on this point. Clearly there are well identified cases where 
they do, and we aren't likely to rule those incorrect. Its also clear 
that some of these cases start out sending a single SSRC, and then later 
"add" another. (It may actually be a substitution.)

So it seems clear to me that you may add an RTP stream to an RTP session 
described by an m-line without doing another O/A exchange.

What is lacking in such cases is a mechanism for describing the role and 
intent of each RTP stream in the RTP session. In some cases it is 
possible to get by without this, by assuming that the two ends have 
consistent *assumptions* about how to infer the role/intent. But there 
are many cases where this isn't enough.

Extra SDP syntax has been defined in an ad hoc way to get at bits and 
pieces of this problem. E.g., the a=ssrc attribute. What has already 
been defined doesn't seem suficient for all the new cases we are no 
discussing.

BUNDLE is *another* proposal for addressing part or all of this problem. 
But BUNDLE brings along another problem: for BUNDLE to be useful, it 
must be possible to associate each RTP packet with one of the bundled 
m-lines. Without BUNDLE we don't have that problem.

To summarize:

- without bundle, we need a mechanism for describing the role/intent
   of each RTP stream in the RTP session. *If* we choose to describe
   that with SDP, then we need an O/A exchange each time we add
   an RTP stream.

- with BUNDLE and Plan A, the assumption is that each m-line in the
   bundle describes a single RTP stream, and so the other SDP stuff
   in that media section can be used to describe the role/intent of
   that RTP stream. By design this requires a new m-line for each
   RTP stream, so adding one requires an O/A. We then assume that there
   is enough stuff in each media section to decide which m-line each
   packet should be associated with.

- with BUNDLE and Plan B, there may be multiple RTP streams per
   m-line. As in Plan A we need to associate each packet with one of
   the m-lines. Like the no-bundle case we still need some mechanism
   to describe the role/intent if the individual RTP streams.
   In some cases (e.g., a=ssrc) the same info that classifies to
   an m-line may also specify the role of each stream. That case
   also leads to an O/A for each stream add.

   If you have a non-SDP way to discover the role/intent of each
   RTP stream, and you use a way of classifying to one of the
   bundled m-lines *without* enumerating every RTP stream, then
   you can perhaps avoid an O/A for each stream add. E.g., if you
   just bundle one audio and one video m-line, and use PT to
   distinguish those.

Note: in above I said Plan A uses an m-line for each RTP stream. That 
isn't always the case. There are some cases (at least in clue) where 
each m-line is intended to describe a "flow" (clue capture) that may 
correspond to different RTP streams over time, or that might include 
supporting FEC streams, etc. Depending on your assumptions about this 
case it may start to take on some of the characteristics of Plan B.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 May 2013 15:02:59 -0700

This is an excellent summary.

On 21 May 2013 13:13, Paul Kyzivat <[email-masked]> wrote:
> AFAIK there is wide agreement that an RTP *session* can carry multiple RTP
> streams.
>
> session. There is disagreement whether it is permissible for the resulting
> RTP session to carry multiple RTP streams.

Nitpick:

As I understand it, there's a disagreement whether O/A allows for
creating multiple streams *in each negotiated direction*... as
determined by a=sendrecv/sendonly/recvonly/inactive.

In the Plan A view, there are 0 or 1 streams in the each "negotiated
open" direction.  The SSRC might change over time, but it maps to the
same rendering.

In the Plan B view, there are 0 or more streams in the each
"negotiated open" direction.  I believe that the assumption is that
every SSRC is a different rendering (in the absence of a=ssrc:...
previous-ssrc:...).

> The specs are ambiguous on this
> point. Clearly there are well identified cases where they do, and we aren't
> likely to rule those incorrect. Its also clear that some of these cases
> start out sending a single SSRC, and then later "add" another. (It may
> actually be a substitution.)

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 22 May 2013 10:50:55 +0200

I think this was a good summary.

But regarding "a mechanism for describing the role and intent of each 
RTP stream in the RTP session.", do we really need that? Isn't the 
combination of ssrc and the msid draft sufficient?

Together the clearly identify how ssrc's map into PC-streams and 
PC-tracks, and the application can convey the remaining info (e.g. 
PC-stream xx represents the speaker audio+video, yy the room video etc.) 
needed in any way it likes .

Stefan

On 2013-05-21 22:13, Paul Kyzivat wrote:
>>>> I don't think it's a BUNDLE issue whether adding/removing of streams
>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue.
>>>>
>> If adding a new stream means adding a new SSRC, within an existing m-,
>> then it is also an SDP O/A issue - bundle or no bundle.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 11:31:18 -0400

> open" direction.  The SSRC might change over time, but it maps to the

So your nit is that for sendrecv there might be *two* (one each way) 
rather than just one?

Sure, *for BUNDLE* I agree with that.

I don't agree that is the agreed meaning of an unbundled m-line.

> every SSRC is a different rendering (in the absence of a=ssrc:...

Or some other attributes that affect it.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 11:39:02 -0400

> needed in any way it likes .

My statements were not intended to be rtcweb-specific. The bundling 
stuff is going to be a more general SDP extension. IMO the problems that 
rtcweb and clue have encountered that need this are just the tip of the 
iceberg.

My point about the role/intent is that the application must have some 
means to determine this. It doesn't always need to be in SDP. But the 
old approach that is mostly based on the cases being so simple that it 
is always obvious without signaling are now breaking down. And in the 
case of SIP apps there are few mechanisms to build on other than SDP.

	Thanks,
	Paul

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 22 May 2013 16:08:29 +0000

> rtcweb and clue have encountered that need this are just the tip of the

You're probably right in this (and I have to admit my comments are 
usually quite rtcweb centric).

> case of SIP apps there are few mechanisms to build on other than SDP.

I agree to the above.

But taking my usual rtcweb shortcut, could we imagine that rtcweb solves 
this with something like msid (i.e. you just provide the identity of 
each stream, and leave it up to the app to exchange what content it 
represents)?

Once we have something that is usable in a SIP world (an agreed way to 
signal this in SDP), perhaps the web app could add that to the SDP. (Not 
that clean, but could work).

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 May 2013 01:03:59 -0700

Great Summarization Paul.

My 2 cents

SDP O/A enables parties in a session to decide on a compatible view of the
session. This implies setting up appropriate transport  , media stack
(encoders, decoders) context and alike in a way that the parties involved
can have a successful session.

Regardless of Plan A or Plan B , any modifications to session parameters (
adding new source, removing a source, modifying existing parameters) that
impacts resources managed, needs to be negotiated and O/A helps in this
regard.

Thanks
Suhas

---

From: Kevin Dempsey <[email-masked]>
Date: Thu, 23 May 2013 09:40:27 +0100

Adding or removing a source generally doesn't need a SDP O/A. The offerer
has indicated where media of a given type should be sent. The answerer can
arrange for any source it wants to send to that destination. It is unusual
for an answerer to send more that one SSRC at a time, but changing  the
source (and SSRC) is not uncommon.

How the offerer handles the change of SSRC, or receiving multiple SSRCs is
application specific. I believe most SIP endpoints I have used render only
one SSRC per m= line at a time and have some mechanism to switch SSRC when
the one they were rendering stops.

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 May 2013 02:40:00 -0700

Hey Kevin,

On Thu, May 23, 2013 at 1:40 AM, Kevin Dempsey <[email-masked]>wrote:

> source (and SSRC) is not uncommon
>

%Suhas% True in some cases and False in some.

What if the new source produces pre-encoded stream that is not been
negotiated within the current session ?
example: video m=line with VP8 is setup and H.264 encoded camera is added
as new source. This needs a O/A negotiation for the appropriate decoder
context to be setup on the receiver side
OR similarly
a high resolution video layer/feed or  a different ptime based audio source
is added or a sendonly source is added.

> the one they were rendering stops.

%Suhas% Agreed. A change in SSRC or totally new SSRC(s) seen at the
end-point can be handled in a App Specific way.

Thanks
Suhas

>> SDP O/A enables parties in a session to decide on a compatible view of
>> the session. This implies setting up appropriate transport  , media stack
>> Regardless of Plan A or Plan B , any modifications to session parameters
>> ( adding new source, removing a source, modifying existing parameters) that
>>> >>>> If adding a new stream means adding a new m- line, then an SDP O/A
>>> is
>>> >>>> obviously needed - bundle or no bundle.
>>> >>>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 May 2013 12:43:58 +0300

On 23.05.13, 12:40, Suhas Nandakumar wrote:
> example: video m=line with VP8 is setup and H.264 encoded camera is
> added as new source. This needs a O/A negotiation for the appropriate
> decoder context to be setup on the receiver side

Obviously this does require a new O/A but I don't see how that case is
related to adding and removing SSRCs which do not require O/A exchanges.

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 09:49:07 +0000

Hi,

>Adding or removing a source generally doesn't need a SDP O/A. The offerer has indicated where media of a given type should be sent. 
>The answerer can arrange for any source it wants to send to that destination. It is unusual for an answerer to send more that one SSRC at a time,

You can have multiple simultaneously sent media streams, each with its own SSRC.

> How the offerer handles the change of SSRC, or receiving multiple SSRCs is application specific. I believe most SIP endpoints I have used render only one SSRC
> per m= line at a time and have some mechanism to switch SSRC when the one they were rendering stops.

SIP endpoints today can map the media to the associated m- line because a unique port is used.

With BUNDLE, even if you only use one SSRC per m- line, you still need to be able to associate it with an m- line.

Regards,

Christer

My 2 cents

SDP O/A enables parties in a session to decide on a compatible view of the session. This implies setting up appropriate transport  , media stack (encoders, decoders) context and alike in a way that the parties involved can have a successful session.

Regardless of Plan A or Plan B , any modifications to session parameters ( adding new source, removing a source, modifying existing parameters) that impacts resources managed, needs to be negotiated and O/A helps in this regard.

Thanks
Suhas

On Wed, May 22, 2013 at 9:08 AM, Stefan Håkansson LK <[email-masked]> wrote:

I agree to the above.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 09:51:12 +0000

Hi,

> Obviously this does require a new O/A but I don't see how that case is related to adding and removing SSRCs which do not require O/A exchanges.

It depends on whether you need to signal the SSRC to the remote endpoint for demux purpose.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 May 2013 13:44:24 +0300

> It depends on whether you need to signal the SSRC to the remote endpoint for demux purpose.

Exactly, and since I've been arguing that you don't ... :)

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 11:04:07 +0000

Hi,

>>>> added as new source. This needs a O/A negotiation for the 
>>>> appropriate decoder context to be setup on the receiver side
>>>

Ok. So, maybe I've missed it, but how do you suggest the received media is:

1. associated with the m- line; and
2. demuxed

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 May 2013 14:08:45 +0300

> 1. associated with the m- line; and

Payload type. (And you either drop bundle when you run out of those

> 2. demuxed

Based on SSRC and application specific signalling. (Presuming that by
demuxed you mean identified)

Emil

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 11:20:27 +0000

Hi,

>>>>>> What if the new source produces pre-encoded stream that is not 
>>>>>> been negotiated within the current session ?
>>>>>> example: video m=line with VP8 is setup and H.264 encoded camera 
>>>>>> is added as new source. This needs a O/A negotiation for the 

My understanding is that people have indicated that the payload type value space is too small. 

Or, did we agree it isn't? :)

>> 2. demuxed
>
> Based on SSRC and application specific signalling. (Presuming that by demuxed you mean identified)

Yes.

I am not sure what you mean by application specific signaling, but for SDP we do need to describe in BUNDLE how it is done.

Or, do you assume, at any given point, a single SSRC per m- line?

Regards,

Christer

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 24 May 2013 13:34:15 +0200

> Or, do you assume, at any given point, a single SSRC per m- line?

Application specific signaling like RFC 4575 - A Session Initiation 
Protocol (SIP) Event Package for Conference State:

        5.8.4 <http://tools.ietf.org/html/rfc4575#section-5.8.4>. <src-id>

    The <src-id> element, if applicable, carries the information about
    the actual source of the media.  For example, for Real-time Transport
    Protocol (RTP) / RTP Control Protocol (RTCP) [13  <http://tools.ietf.org/html/rfc4575#ref-13>] media streams, the
    value MUST contain the synchronization source (SSRC) identifier value
    generated by the endpoint for the stream it sends.

Best regards
Sergio

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 May 2013 14:35:32 +0300

> Or, did we agree it isn't? :)

This would be a problem if it meant that exhausting it would prevent you
from using any more more formats. This is not the case. Exhausting the
PT value space only means that you have to start a second bundle (or
stop using bundle).

Note that depending on how big you are willing to accept the PT space is
this would either be relatively rare case (if you only want to use 32
values) or a quite unlikely one (if you are brave enough to allocate all
96).

Also note that dropping bundle in such cases would only mean a slightly
higher connection establishment time (we still have trickle ICE) and a
negligibly higher overall use of port numbers, so I don't think we
should consider this a big deal.

> I am not sure what you mean by application specific signaling, but for SDP we do need to describe in BUNDLE how it is done.

Why do you need to describe this? Applications could be sending such
info through SIP and RRC 4575, or XMPP and XEP-0298 or some completely
different signalling mechanism.

> Or, do you assume, at any given point, a single SSRC per m- line?

No. I assume no such thing. I am actually insisting on the opposite! :)

Cheers,
Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 11:44:40 +0000

Hi,

> This would be a problem if it meant that exhausting it would prevent you from using any more more formats. This is not the case. 
> Exhausting the PT value space only means that you have to start a second bundle (or stop using bundle).
>
> Note that depending on how big you are willing to accept the PT space is this would either be relatively rare case (if you only want to use 32
> values) or a quite unlikely one (if you are brave enough to allocate all 96).
>
> Also note that dropping bundle in such cases would only mean a slightly higher connection establishment time (we still have trickle ICE) and a 
> negligibly higher overall use of port numbers, so I don't think we should consider this a big deal.

If the community can agree on PT usage, fine. My understanding is that we currently do not have such agreement :)

> Why do you need to describe this? Applications could be sending such info through SIP and RRC 4575, or XMPP and XEP-0298 or some completely different signalling mechanism.
>

If the community can agree that, from a BUNDLE perspective, we don't need to care about SSRC values, fine :)

However, from a more general SDP perspective, it is possible to indicate SSRC specific values, using the SDP ssrc attribute. Now, that assumes that those SSRCs will actually be used, and not changed (at least not without associated signaling).

Regards,

Christer

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 13:28:22 -0400

I'm confused.  The "no plan" plan still requires signaling, it's just not
O/A.  So what are you saving?