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

Iñaki Baz Castillo <> Thu, 20 June 2013 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CFCD11E80E1 for <>; Thu, 20 Jun 2013 14:49:59 -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 P9J8NiFKYQSL for <>; Thu, 20 Jun 2013 14:49:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::231]) by (Postfix) with ESMTP id 1812011E80E4 for <>; Thu, 20 Jun 2013 14:49:48 -0700 (PDT)
Received: by with SMTP id hu16so37173qab.1 for <>; Thu, 20 Jun 2013 14:49:47 -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=uCrDZ1/W2yBYA4Lml8KZI7/Wb+Kx0Wcvernped6bLlg=; b=FjSepNA5iEW9p6BsL8M3k94d3YlH9img820xq2JBghcA5947Nsor5XqD0t/mNcMA70 s/lKiaTLWca1hn+3cFTlA1cnN+2Dz3XoPA+4hslP8OCTL4usj+t9zxP1l3EGH0jxjsCO eu9Zf/nOovNx2qUcdt3nTDhylGX8l9WV8spdJ4ajUBn51q8kFMs98LVl5RcCoY0Keqeh 9l+D6KlbC1zQZHhGsPobB5oftVr0NdjxrWxT3VarNo9KZj9KBnZ8wDdZnxCAbOvmVvPT o6i4j9/35FXOx6tEGDror4zq8MtUXorAl/QhinaAFuodmCDFPAnJkCKCC13aiXymBrmo naSw==
X-Received: by with SMTP id bj9mr11105864qab.14.1371764987536; Thu, 20 Jun 2013 14:49:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jun 2013 14:49:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Thu, 20 Jun 2013 23:49:27 +0200
Message-ID: <>
To: Harald Alvestrand <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQncxeep2/xyBoiDvt2vtG1cWnVEW1M4Is4ZdXrATRhYK/lv1IX1ucYNeM5fNpWfItb4x/Je
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 21:49:59 -0000

2013/6/20 Harald Alvestrand <>:

>> IMHO it would be much more interesting a JS demo that takes the SDP
>> generated by Chrome and "converts" it into a Jingle XML session
>> description (I mean XEP-0167), and that can interoperate (via XMPP
>> over WebSocket or whatever) with a XMPP/Jingle endpoint by
>> incrementally sending/receiving transport (ICE stuff) and media
>> capabilities (as XEP-0167 allows) in different XMPP messages.
> You find it interesting. I'm sure you have a particular XMPP/Jingle
> endpoint in mind that you want to connect to.
> Create one. Or try, and share with us why it did not work.

It will not work (with the current SDP-based model) because it will
require that my JS code parses the SDP blob retrieved from the
browser, extracts all the fields/attributes and "exports" them into
some XML bodies.

What is the problem here? SDP itself because there are tons of
possible valid representations for the *same* session description
information into SDP blobs that look different (but mean the same).
And the problem is that we don't know how the SDP blob retrieved from
current browser model and version will look. My JS code could properly
parse a SDP blob generated by Chrome 35 but may fail in Chrome 36 or
Firefox 29 due to "cosmethic" changes in the SDP.

If this statement is not true (I hope I don't need to code a
XMPP/Jingle endpoint to prove it...), why are there so many SDP
compatibility issues in widely deployed SDP-based protocolos (i.e.
SIP)? Why do SBCs exist? (I know "fixing-SDP-compatibility-issues" is
not their only feature, but it is one of them).

>> And it would also be interesting a JS demo that interoperates with a
>> SIP gateway and is able to perform the "hold" / "unhold" feature so
>> widely extended in SIP world (via reINVITE with a=inactive/sendonly
>> and 200 "OK" with a=inactive/recvonly).
> We have people who have demonstrated interoperability with SIP softphones.
> Some of them are on this list.
> Can they tell us what happened when they tried?

Which kind of interoperability? Let me guess it:

- Initial INVITE with SDP.
- 200 OK response with SDP.
- Lot of applause when the browser produces audio.
- BYE.

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.

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.

Best regards.

Iñaki Baz Castillo