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

Emil Ivov <emcho@jitsi.org> Mon, 03 June 2013 10:46 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515C721F93D2 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 03:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYS-1OLeQRu0 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 03:46:09 -0700 (PDT)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6FB21F8F2F for <rtcweb@ietf.org>; Mon, 3 Jun 2013 03:46:08 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id jm19so780161bkc.16 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 03:46:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Oj+v4tWMlIaYJS3vFJtSVkrxrphnnOA8oH1tfbt8QuE=; b=fj/lKV8jqdEKbp5BNtlCXu/gWY/x/LLe3JzbnDdjrsE7AeJUcZ7HI3oBEHhE/sWjuk MCuNPUyJ77nnAbIVRUnHCCor8Ge3BLZLIzfk4SF+ta2p5eXUj2a+fJKk2S8LTW9W0n0q oXQg2S6Q0q1jTT8/hKSqt6Vn/dGjKtKpW7VF03HB8G6QIJQ+dLnxX5D0J1uXAHQpZL1o 1C3WmLxZTbbM4N3L/mfbybG11wPBaLZ820QQZQGCJh7jh48h0VsYWcgC+SZaHiLiXFJY dnPVgCVin2g800HEGH6wZ24tz/3IcR2+zSe/jz/mKPggHYJDKlDLvH6JJHnOFGdb4fvH z0YQ==
X-Received: by 10.205.128.204 with SMTP id hf12mr6189594bkc.30.1370256367901; Mon, 03 Jun 2013 03:46:07 -0700 (PDT)
Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id rj5sm18919543bkb.1.2013.06.03.03.46.06 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 03:46:06 -0700 (PDT)
Message-ID: <51AC73EE.5080603@jitsi.org>
Date: Mon, 03 Jun 2013 13:46:06 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com>
In-Reply-To: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkFdTdmmq920Q+oQnJgjDSVnIOCpkPsAWPLXfs0gS9RtKrDDlJonP5L2YB2GGX/eSl5cMPQ
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 10:46:10 -0000

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