One document matched: draft-burger-sipping-dir-transcode-00.txt
SIPPING E. Burger
Internet-Draft SnowShore Networks, Inc.
Expires: August 25, 2003 February 24, 2003
Directed Transcoding
draft-burger-sipping-dir-transcode-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a mechanism for invoking transcoding services
in a SIP network. A user, proxy server, or other agent can
transparently request these services, without modification to the
existing network.
Conventions used in this document
This document refers generically to the calling party (caller) in the
masculine (he/him/his) and the called party in the feminine (she/her/
hers). This convention is purely for convenience and makes no
assumption about the gender of either party.
Burger Expires August 25, 2003 [Page 1]
Internet-Draft SIP Directed Transcoding February 2003
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Examples . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Inbound SIP Proxy . . . . . . . . . . . . . . . . . . . . . . 4
2.2 On Demand Transcoding: Individual User . . . . . . . . . . . . 5
3. Sample Implementation . . . . . . . . . . . . . . . . . . . . 6
3.1 Using Source-Sink SDP . . . . . . . . . . . . . . . . . . . . 6
3.2 Using Conference Bridge . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Burger Expires August 25, 2003 [Page 2]
Internet-Draft SIP Directed Transcoding February 2003
1. Overview
There is often a need for transcoding services in a communications
network. Common scenarios include transcoding audio real-time data
and services for the speech and hearing impaired.
Companion papers sip-deaf [9] and source-sink [2] describe the
mechanics for transcoding aware devices to request transcoding
services from a media server.
This document describes a mechanism for creating a pass-through
transcoding session. The mechanism described here alleviates the
endpoints from needing to understand and execute complex call flows.
Moreover, this mechanism is simple for SIP Proxies to implement.
The essence of the mechanism is to use a special Request-URI to
identify the transcoding service and the target SIP UAS. This is
similar to the concept described in netann [10]. The user part
(left-hand side) of the Request-URI begins with "xcod=", followed by
the target SIP Request-URI, with special characters, like colon (:)
and at-sign (@) escaped. The system part (right-hand side) of the
Request-URI identifies the transcoding server.
Codec negotiation between the UAS, UAC, and transcoding server
proceed following standard RFC3261 [3] offer/answer. Optionally, the
SDP may contain the source and sink attributes specified in
source-sink [2] if the UAC desires multiple simultaneous
translations.
Burger Expires August 25, 2003 [Page 3]
Internet-Draft SIP Directed Transcoding February 2003
2. Service Examples
2.1 Inbound SIP Proxy
In this example, a user wishes to have transcoding service performed
on her behalf on her inbound sessions. Perhaps they are speech
impaired and wish to have the caller hear synthesized speech offered
by a transcoding server.
To establish the request for the transcoding service, the user
registers a special SIP URI for their address. Rather than register
the actual address of her UAS, she registers the address of a
transcoding server, with her UAS' URI encoded in the registered URI.
Figure Figure 1 describes the network components, their relationship,
and the SIP Request-URI's formed for each INVITE.
+-----------+
+-----+ INVITE sip:target@example.com | target's |
| UAC |--------------------------------->| in-bound |
+-----+ | SIP Proxy |
+-----------+
|
INVITE sip:xcod=sip%3areal-target%40example.com@ms.example.com
|
V
+--------------+
| Transcoding |
| Server |
+--------------+
|
+-----+ INVITE real-target@example.com |
| UAS |<----------------------------------------+
+-----+
Figure 1
Note the beauty of using opaque SIP Request-URIs. The in-bound SIP
Proxy does not need to be aware of the function of the transcoding
server. All the in-bound SIP Proxy need do is do a standard lookup
for a given SIP Request-URI. In the example above, the SIP
Request-URI
sip:target@example.com ,
rather than having the translation
sip:real-target@example.com ,
Burger Expires August 25, 2003 [Page 4]
Internet-Draft SIP Directed Transcoding February 2003
has the translation
sip:xcod=sip%3areal-target%40example.com@ms.example.com .
Said differently, there are absolutely no modifications needed to the
SIP Proxy.
Considering the use of this method for the subscriber, her callers
need never know that she has a transcoding service. For example, the
transcoding could be a human reading the subscriber's text. As far
as the calling party is concerned, he never knows that he is not
speaking with the called party.
2.2 On Demand Transcoding: Individual User
In this example, a user wishes to have transcoding service performed
on his behalf on a session he initiates. Perhaps they are hearing
impaired, he knows that the called party wishes to speak, and he
wants to keep his impairment a secret.
To establish the request for the transcoding service, the user enters
a special SIP URI for the called party's address. Rather than enter
the SIP URI of the called party, he enters the address of a
transcoding server, with the called party's UAS URI encoded in the
SIP Request-URI. Figure bar describes the network components, their
relationship, and the SIP Request-URI formed for each INVITE.
+-----+ INVITE sip:xcod=sip%3atarget%40example.com@ms.example.com
| UAC |---------\ +--------------+
+-----+ \------------------->| Transcoding |
| Server |
+--------------+
|
+-----+ INVITE target@example.com |
| UAS |<-------------------------------------+
+-----+
Note again the benefit of using opaque SIP Request-URIs. Not one
piece of infrastructure needs modification to support this service.
Granted, user's may prefer a smart UAC that automatically generates
the transcoding URI from a target URI. However, nothing requires
this. On the other hand, this is why it is critically important to
standardize the usage of the Request-URI. The standardization
enables manufacturers of UAC's and transcoding servers to
interoperate.
Burger Expires August 25, 2003 [Page 5]
Internet-Draft SIP Directed Transcoding February 2003
3. Sample Implementation
This section is informative. Any deviations with the preceding
sections are unintentional. In the event of deviations, the
normative descriptions above are correct.
3.1 Using Source-Sink SDP
One can construct a transcoding server from a transcoding application
server and media server.
o Take the transcoding Request URI and extract the target Request
URI
o Invite a classical media server to the dialog
o Invite the target Request URI, using mechanisms described in
sip-deaf [9]
Here is a typical network topology.
+--------+ INVITE sip:xcod=sip%3atarget%40example.com@t.example.com
| UAC or |-------\ +-------------+
| Proxy | \------------------->| Transcoding |
+--------+ | App. Server |
+-------------+
INVITE target@example.com / | INVITE
+-----+ /--------------------/ | xcod@example.com
| UAS |<-----/ V
+-----+ RTP +--------------+
\==============================| Media Server |
+--------------+
Following the example laid out in sip-deaf [9], here is a sample call
flow.
Burger Expires August 25, 2003 [Page 6]
Internet-Draft SIP Directed Transcoding February 2003
C T M S
| | | |
| INVITE sip:xcod=sip%3atarget%40example.com@t.example.com
|------------>| | | (1)
| SDP C | | |
| | | |
| 100 Trying | | |
|<------------| | | (2)
| | INVITE sip:target@example.com|
| |----------------------------->| (3)
| | no SDP | |
| | | 200 OK |
| |<-----------------------------| (4)
| | | SDP S |
| | | |
| | INVITE sip:xcode@ms.example.net
| |-------------->| | (5)
| | SDP C+S | |
| | | |
| | 200 OK | |
| |<--------------| | (6)
| | SDP MC+MS | |
| | | |
| 200 OK | | |
|<------------| | | (7)
| SDP MS | | |
| | | |
| ACK | | |
|------------>| ACK | | (8)
| |-------------->| | (9)
| | ACK | |
| |----------------------------->| (10)
| | SDP MC | |
| | | |
| | RTP | RTP |
|<===========================>|<============>| (11)
| | | |
Here is a detailed description of the operation of the mechanism.
First, the UAC or Proxy C issues an INVITE to the transcoding
application server T with C's SDP in message (1). The transcoding
application server T responds with a 100 Trying (2), as it may take
some time to coordinate the media server and UAS.
The transcoding application server T then invites the UAS S with no
SDP in message (3). The UAS S responds with a 200 OK with S's SDP in
message (4).
Burger Expires August 25, 2003 [Page 7]
Internet-Draft SIP Directed Transcoding February 2003
With C's and S's SDP, the transcoding application server T then
invites the media server M with the SDP with the appropriate plumbing
as specified in [I-D.camarillo-mmusic-source-sink]. The media server
M responds with the appropriate media server sinks for S to C (MC)
and C to S (MS) in message (6).
The transcoding application server T sends the media server sink for
S to C (7) and C acknowledges the connection (8). The transcoding
application server acknowledges the connection to the media server M
(9).
Finally, the transcoding application server T sends the media server
sink for C to S in the acknowledgement (10). At this point we have a
transcoding stream (11).
3.2 Using Conference Bridge
An alternative method of constructing a transcoding server from a
transcoding application server and media server is to create a
conference.
o Take the transcoding Request URI and extract the target Request
URI
o Invite a classical media server to the dialog
o Invite the target Request URI, using mechanisms described in
sip-deaf [9]
Here is a typical network topology.
+--------+ INVITE sip:xcod=sip%3atarget%40example.com@ms.example.com
| UAC or |-------\ +-------------+
| Proxy | \------------------->| Transcoding |
+--------+ | App. Server |
+-------------+
INVITE target@example.com / | INVITE
+-----+ /--------------------/ | xcod@example.com
| UAS |<-----/ V
+-----+ RTP +--------------+
\==============================| Media Server |
+--------------+
Following the example laid out in sip-deaf [9], here is a sample call
flow.
C T M S
Burger Expires August 25, 2003 [Page 8]
Internet-Draft SIP Directed Transcoding February 2003
| | | |
| INVITE sip:xcod=sip%3atarget%40example.com@t.example.com
|------------>| | | (1)
| SDP C | | |
| | | |
| 100 Trying | | |
|<------------| | | (2)
| | | |
| | INVITE sip:conf=id@ms.example.net
| |-------------->| | (3)
| | SDP C | |
| | | |
| | 200 OK | |
| |<--------------| | (4)
| | SDP MS | |
| | | |
| | INVITE target@example.com |
| |----------------------------->| (5)
| | no SDP | |
| | | 200 OK |
| |<-----------------------------| (6)
| | | SDP S |
| | | |
| | INVITE sip:conf=id@ms.example.net
| |-------------->| | (7)
| | SDP S | |
| | | |
| | 200 OK | |
| |<--------------| | (8)
| | SDP MC | |
| | | |
| 200 OK | | |
|<------------| | | (9)
| SDP MS | | |
| | | |
| ACK | | |
|------------>| ACK | | (10)
| |-------------->| | (11)
| | ACK | |
| |----------------------------->| (12)
| | SDP MC | |
| | | |
| | RTP | RTP |
|<===========================>|<============>| (13)
| | | |
Here is a detailed description of the operation of the mechanism.
Burger Expires August 25, 2003 [Page 9]
Internet-Draft SIP Directed Transcoding February 2003
First, the UAC or Proxy C issues an INVITE to the transcoding
application server T with C's SDP in message (1). The transcoding
application server T responds with a 100 Trying (2), as it may take
some time to coordinate the media server and UAS.
The transcoding application server T then invites the media server M
to a conference with the ID id with the SDP for C (3). The media
server M responds with a 200 OK with what will be the transcoded
version of S's SDP in message (4). Note the user of the conference
SIP Request-URI as specified by netann [10].
The transcoding application server T then invites the UAS S with no
SDP in message (5). The UAS S responds with its SDP in message (6).
With the UAS' SDP, the transcoding application server invites the
media server M to the same conference in (3) in message (7). The
media server responds to the request with a 200 OK with what will be
the transcoded version of C's SDP in message (8).
The transcoding application server T sends the transcoded version of
S' SDP in message (9). The UAC C acknowledges the request in message
(10), which T relays to the media server M (11).
The transcoding application server T then sends the transcoded
version of C's SDP to the UAS S in message (12).
At this point, we have the transcoded RTP stream (13).
Burger Expires August 25, 2003 [Page 10]
Internet-Draft SIP Directed Transcoding February 2003
4. Security Considerations
Yes, there definitely will be a -01!
Burger Expires August 25, 2003 [Page 11]
Internet-Draft SIP Directed Transcoding February 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H., Camarillo, G. and E. Burger, "The source and
sink attributes for the Session Description Protocol",
draft-camarillo-mmusic-source-sink-00 (work in progress),
September 2002.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[4] ISO, "Codes for the representation of names of languages -- Part
1: Alpha-2 code", ISO 639-1, July 2002.
[5] ISO, "Codes for the representation of names of countries and
their subdivisions -- Part 1: Country codes", ISO 3166-1,
October 1997.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
Burger Expires August 25, 2003 [Page 12]
Internet-Draft SIP Directed Transcoding February 2003
Informative References
[9] Camarillo, G., "Transcoding Services Invocation in the Session
Initiation Protocol", draft-camarillo-sip-deaf-01 (work in
progress), November 2002.
[10] Burger, E., Van Dyke, J., O'Connor, W. and A. Spitzer, "Basic
Network Media Services with SIP",
draft-burger-sipping-netann-04 (work in progress), January
2003.
[11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[12] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van
Wijk, "User Requirements for the Session Initiation Protocol
(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
Individuals", RFC 3351, August 2002.
[13] Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media
Server Control Markup Language and Protocol",
draft-vandyke-mscml-00 (work in progress), November 2002.
[14] World Wide Web Consortium, "Voice Extensible Markup Language
(VoiceXML) Version 2.0", W3C Working Draft , April 2002,
<http://www.w3.org/TR/voicexml20/>.
[15] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[16] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
3010, December 2000.
[17] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[18] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
Burger Expires August 25, 2003 [Page 13]
Internet-Draft SIP Directed Transcoding February 2003
Author's Address
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
EMail: e.burger@ieee.org
Burger Expires August 25, 2003 [Page 14]
Internet-Draft SIP Directed Transcoding February 2003
Appendix A. Acknowledgements
The transcoding design team includes Gonzalo Camarillo, Henning
Schulzrinne, and Arnoud van Wijk.
Burger Expires August 25, 2003 [Page 15]
Internet-Draft SIP Directed Transcoding February 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Burger Expires August 25, 2003 [Page 16]
Internet-Draft SIP Directed Transcoding February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Burger Expires August 25, 2003 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 02:58:16 |