Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Emil Ivov <> Thu, 20 June 2013 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56D4B21E8091 for <>; Thu, 20 Jun 2013 15:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9KtzH-D+5v64 for <>; Thu, 20 Jun 2013 15:34:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22d]) by (Postfix) with ESMTP id 5388521F9E8D for <>; Thu, 20 Jun 2013 15:34:01 -0700 (PDT)
Received: by with SMTP id j13so5942399wgh.0 for <>; Thu, 20 Jun 2013 15:34:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=ReFPsqn7JWLGoZKMgrNbb7mO2Ub+rNiUi6URMFiC0GA=; b=PevdXivpecCOfejU57x/h1AeUUaQC/Q9vMRPSzkbLCTfnfnCwEd7S9Pb0m979Ap1D4 u1eBbIjfmOdHNGQytCehvxaOPwzpTFLPPd7b9kHfr321eld9q/7i9HlKC3VDQQ8Cl0Ws nZyH9DZE4rqUFWmcqTGotkhrUPmtl0ynfn7uot9WulWK3J0MCFjzo0xZIVnF2AGHXbGX sTW3K/wbuhgTAEZHc7JGSPJnKr6FZGBVQmQRB1Glv8OdvFWPXBp8fUJfjzhNUhfkBFLG adkEkW40aY1NVpVPtzGL6Idg+6mpuOTa9wWFfOkNwC9HMNefV28qh1VjcGfEAmTPQFgi PmGg==
X-Received: by with SMTP id bi7mr7241052wjc.2.1371767640909; Thu, 20 Jun 2013 15:34:00 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPSA id r9sm19207142wik.1.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 15:34:00 -0700 (PDT)
Message-ID: <>
Date: Fri, 21 Jun 2013 00:33:58 +0200
From: Emil Ivov <>
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: Iñaki Baz Castillo <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk6p1qqhuvinuIcX/I3Pf7MZxpaBJMoqDPvbmkpPD+lRFhsHxF/AY+dHRDHGPodgIMkplyO
Cc: "" <>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Jun 2013 22:34:08 -0000

Hey Iñaki,

On 20.06.13, 23:49, Iñaki Baz Castillo wrote:
> In JsSIP we are getting frustrated trying to implement the "hold" /
> "unhold" feature because it requires SDP parsing and mangling. Sending
> a re-INVITE with a modified SDP (now with a video track enabled) seems
> to work (after lot of pain) but we still miss a reliable API to know
> what the new SDP means. Instead we need to parse the SDP to detect
> global (or per m=) line attributes like "a=inactive" or "a=sendonly"
> etc etc. It's really painful.

I am having a problem following what you are trying to achieve here. In 
JsSIP you seem to be going for a full SIP implementation in the browser. 
If this is true and if this WG decides to remove SDP from the API 
surface, then you would need to completely parse SDP in the JS and then 
convert it into API calls. Similarly, when creating offers and answers 
you would need to construct SDP all by yourself.

So I am not sure why the SDP parsing in the current situation is so much 
of a blocker for your use case.

> BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did
> a question (in this case about NoPlan) for which I got no response,
> and honestly I would like to see it replied regardless the solution
> uses PlanA, PlanB or NoPlan model:
> I would *really* appreciate a response to that mail (with any Plan as
> solution), really.

Yup, sorry for being silent on that one. Busy days.

My personal take on No Plan SIP interop is that the JS app would take 
the initial SDP out of the browser, send it to a signalling gateway and 
leave that gateway do whatever it wants with it.

Some gateways will resend it with no changes (it is likely that an 
increasing number of endpoints will come to support the kind of SDP that 
comes from browsers). Most GWs will probably handle it as any B2BUA 
handles a call leg. They'd keep a state and possibly convert some of the 
SDP to match what various endpoints expect.

The other option would be indeed to do the same thing in JS. I believe 
this is JsSIP's use case. In that case however, regardless of whether 
you choose Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be 
exposed to a fair amount of complexity, parsing and JS magic.

You are, after all, building a SIP stack.

In the above mail you also say:

> Another example:
> * I am a powerful SIP conference server which properly implements
> WebRTC. I initiate a call to 5 users (running JS SIP app in their
> browsers). The initial INVITE has SSRC/MSID fields in the SDP
> identifying all the participants, am I right?

No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from 
the browser.

> * Later, during the conference, I call to another 6th participant and
> enter him into the conference, so I need to send a re-INVITE to every
> participant with a modified version of the SDP (note that this is SIP
> protocol, so I need to use SIP messages to carry the new info about
> SSRC/MSID and so on).

That's the thing. You don't need that. In Jitsi we do exactly this 
operation with no Offer/Answer signalling. RTP carries enough 
information to process streams and we use upper layer signalling (4575) 
for things such as mapping SSRCs to users and announcing current 
participant list.