W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

VS: Teleco Integrators vs Web Developers vs Browser Implementers

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tue, 2 Jul 2013 18:38:29 +0000
To: Eric Rescorla <ekr@rtfm.com>, "piranna@gmail.com" <piranna@gmail.com>
CC: Robin Raymond <robin@hookflash.com>, Ted Hardie <ted.ietf@gmail.com>, cowwoc <cowwoc@bbs.darktech.org>, Roman Shpount <roman@telurix.com>, "Adam Bergkvist" <adam.bergkvist@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3C1A23@ESESSMB209.ericsson.se>

I am not going to jump into the SDP O/A discussion, but just to comment on PRANSWER.

>> It has been said always that SDP was choosed so WebRTC would be compatible with current VoIP devices and software, so you could 
>> make calls from your browser without needing a proxy. Problem is, that WebRTC has evolve a lot adding a lot of features (panswer SDP message,
> Huh? PRANSWER is specifically designed to enable/model existing
> SIP/SDP features, namely serial forking and 180.

PRANSWER tries to map multiple early SIP legs (in the case of forking) into a single "leg", but it does not work, at least not as currently defined, because it prevents the sending and receiving of additional offers while in the pranswer state.

People have said "Well, just don't use PRANSWER, and it works.". Well, while that is true, then the whole forking support goes away.

I have tried to explain this to some people (including Ekr) off-line in the past, but obviously I haven't done a good job, so I guess I'll have to try again :)


Received on Tuesday, 2 July 2013 18:38:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC