W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 20 Feb 2012 09:54:43 +0100
Message-ID: <CALiegfmEJTHL_b7FnqWTLS6t9-x+j20N114UGEu-F-Ffh50uQg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, Cullen Jennings <fluffy@iii.ca>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
2012/2/20 Christer Holmberg <christer.holmberg@ericsson.com>:
>> IIUC, your proposal is to update JSEP SDP_PRANSWER and SDP_ANSWER as equivalent to moreComing=true/false in ROAP. Also, we need to consider the scenario like 18x with SDP (SDP_PRANSWER) and
>> 2xx without SDP wherein JS has to take care of SDP_ANSWER even though it does not receive one. IMO, Multiple answer issue is not fully solved in ROAP as well.
> In that case, I guess the JS app could simply take a previous SDP_PRANSWER, and send it as SDP_ANSWER.

Right, and that is just custom JavaScript stuff just depending on the
chosen on-the-wire signaing mechanism. WebRTC should not be aware
about SIP semantics. If someone implements SIP or something "like SIP"
in JavaScript and wants to deal with an empty 200 OK after a 180/183
with SDP, then he should handle it in his custom JavaScript code.
WebRTC is out of that scope.

Iñaki Baz Castillo
Received on Monday, 20 February 2012 08:55:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC