[dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP
Hi, We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-int... Cheers, Xavier and Jean-François
GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way it allows interworking with SIP-RTP applications both at the signalling and media level. Please help me understand how this and the other requirements do not cripple the whole concept of the RTC-Web (innovation based on simplicity and flexibility) by making it just another extension of legacy telecom design? Or did the authors mean requirements for gateways only? Thanks, Henry On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou@orange-ftgroup.com> wrote:
Hi,
We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-int... wk-reqs-00.txt
Cheers, Xavier and Jean-François
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
well, reading it on its face, as long as we have an architecture which one *can* instantiate a component for the signalling that does SIP and a component for media-transfer that does RTP, and so on, this requirement is met. And I would have thought that yes, we would agree the architecture should make that possible. whether we choose those components as a baseline set to implement is much more a debate, I'd say. On Feb 9, 2011, at 9:36 , Henry Sinnreich wrote:
GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way it allows interworking with SIP-RTP applications both at the signalling and media level.
Please help me understand how this and the other requirements do not cripple the whole concept of the RTC-Web (innovation based on simplicity and flexibility) by making it just another extension of legacy telecom design?
Or did the authors mean requirements for gateways only?
Thanks, Henry
On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou@orange-ftgroup.com> wrote:
Hi,
We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-int...
Cheers, Xavier and Jean-François
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
David Singer Multimedia and Software Standards, Apple Inc.
Hi, Hi Henry, These requirements certainly do not want to cripple innovation (RTC-Web). They rather want to catch attention so that RTC-Web is designed in a way it can also work with existing SIP-RTP devices. Cheers, Xavier On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich <henry.sinnreich@gmail.com>wrote:
GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way it allows interworking with SIP-RTP applications both at the signalling and media level.
Please help me understand how this and the other requirements do not cripple the whole concept of the RTC-Web (innovation based on simplicity and flexibility) by making it just another extension of legacy telecom design?
Or did the authors mean requirements for gateways only?
Thanks, Henry
On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou@orange-ftgroup.com> wrote:
Hi,
We have posted a draft about interworking requirements between RTC-Web and SIP-RTP.
http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-int...
Cheers, Xavier and Jean-François
------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi Xavier and Jean-Francois, Thanks for putting this together. Based on the recent list discussion, I would say that quite many people are leaning towards the architecture you depict in Section 5.2, Figure 2: The session setup protocol is an application specific Javascript implementation transported over HTTP or WebSocket, while media is running on standard RTP supported by the browser. In that model we can't put many requirements on the session setup protocol or its interworking with SIP. If the service provider needs SIP interoperability (to connect to PSTN, to other service providers or SIP phones), it is indeed THEIR burden to make sure they use something that has a clean mapping to SIP - for instance, that they can do things like call hold. On the other hand if the service provider is not interested in SIP interoperability, they do not have to worry about that. In the IETF there are probably two ways to address this interworking: a) do nothing and leave it completely to the implementers and service providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSocket mapping in the same way that the XMPP folks have done. The XMPP/BOSH spec does have implementations both on the client/Javascript side as well as on the server side, so I think that spec has had some value. (At least in a way that the Javascript library and the BOSH servers can be implemented somewhat independently.) The RTP/media stack on the other hand is definitely in the scope of the IETF effort. I think we should standardize the RTP use in the browsers and that would be one step towards interop with SIP phones. The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC). DTMF transport capability may also be relevant interop requirement. I think these are the key issues we should consider wrt. SIP phone interop. Markus From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Xavier Marjou Sent: 09 February, 2011 11:07 To: DISPATCH list Cc: rtc-web@alvestrand.no; Jean-François Jestin Subject: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Hi, We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-int... Cheers, Xavier and Jean-François
On 2/9/11 13:52, Feb 9, Markus.Isomaki@nokia.com wrote:
The RTP/media stack on the other hand is definitely in the scope of the IETF effort. I think we should standardize the RTP use in the browsers and that would be one step towards interop with SIP phones. The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC). DTMF transport capability may also be relevant interop requirement.
+1. Also, it would be incorrect to characterize RTP as being solely for the benefit of SIP. Several other protocol -- both published and proprietary -- make use of RTP; Jingle comes to mind, as do the proprietary protocols used by various IP PBX vendors. If we decide to go down an "RTP but with special sauce" or "not quite RTP" path, we lose a lot of potential functionality. /a
I also agree with the "make RTP just work" - signal where and how you want.. Sorry if I am being dense here - do we not need ICE connectivity checks to finish before RTP can be sent? Or is the point that this will take too long to get into browser code and that ICE in Javascript with STUN in the browser gets rolled out faster? Peter Musgrave On 2011-02-09, at 3:07 PM, Adam Roach wrote:
The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC)
participants (7)
-
Adam Roach -
David Singer -
Henry Sinnreich -
Markus.Isomaki＠nokia.com -
Peter Musgrave -
Xavier Marjou -
Xavier Marjou