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

Iñaki Baz Castillo <> Thu, 20 June 2013 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CF4121E80AD for <>; Thu, 20 Jun 2013 16:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1vKM5Zpj2yQr for <>; Thu, 20 Jun 2013 16:24:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::231]) by (Postfix) with ESMTP id 8006F21E80B9 for <>; Thu, 20 Jun 2013 16:24:29 -0700 (PDT)
Received: by with SMTP id n1so4123326qcx.22 for <>; Thu, 20 Jun 2013 16:24:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=u/kREXIGyrA/uUnwxWew2c/M/zpwgGiIvd5MTZg7ulg=; b=bcMP26j9nQVqQvA/SJM/qlo5geZNfld6nHetiJZhlskq/rzz38ffs2p09tdy5w72t3 jGTYwGEo5c5PUChxZA4aTpyDdI1a83xzKvc9By7O9KJY1Gnw/I310626ooZsNdmhQRvu LlIu/A+PqC+/PdQPCkFSzZUYpg3x+tUHYTHPwchFRYoQwSuhpNPnQt/vXruKDdNDEBhN acMMLMGh7skoAivAmo3ofD14VGiM0QYvUyjpBrZKJ4WJYxh7LKifypXcV/83FBjTdIRn mCChkmGgESuNxjK8DNEc55FkPJ8wH0wzTs2CsZ8bbO+ahh8g6RcZw85p4uOuKGe8hYhY rhIQ==
X-Received: by with SMTP id k9mr577733qcb.91.1371770669406; Thu, 20 Jun 2013 16:24:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jun 2013 16:24:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Fri, 21 Jun 2013 01:24:09 +0200
Message-ID: <>
To: Emil Ivov <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl+3S0JYSO0WOCCKriLtX5RXFGcQSIQC5+Bvywgq7kLpztzXHNY9oTX65R3NNHpTeLv3jJV
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 23:24:36 -0000

2013/6/21 Emil Ivov <>:
> 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.

And we will do it very happily because then we will know what
*exactly* we are sending on-the-wire.

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

Because regardless I am a SIP-guy, I understand that the main mission
of WebRTC is to provide realtime communications *for* the WWW, and not
to enable a new interface for like-telephony-bussines.

Today I'm doing SIP. Tomorrow I may be doing
[[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't
want to be constrained by decisions made today that force any future
RTC protocol to deal with SDP O/A model.


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

Yes, but JsSIP creates its own SIP messages to be sent in the wire, so
we have full control over *what* we create and send. Those SIP
messages are not provided by the WebRTC API. But for the SDP
component, JsSIP retreives a SDP blob string from the PC.

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

That is much better than Plan A and Plan B.

BTW: What would happen in NoPlan if the remote (i.e. a SIP
gateway/endpoing) sends you a re-INVITE for "hold" purposes and you
pass the SDP to your PC? or you should not pass the SDP to your PC?
and if so, what about if the SDP contains updated ICE candidates due
to remote peer network mobility?

Thanks a lot for your response.

Iñaki Baz Castillo