Re: [rtcweb] No Plan

Hey Roni,

On 03.06.13, 13:29, Roni Even wrote:
> Hi,
> I read the draft and the email thread and I think I have similar questions
> to the ones Cullen made.
> My understanding was that the proposal is to  do one SDP offer/ answer
> exchange  and add remove streams using other means (not specified)

Yes, this is exactly it.

> I looked at the offer example is section 3 and it has
>
> a=max-send-ssrc:{*:1}                      // declaring maximum
>     a=max-recv-ssrc:{*:4}                     // number of SSRCs
>
> I have some clarifying questions?
>
> 1. Is the proposal to always offer max-send-ssrc=1?
>
> 2. What is the answer in this case can it be max-send-ssrc=4?

The max-ssrc in the SDP was just an example for capabilities that the 
offerer could add to SDP (could be useful for mobile devices for 
example). It is by no means essential to the approach.

> 3. If max-send-ssrc >1 in the answer and the m-line has, for example,
> support for H.264 and VP8 with max-send-ssrc=2  and de-multiplexing is based
> on pt number, it will require four pt in the m-line since there can be two
> VP8 or two H.264 RTP streams
>
>     m=video 5002 RTP/SAVPF 97 98 99 100
>     a=mid:video
>     a=rtcp-mux
>     a=rtpmap:97 VP8/90000
>     a=rtpmap:98 VP8/90000
>     a=rtpmap:99 H264/90000
>     a=rtpmap:100 H264/90000
> Is my understanding correct?

Can you help me understand why you need the PT duplication? Is this just 
so that you could understand distinguish between two sources? If so, 
then it wouldn't be necessary.

With No Plan you would just send:

      m=video 5002 RTP/SAVPF 97 99
      a=mid:video
      a=rtcp-mux
      a=rtpmap:97 VP8/90000
      a=rtpmap:99 H264/90000

If then you want to have one of the VP8 streams rendered on the left 
screen and the other on the right, you will add this in 
application-specific signalling. A web application could do this like this:

{
     "leftSSRC": "1234",
     "rightSSRC": "5678"
}

An WebRTC-to-SIP gateway could transform this into SDP or whatever that 
target devices need.

Does this answer your question?

Emil

>
>
> Roni
>
>
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Emil Ivov
>> Sent: 29 May, 2013 10:00 PM
>> To: rtcweb@ietf.org
>> Subject: [rtcweb] No Plan
>>
>> Hey all,
>>
>> Based on many of the discussions that we've had here, as well as many
>> others that we've had offlist, it seemed like a good idea to investigate a
>> negotiation alternative that relies on SDP and Offer/Answer just a little
> bit
>> less.
>>
>> The following "no plan" draft attempts to present one such approach:
>>
>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>
>> The draft relies on conventional use of SDP O/A but leaves the intricacies
> of
>> multi-source scenarios to application-specific signalling, with
> potentially a
>> little help from RTP.
>>
>> Hopefully, proponents of Plans A and B would find that the
> interoperability
>> requirements that concerned them can still be met with "no plan". Of
> course
>> they would have to be addressed by application-specific signalling and/or
>> signalling gateways.
>>
>> Comments are welcome!
>>
>> Cheers,
>> Emil
>>
>> --
>> https://jitsi.org
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
https://jitsi.org

Re: [rtcweb] No Plan - SDP offer/answer clarification