Internet DRAFT - draft-kang-sipping-dtransc-requirement
draft-kang-sipping-dtransc-requirement
Direct Transcoding requirement June 2005
SIPPING Working Group Taegyu Kang
Internet-Draft Doyoung Kim
Expires: December 8, 2005 Haewon Jung
ETRI
June 9, 2005
The requirement for direct transcoding with Session Initiation
Protocol
<draft-kang-sipping-dtransc-requirement-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are 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 a "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 December 8, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document presents a set of Session Initiation Protocol (SIP)
call control requirements that support communication with direct
transcoding capability. Several solutions are addressed for
transcoding service.
Direct transcoding requires two kinds of requirements: the service
requirement and call control requirement. Service requirement is no
constraint of codec adaptation and interoperability of models. Call
Taegyu Kang Expires - December 2005 [Page 1]
Direct Transcoding requirement June 2005
control requirement is exchange of codec information and minimizing
of call set up delay.
The model might be applied to general-purpose services satisfying the
requirements of multimedia applications without an additional INVITE.
Taegyu Kang Expires - December 2005 [Page 2]
Direct Transcoding requirement June 2005
Table of Contents
1. Introduction...................................................4
2. Purpose and scope..............................................4
3. Background.....................................................4
4. Service Requirement............................................7
4.1 No Constraint of Codec Adaptation..........................7
4.2 Interoperability of Models.................................7
5. Call Control Requirement.......................................8
5.1 Exchange of codec information..............................8
5.2 Minimizing of Call set up delay............................8
6. Security Considerations........................................9
7. IANA Considerations............................................9
References........................................................9
Author's Addresses...............................................10
Intellectual Property Statement..................................10
Taegyu Kang Expires - December 2005 [Page 3]
Direct Transcoding requirement June 2005
1. Introduction
Simple homogeneous terminals and special purpose terminals comprise
the majority of existing network terminals. Communication media is
getting more diverse in terms of the types of network terminals.
However, the era of new communication media types through several
kinds of network terminals such as hardware IP phones(POTS style, PDA
style, mobile phone style), software IP phones(special purpose
software phone, messenger phone, ITSP phone), POTS phones, ISDN
phones and mobile phones is coming.
We believe that transcoding services are a key solution to supporting
these types of communication in heterogeneous networks and different
capability terminals.
We want to use a service network transparency even though it has
wireline network, wireless network, internet, and broadcasting
network with a horizontal structure.
The IETF sipping WG has been developing two models for transcoding
services: Third Party Call Control Transcoding Model[4][6-7] and
Conference Bridge Transcoding Model[5]. The Third Party Call Control
Transcoding Model is suitable for advanced end points that are able
to perform third party call control. The Conference Bridge
Transcoding Model is suitable for a centralized conference. These two
models are useful for a specific application invoked rarely to
support deaf, hard of hearing and speech-impaired individuals[2].
We need another model that is useful for general application[8]
invoked frequently[9]. A transcoding function is needed in cases of
interworking between different networks with different codecs and
communicating between different applications (e.g., text and speech).
2. Purpose and scope
The direct transcoding requirements described within this document.
3. Background
There are heterogeneous networks, media types and applications. Some
examples of heterogeneous networks are ones between PSTN and
3GPP/3GPP2, PSTN and Internet Telephony, or Internet Telephony and
3GPP/3GPP2. Examples of media types are a communication in real time
between voice and text, video/voice and voice, or video/voice and
text. Examples of applications are call forwarding and conference
call.
Codecs are adapted depending on networks, media types, and
applications. We need a transcoding requirement between different
codecs for global communication.
Taegyu Kang Expires - December 2005 [Page 4]
Direct Transcoding requirement June 2005
There are several cases for call scenarios with codecs
1) Case with same codec between calling party and called party
+-------+ +-------+
| |<----SIP---->| |
| A | | B |
| a |----Media----| a |
+-------+ +-------+
Figure 1: Case with same codec
2) Case with call setup failure due to codec mismatch
+-------+ +-------+
| |<----SIP---->| |
| A | | B |
| a |----Media----| b |
+-------+ +-------+
Figure 2: Case with call setup failure
3) Case with request for another transcoding server
+-------+ +-------+ +-------+
| |<----SIP---->| |<----SIP---->| |
| A | | B | | C |
| a | | b |----Media----| a-b |
+-------+ +-------+ +-------+
| |
+-------Media-------------------------------+
Figure 3: Case for an additional request
4) Case with controlling by conference server
+-------+ +-------+ +-------+
| |<----SIP---->| C |<----SIP---->| |
| A | |a-b,a-c| | B |
| a |----Media----| b-c |----Media----| b |
+-------+ +---+---+ +-------+
|
| +-------+
|<--------SIP---->| |
| | D |
+--------Media----| c |
+-------+
Figure 4: Case with central controller
Taegyu Kang Expires - December 2005 [Page 5]
Direct Transcoding requirement June 2005
5) Case with transcoding processing in transit party
+-------+ +-------+ +-------+
| |<----SIP---->| |<----SIP---->| |
| A | | T | | B |
| a |----Media----|a-b,a-c|----Media----| c |
+-------+ +-------+ +-------+
Figure 5: Case with direct transcoding function
Case 1 has the most efficient media processing among the 5 cases.
Case 1 does not need transcoding because there is only one codec or
the same codec.
Case 2 can not connect a call due to codec mismatch. We should avoid
Case 2 during call setup stage.
Case 3 is a transcoding model by new INVITE to invoke transcoding in
the third party.
Case 4 is a transcoding model by re-INVITE to invoke transcoding in a
transit party.
Case 5 is a transcoding model by direct transcoding in a transit
party.
The Direct Transcoding Model, case 5, is a useful solution from the
point of ITSP(Internet Telephony Service Provider). In an ITSP
environment, all call control messages should be controlled by the
ITSP server, ITSP can provide service to terminals with all kinds of
codecs. ITSP media server has a transcoding function and call
control by itself. This model has the advantage of no additional
messages between nodes and no modification for SIP call set up
standard.
The Direct Transcoding Model can be one of the solutions to network
convergence of PSTN, mobile network, internet telephony, and digital
broadcasting TV.
The models are compared by signaling traffic overhead. The Conference
bridge model and the Third party transcoding server model need an
additional signaling procedure for transcoding service whenever they
are invoked. The additional signaling procedure includes an
additional INVITE procedure with SIP/SDP between invoking point and
serving point. Conference bridge model and Third party transcoding
server model are useful for environments that rarely occur for the
transcoding service.
Taegyu Kang Expires - December 2005 [Page 6]
Direct Transcoding requirement June 2005
4. Service Requirement
The user requirements in this section are provided for the benefit of
end user and the convergence network providers.
4.1 No Constraint of Codec Adaptation
We should not restrict the use or choice of a specific codec. There
are several adaptable codecs by network, end user, and ITSP.
- The right of choice for codec by network
- The right of choice for codec by end user
- The right of choice for codec by ITSP
Networks have adapted a specific codec since the PSTN era; G.711 in
PSTN, AMR in GSM(3GPP), EVRC, QCELP or SMV in 3GPP. End users have
adopted any codec since internet phone; G.723.1, G.729, G.711, and
internet Low Bit Rate Codec (iLBC) Speech. ITSP tries to provide a
transcoding function for wider service coverage. It is possible to
communicate between users with a heterogeneous codec.
We should make a model for more successful call set up regardless of
different codecs between calling and called party. So, we can freely
choose codecs according to our preference.
Direct transcoding model should accept all kinds of codecs supported
by network, end user, or ITSP.
4.2 Interoperability of Models
We can make a call flow with a sequence of transcoding models
according to a service requirement. The service requirements can be
provided by a third party server, a central controlling server, or an
intermediary provider. The available models are:
- No transcoding model
- 3pcc transcoding model
- Conference call transcoding model
- Direct transcoding model
The direct transcoding model should not affect the other transcoding
models; no transcoding model, 3pcc transcoding model, and conference
call transcoding model. Even though the models are different between
calling party and called party, direct transcoding model can
communicate to the other side supported by a different model without
any other requirements.
Taegyu Kang Expires - December 2005 [Page 7]
Direct Transcoding requirement June 2005
5. Call Control Requirement
The following is a detailed description of the transcoding call
control requirement.
5.1 Exchange of codec information
Direct transcoding model should provide the below information to the
other side.
- a transcoding capability
- a discriminator for codec characteristics
- a preference order for codecs
The transit party should provide all transcoding capability to
calling party and called party during call set up procedures. This
minimizes codec mismatch call setup failure due to a lack of codec
negotiation information.
A discriminator for codec characteristics should provide the codec
information whether transcoded or not. The discriminator prevents re-
transcoding or transcoding-cycling from occurring. The transcoding
can decrease the quality of codec, so the number of transcodings are
minimized if possible.
A preference order for codecs should be provided by the other side
according to a codec quality. The preference is useful for codec
negotiation during the call set up.
5.2 Minimizing of Call set up delay
End user requires connectivity, speed, and efficiency for internet
telephony. The requirements of call set up are:
- based on SIP and Offer/Answer
- no interaction with user
- minimize call set up delay due to transcoding
- minimize the number of call waiting states during call set up
procedure
Direct transcoding model should be applied the principle based on
SIP[1] and Offer/Answer[3]. The independence between the model and
SIP is useful for its self-development and re-use independently.
We need a model for various codecs without user interaction.
Taegyu Kang Expires - December 2005 [Page 8]
Direct Transcoding requirement June 2005
Transcoding processing time should be minimized during the setup. If
we have to wait for a long time to setup another party, the
transcoding model will be useless.
The increase of call waiting states number for transcoding call set
up procedure make the network performance worse.
6. Security Considerations
This document does not introduce any new security considerations.
7. IANA Considerations
This document does not contain any IANA actions.
References
1. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force,
June 2002.
2. N. Charlton, M. Gasson, G. Gybels, M. Spanner, 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, Internet Engineering Task Force, Aug. 2002.
3. J. Rosenberg and H. Schulzrinne, " An offer/answer model with
session description protocol (SDP)," RFC 3264, Internet
Engineering Task Force, June 2002.
4. J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, "
Best current practices for third party call control in the
session initiation protocol," RFC 3725, Internet Engineering Task
Force, Jan. 2004. Work in progress.
5. G. Camarillo, " The session initiation protocol conference bridge
transcoding model," Internet Draft draft-camarillo-sipping-
transc-b2bua-00, Internet Engineering Task Force, Aug. 2003.
Work in progress.
6. G. Camarillo, " Framework for Transcoding with the Session
Initiation Protocol," Internet Draft draft-ietf-transc-framework-
00.txt, Internet Engineering Task Force, Feb. 2004. Work in
progress.
7. G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk,
" Transcoding Services Invocation in the Session Initiation
Protocol (SIP) Using Third Party Call Control (3pcc)," Sep 2004
Work in progress.
8. A. van Wijk, " Framework of requirements for real-time text
conversation using SIP," Internet Draft draft-vanwijk-sipping-
Taegyu Kang Expires - December 2005 [Page 9]
Direct Transcoding requirement June 2005
toip-00, Internet Engineering Task Force, Jan. 2004. Work in
progress
9. Taegyu Kang, D.kim, Y. Kim, " Intelligent Transcoding Gateway
Model for Transcoding with the Session Initiation Protocol,"
Internet Draft draft-taegyukang-sipping-transc-itg-00.txt,
Internet Engineering Task Force, Jan. 2004. Work in progress
Author's Addresses
Taegyu Kang
tgkang@etri.re.kr
Multimedia Communications Team
161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea
Doyoung Kim
dyk@etri.re.kr
Multimedia Communications Team
161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea
Haewon Jung
hw-jung@etri.re.kr
BcN Core Technology Group
161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Taegyu Kang Expires - December 2005 [Page 10]
Direct Transcoding requirement June 2005
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Taegyu Kang Expires - December 2005 [Page 11]
