Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API

Enrico Marocco <> Wed, 03 July 2013 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 506F321F9C3E for <>; Wed, 3 Jul 2013 01:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.419
X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NPTbNHwk7FCk for <>; Wed, 3 Jul 2013 01:23:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0393F21F9C3B for <>; Wed, 3 Jul 2013 01:23:27 -0700 (PDT)
Received: from grfhub701rm001.griffon.local ( by ( with Microsoft SMTP Server (TLS) id; Wed, 3 Jul 2013 10:23:17 +0200
Received: from MacLab.local ( by ( with Microsoft SMTP Server (TLS) id; Wed, 3 Jul 2013 10:23:17 +0200
Message-ID: <>
Date: Wed, 3 Jul 2013 10:23:17 +0200
From: Enrico Marocco <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090906030002040805000804"
X-TI-Disclaimer: Disclaimer1
Cc: "<>" <>
Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
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: Wed, 03 Jul 2013 08:23:40 -0000

On 7/2/13 6:30 PM, José Luis Millán wrote:
> Thanks Enrico,
> Yes, you are right. I was missing a detail.
> Now imagine you are not using your own wire protocol but a standard one,
> where accepting the request doesn't imply accepting or rejecting the SDP
> offer, since SDP has its own methods to accept or reject the call as
> commented before.

I assume you are talking about browser-to-browser signalling. If it was
a deliberate choice to pick SIP rather than a custom protocol properly
designed for the semantics of you application, then it is a
self-inflicted pain you cannot blame on the API.

If on the other hand you are talking about interworking with SIP
networks, I'm sympathetic with you, as there is no way for your
gatewaying function (regardless of whether it is on an external element
or wired directly into the JS) to avoid SDP parsing and handling of the
42 different ways it defines for signalling stream rejection. My advice
in such case: hang on in there! Eventually your customers will be happy
to pay you good money for the commendable effort.