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

[Emil Ivov <[e-mail]>]

On 23.05.13, 14:20, Christer Holmberg wrote:
> 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 
>>>>>>> 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.
>>>>>
>>>>> 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 ... :)
>>>
>>> Ok. So, maybe I've missed it, but how do you suggest the received media is:
>>>
>>> 1. associated with the m- line; and
>>
>> Payload type. (And you either drop bundle when you run out of those
> 
> My understanding is that people have indicated that the payload type value space is too small. 
> 
> 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.

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

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