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

From: Slava Borilin <[email-masked]>
Date: Wed, 9 Feb 2011 23:17:07 +0300

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 -----
От: "[email-masked]" <[email-masked]>
Дата: ср, фев 9, 2011 22:53
Тема: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP
Кому: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Копия: "[email-masked]" <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Xavier Marjou
Sent: 09 February, 2011 11:07
To: DISPATCH list
Cc: [email-masked]; 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-interwk-reqs-00.txt

Cheers,
Xavier and Jean-François

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 09 Feb 2011 16:04:08 -0600

+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" <[email-masked]> wrote:

> 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 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.
> 
> _______________________________________________
dispatch mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch