НА: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

Dear all, Let me throw in another question- when all of us are talking media, we think its audio-video only. But in practice, real-time data such as vnc, is also now part of real-time media session, and it must follow the same Nat-traversal scenario, as audio & video, but not necessarily the rtp protocol (but TCP). I think if we put stun in browser, it should be available not only for rtp sessions. Based on videoconferencing experience. Слава ----- Reply message ----- От: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> Дата: ср, фев 9, 2011 22:53 Тема: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Кому: "xavier.marjou@orange-ftgroup.com" <xavier.marjou@orange-ftgroup.com>, "dispatch@ietf.org" <dispatch@ietf.org> Копия: "rtc-web@alvestrand.no" <rtc-web@alvestrand.no> 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

+1
But in practice, real-time data such as vnc, is also now part of real-time media session, and it must follow the same Nat-traversal scenario, as audio & video, but not necessarily the rtp protocol
Indeed, many people spend far more time with VNC than making phone/video calls. And as argued here before, the data content in RTP can be transported over HTTP as well, along with all other metadata. A possible guideline here is:
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.
This last sentence is the key IMO. Thanks, Henry On 2/9/11 2:17 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Dear all,
Let me throw in another question- when all of us are talking media, we think its audio-video only.
But in practice, real-time data such as vnc, is also now part of real-time media session, and it must follow the same Nat-traversal scenario, as audio & video, but not necessarily the rtp protocol (but TCP). I think if we put stun in browser, it should be available not only for rtp sessions.
Based on videoconferencing experience.
Слава
----- Reply message ----- От: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> Дата: ср, фев 9, 2011 22:53 Тема: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Кому: "xavier.marjou@orange-ftgroup.com" <xavier.marjou@orange-ftgroup.com>, "dispatch@ietf.org" <dispatch@ietf.org> Копия: "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>
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... wk-reqs-00.txt
Cheers, Xavier and Jean-François _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
participants (2)
-
Henry Sinnreich
-
Slava Borilin