Is the issue that PRANSWER doesn't imitate the SIP use cases correctly, or is it that SIP doesn't handle these situations well? Are we failing to mimic SIP, or are we mimicking SIP's failure? - Jim From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Tuesday, July 02, 2013 3:23 PM To: Christer Holmberg Cc: piranna@gmail.com; Robin Raymond; Ted Hardie; cowwoc; Roman Shpount; Adam Bergkvist; public-webrtc@w3.org Subject: Re: Teleco Integrators vs Web Developers vs Browser Implementers On Tue, Jul 2, 2013 at 11:38 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi, 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 :) Yes, I understand you feel this way. Regardless, it is the case that PRANSWER is designed to imitate SIP use cases, not some innovation that came out of the blue for WebRTC. -Ekr
Received on Tuesday, 2 July 2013 19:34:05 UTC