One document matched: draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3439 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3439.xml'>
<!ENTITY RFC3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY RFC4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY RFC3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY RFC3960 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3960.xml'>
<!ENTITY RFC5939 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5939.xml'>
<!ENTITY SIPAPI PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-sinnreich-sip-web-apis-01.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc ipr='trust200811' category='info'>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>
<front>
<title abbrev='RTC-Web reqs for SIP and RTP interworking'>
Requirements for interworking between RTC-Web and SIP-RTP protocols
</title>
<author initials='X.' surname='Marjou' fullname='Xavier Marjou'>
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22307</code>
<country>France</country>
</postal>
<email>xavier.marjou@orange-ftgroup.com</email>
</address>
</author>
<author initials='JF.' surname='Jestin' fullname='Jean-Francois Jestin'>
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22307</code>
<country>France</country>
</postal>
<email>jeanfrancois.jestin@orange-ftgroup.com</email>
</address>
</author>
<date month='February' year='2011' />
<area>Real-time Applications and Infrastructure Area</area>
<keyword>RTC-Web</keyword>
<keyword>rtc-web</keyword>
<keyword>RTCweb</keyword>
<keyword>requirements</keyword>
<keyword>SIP</keyword>
<keyword>Interworking</keyword>
<abstract>
<t>In the context of <xref target="RTC-Web" />, some work is emerging to make real-time
communications possible in a web browser.
This document defines a minimal set of requirements so that such applications
interoperate with SIP-RTP applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In the context of <xref target="RTC-Web" />, some work is emerging to make real-time communications
possible in a web browser.
Such work will allow to use the UDP protocol to transport real time data.</t>
<t>This document defines a minimal set of requirements so that RTC-Web applications interoperate with applications based on SIP (<xref target="RFC3261" />) and RTP (<xref target="RFC3550" />) protocols.</t>
<t>On the one hand, bringing real-time communication capability in the web browser RTC-Web promises to offer great value to end-users,
developers and service providers. This value comes from the ubiquity of the web browser and the web architecture, from the
simple programatic model the web offer and indeed the innovation perspective of such solution.</t>
<t>On the other hand, SIP and RTP protocols are broadly used to implement real-time or near real-time applications.
This is particularly true for voice, video, instant messaging, presence and content sharing
and when considering available implementations in devices (hard phone, mobile phone...), network infrastructures
(e.g. SIP based architecture) and service provider interconnection gateways.
</t>
<t>Allowing both solutions to interoperate promises RTC-Web solution to have greater value as it will allow
this solution to reach legacy SIP multimedia devices and networks and vice versa. </t>
<t><xref target='usecases'/> describes some use cases.
<xref target='interworking'/> reports the different possible architectures.
<xref target='requirements'/> finally states a set of requirements the ongoing RTC-Web solution definition should fulfil to be able to interoperate with SIP based multimedia applications.
</t>
<t>Note: This document does not directly address RTC-Web service provider interconnection except if this interconnection is based on SIP-RTP.</t>
</section>
<section title="Terminology">
<t> In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 <xref target="RFC2119" />.</t>
</section>
<section title="Definitions">
<t>RTC-WEB: the term <xref target="RTC-Web" /> refers to the ongoing work on defining a solution that enables real time applications
such as bidirectional audio and video within web applications</t>
<t>SIP-RTP: the term SIP-RTP is a generic term which refers to SIP and RTP ecosystem protocol stack.
This includes, non exhaustively: SIP, SDP, RTP, RTCP, SRTP...</t>
<t>Note: To be adjusted to fit with the current on going <xref target="RTC-Web" /> charter.</t>
</section>
<section anchor="usecases" title="Use cases">
<t>This section presents some use cases involving interworking between RTC-Web and SIP applications.
These use cases include scenarios where real-time audio and/or video are exchanged.</t>
<section title="SIP Multimedia application reachability extension">
<t>Alice wants to access its services. Her service provider A (e.g. atlanta.example.org) hosts these services on SIP-RTP servers.
Alice can use a web browser implementing an RTC-Web extension to reach its service. </t>
</section>
<section title="RTC-Web applications with integration of SIP device ">
<t>Bob wants to access its services. His service provider B (e.g. biloxy.example.org) hosts these services on RTC-Web servers.
Bob can use a device implementing an SIP-RTP extension to reach its service. </t>
</section>
<section title="RTC-Web and SIP service provider interconnection">
<t>All the users of service provider A (e.g. atlanta.example.org) use an RTC-Web application.
All the users of service provider B (e.g. biloxi.example.org) use a SIP-RTP application.
Both service providers want to make communications possible between all these users.
</t>
<t>This use case is typically an inter service operators use case.</t>
</section>
</section>
<section anchor="interworking" title="Possible RTC-Web/SIP interworking architectures">
<t>This section outlines different architectures to realize RTC-Web/SIP-RTP interworking. This section does
not pretend to be exhaustive in term of architecture description but intends to propose families of models any kind of
solution should fit in.</t>
<t>These architectures satisfy the use cases listed above. However, It must be noted
that depending on the considered use case, additional components may be necessary.</t>
<t>In this section, the name SIP used alone is a shortcut for SIP and SDP protocols.
Similarly, RTP used alone is a shortcut for RTP, RTCP, and SRTP protocols.</t>
<section anchor="archi1" title="SIP-RTP Stack in the Browser">
<t>This architecture consists in directly implementing a SIP-RTP protocol stack
in the browser, enabling a direct connection between an RTC-Web application in a browser and a SIP-RTP phone.</t>
<figure anchor="no_gw">
<preamble>Architecture with SIP-RTP in the browser:</preamble>
<artwork><![CDATA[
----------------- -----------------
| RTC-Web | | SIP-RTP |
| application | | application |
|-----------------| | |
|rtcweb rtcweb | | |
| sig media | | |
| APIs APIs | | |
|-----------------| | |
| | | |
| ----- | | ----- |
|| SIP | |<-----------SIP----------->|| SIP | |
||stack| | ||stack| |
| ----- | | ----- |
| ----- | | ----- |
| | RTP ||<-----------RTP----------->| | RTP ||
| |stack|| | |stack||
| ----- | | ----- |
----------------- -----------------
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="archi2" title="New Signalling Scheme and RTP Stack in the Browser">
<t>This architecture consists in implementing a new signalling scheme and an RTP
stack in the browser.</t>
<t>A new signalling scheme means refers to two possible models:
<list style="symbols">
<t>Session management data set by API and transported by an application protocol (e.g. HTTP or WebSockets).
<xref target="sig_gw_http" /> illustrates such architecture with XXX as the session management data.
The HTTP stack shown in the figure is the regular HTTP stack available by default in all web browsers.
Having SIP (or part of it) embedded in HTTP in one possible implementation, as indicated in [draft-sinnreich-sip-web-apis-01].</t>
<t>A session management protocol different from SIP (e.g. XMPP, MEGACO).
<xref target="sig_gw_other" /> illustrates such architecture with YYY as the signalling protocol. </t>
</list>
</t>
<t>Both models relax constraints on the technology choice to implement the RTC-Web solution but add constraints on end-to-end compatibility with SIP-RTP
applications by requiring the implementation of a gateway to map one protocol into another one.</t>
<figure anchor="sig_gw_http">
<preamble>Architecture with HTTP in the browser:</preamble>
<artwork><![CDATA[
----------------- -----------------
| RTC-Web | | SIP-RTP |
| application | | application |
|-----------------| | |
|rtcweb rtcweb | | |
| sig media | | |
| APIs APIs | | |
| | XXX | | | |
|---|---------|---| XXX | |
| --|-- | | over -------- | ----- |
||HTTP | | |<-HTTP->|HTTP|SIP|<-SIP-->|| SIP | |
||stack| | | | GW | ||stack| |
| ----- | | -------- | ----- |
| --|-- | | ----- |
| | RTP ||<----------RTP----------->| | RTP ||
| |stack|| | |stack||
| ----- | | ----- |
----------------- -----------------
]]></artwork>
<postamble></postamble>
</figure>
<figure anchor="sig_gw_other">
<preamble>Architecture with another protocol than SIP or HTTP in the browser:</preamble>
<artwork><![CDATA[
----------------- -----------------
| RTC-Web | | SIP-RTP |
| application | | application |
|-----------------| | |
|rtcweb rtcweb | | |
| sig media | | |
| APIs APIs | | |
|-----------------| | |
| ----- | -------- | ----- |
|| YYY | |<-YYY-->| YYY|SIP|<-SIP-->|| SIP | |
||stack| | | GW | ||Stack| |
| ----- | -------- | ----- |
| ----- | | ----- |
| | RTP ||<----------RTP----------->| | RTP ||
| |stack|| | |stack||
| ----- | | ----- |
----------------- -----------------
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="archi3" title="New Signalling Scheme and New Media Protocol in the Browser">
<t>This architecture consists in implementing different protocols in RTC-Web and SIP-RTP frameworks, both for at the signalling level and at the media level.</t>
<t>Such architecture requires interworking work (protocol mapping, gateway) both for the signalling and the media protocols.</t>
<t>This architecture relaxes constraints on the technology choice to implement the RTC-Web solution but adds constraints on end-to-end compatibility with SIP-RTP
applications by requiring the implementation of gateway(s) to adapt protocols and media payloads.</t>
<figure anchor="sig_media_gw">
<preamble>Architecture with another protocol than RTP as a media protocol:</preamble>
<artwork><![CDATA[
----------------- -----------------
| RTC-Web | | SIP-RTP |
| application | | application |
|-----------------| | |
|rtcweb rtcweb | | |
| sig media | | |
| APIs APIs | | |
|-----------------| | |
| ----- | ------- | ----- |
||sig. | |<-sig->|sig|SIP|<-SIP-->|| SIP | |
||stack| | | GW | ||stack| |
| ----- | ------- | ----- |
| ----- | ------- | ----- |
| |med. ||<-med->|med|RTP|<-RTP-->| |RTP ||
| |stack|| | GW | | |stack||
| ----- | ------- | ----- |
----------------- -----------------
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Analysis with regards to interworking">
<t>Using a full SIP-RTP stack in the browser (<xref target="archi1"/>) would undoubtedly be the best solution
with regards to interworking: it would avoid specifying new protocols
and it would thus avoid the control plane interworking problem described
in <xref target="RFC3439"/> (i.e. no need for protocol mapping).
It nevertheless requires a granular API to configure and access the protocol stack.
</t>
<t>Using the RTP protocol suite but another than the SIP protocol (<xref target="archi2"/>)
add the burden of interworking efforts at the signalling level.
<!--This gateway based architecture also adds investments and complexity that are incompatible with easy development of end-to-end solution.-->
The level of complexity of this gateway depends on how much the signaling protocol will look like SIP.
However, having HTTP (or WebSocket) as a protocol transporting the signaling data is attractive due to
the central role played by this protocol in Web environments.</t>
<t>Using both new signalling and media protocols in the browser (<xref target="archi3"/>) has been presented
above for the sake of exhaustiveness but this solution is not attractive for SIP-RTP interworking: it increases the interworking efforts
by requiring work at the media level (new media protocol, complexity and cost of interworking gateways...),
whereas adding no identified advantages with regards to the existing RTP/UDP protocol suite.</t>
</section>
</section>
<section anchor="requirements" title="Requirements">
<t>Whatever the architecture solution the RTC-Web will retain, a reasonable way-forward
is to specify its protocols and APIs taking care of interworking with SIP-RTP devices.
As such the following requirements are proposed to the RTC-Web working group:</t>
<section title="Generic requirements:">
<t><list style="format GENERIC-REQ-%d">
<t> The <xref target="RTC-Web" /> solution MUST be designed in a such way it allows interworking with SIP-RTP applications both at the signalling and media level.</t>
</list></t>
</section>
<section title="Signalling level requirements:">
<t><list style="format SIG-REQ-%d">
<t> The <xref target="RTC-Web" /> solution MUST be designed in a way it allows interoperability with SIP based multimedia applications.
This is typically applicable for identifiers, credentials, state machine, and message types. <vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution MUST include a way to negotiate media format as in Offer/Answer model used in SIP (<xref target="RFC3264" />)<vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution MUST include a way to interoperate with (<xref target="RFC5939" />)<vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution MUST allow end to end codec negotiation between RTC-web device and SIP device<vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution MUST include a compatibility/mapping with SDP(<xref target="RFC4566" />)<vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution SHOULD NOT require SIP-RTP extensions. <vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Media level requirements:">
<t><list style="format MEDIA-REQ-%d">
<t> The <xref target="RTC-Web" /> solution MUST be designed in a way it does not mandate a gateway at media level when interworking
with SIP based multimedia application, consequently it must be based on RTP/RTCP protocol suite over UDP for real-time media.<vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution MUST be compatible with a media gateway architecture and not rely exclusively on a peer to peer (between RTC-Web devices)...<vspace blankLines="1"/></t>
<t> The <xref target="RTC-Web" /> solution MUST allow the configuration of some media-related parameters per session (e.g. buffer size, packetization...).<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Codec level requirements:">
<t><list style="format CODEC-REQ-%d">
<t> The <xref target="RTC-Web" /> solution MUST allow codecs available in existing SIP-RTP
applications. A non exhaustive list is the following: G.711, G.722, AMR, AMR-WB, H.264.<vspace blankLines="1"/></t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t><list style="format SEC-REQ-%d">
<t> RTC-Web and SIP-RTP interworking solution MUST NOT compromise inherent
security feature(s) developed and used for both RTC-Web and SIP-RTP solutions.<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<section title="Acknowledgements">
<t>Thank you to Bruno Chatras, Christophe Eyrignoux, and Sebastien Cubaud who provided early feedback.</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC1958;
&RFC2119;
&RFC2616;
&RFC3261;
&RFC3550;
&RFC4566;
&RFC3264;
&RFC3960;
&RFC5939;
</references>
<references title="Informative references">
&RFC3439;
&SIPAPI;
<reference anchor="RTC-Web">
<front>
<title>http://rtc-web.alvestrand.com/</title>
<author>
<organization>RTC-Web</organization>
</author>
<date year="">2010</date>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:05 |