One document matched: draft-hwang-sipping-infomidcall-00.txt
J. Hwang
Internet Draft
Document: draft-hwang-sipping-infomidcall- KT
00.txt
Expires: July 2004 February 2004
INFO Usage Examples for Network-based Mid-Call Service
draft-hwang-sipping-infomidcall-00.txt
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.
Abstract
This document describes the INFO usage examples for network based
mid-call service. Mid-call based services are for example, Call
Transfer, Call Waiting, and Three-Way Calling. Other possible mid-
call services are useful and important, even more in IP multimedia
network. The cases described in SIP service examples (draft-ietf-
sipping-service-examples-05) are Terminal-basis. Since the service
procedures are fixed in the Terminal, the features are not extensible.
This document propose network-based mid-call control mechanism with
INFO and show examples that simple mid-call request (INFO) from the
Terminal, the network application server provide various mid-call
services by prompting user through the Media Server, according to the
subscription information of the user.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Network-based Mid-Call Service Examples.........................3
2.1 Call Transfer..................................................5
Hwang Informational - Expires July 2004 1
INFO usage examples for Network based February 2004
mid-call control
2.2 Call Waiting...................................................6
3. Other Possible Examples.........................................8
4. Proposed INFO format............................................8
5. Security Considerations.........................................9
6. IANA Considerations.............................................9
References........................................................10
Author's Addresses................................................10
Intellectual Property Statement...................................10
Full Copyright Statement..........................................10
Hwang Informational - Expires July 2004 2
INFO usage examples for Network based February 2004
mid-call control
1. Introduction
The SIP INFO method [1] is defined for carrying application level
information along the session signaling path during the call session.
The main purpose of INFO is the mid-call information delivery,
especially PSTN signaling messages between PSTN gateways through SIP-
T [2]. Mid-Call services are for example, call transfer, call waiting,
three-way calling and etc. Mid-call feature is for calling or called
party to request the services in the middle of the call. As this is
useful and essential feature in PSTN, the IP-based Next Generation
Network (NGN) where various multimedia services are to be provided
even more requires the enhanced mid-call services.
In [3], several mid call service examples are described. The cases
are terminal-basis. Since the service procedures are fixed and the
buttons are predefined in the terminal, the features are not
extensible.
This document proposes network-based mid-call control mechanism with
INFO. Two examples are described that simple mid-call request (INFO)
from the Terminal, the network application server provide various
mid-call services by prompting user through the Media Server,
according to the subscription information of the user or predefined
configuration. Addition of media type to Content-Type header in INFO
is also proposed.
2. Network-based Mid-Call Service Examples
To provide network-based mid-call services, the terminal only has a
mid-call request function (INFO) and the services are on the
application server side. Binding between the terminal and the
services are possible in several ways.
1) Predefined mapping the terminal and the service
2) User's configuration of the preferred mid-call service (for
example, through web page)
3) Network application service provides full options to
choose by prompting user to select call waiting, call
transfer, etc when user requests a mid-call.
The examples in this document assume 1) or 2).
Network architecture for network-based mid-call service is depicted
in Figure 1.
o Softswitch includes two interfaces to the subscriber side: one is
SIP interface to SIP phone and the other is MEGACO interface to POTS
phone. Softswitch has the trigger function that routing requests from
the terminal to appropriate application service. For mid-call
requests, SIP phone SHOULD have mid-call button that initiate INFO
message; From POTS phone, user makes 'hook-flash', then AGW notify to
Softswitch and the Softswitch generates INFO message to Application
Hwang Informational - Expires July 2004 3
INFO usage examples for Network based February 2004
mid-call control
server. This contribution only concerns the SIP interface between
Application server and Softswitch(SIP block mapped on MGC) or
Application server and the terminal. The MEGACO interface is shown
here for general mid-call environment including POTS phone.
o Application server includes several mid-call services. It has SIP
interfaces to Softswitch and Media Server.
We assume that the service model in Application server is B2BUA.
Since the mid-call is requested from the terminal and the Application
server receives and processes it, the mid-call INFO request is ended
at the Application server. Therefore the UAC of the INFO is terminal
(or SIP block mapped on MGC in the Softswitch) and the UAS of the
INFO is Application server.
o Media Server includes prompting and announcement functions. It
interfaces to Application server with SIP and provides media control
and processing resources controlled by the Application server.
Mid-call services
+----+ +----+ +----+ +---+
+-| CW |-| CT |-| TWC|-|...|-+
| +----+ +----+ +----+ +---+ | SIP
| Application Server +--------+
| /-------\ | |
| |UAS/UAC| | |
| \-------/ | |
+------------+---------------+ |
| |
SIP | +----+----+
| | Media |
+------------+---------------+ | Server |
| SIP Proxy Server | +----+----+
| (Softswitch) | **
| /-------\ | **
| |UAC/UAS| | **
| \-------/ | **
| +--------+ | **
| | MGC | | **
+---+-----------+----+---+---+ **
| MEGACO | **
| +----+---+ **
SIP| | AGW |************** RTP
| +----+---+ *
/-------\ | *
|UAC/UAS| | *
\-------/ | *
+---+ +---+ *
|| || || || *
+ + + + *
+++++ +++++ *
* *
Hwang Informational - Expires July 2004 4
INFO usage examples for Network based February 2004
mid-call control
************************************
(SIP phone) (POTS phone)
CW: Call Waiting service
CT: Call Transfer service
TWC: Three Way Calling service
MGC: Media Gateway Controller
AGW: Access Gateway
POTS: Plain Old Telephone Service
Figure 1: Network Architecture for network-based Mid-call services
2.1 Call Transfer
Call transfer is the service that during a call between two parties,
transferor initiates a mid-call and input the 2nd callee's (transfer
target) number, then the transferee and the 2nd callee (transfer
target) are connected.
Network based call transfer flow is presented in Figure 2.
(Transferor)(Transferee)(Transfer
Target)
Original Original 2nd Softswitch Application Media
Caller Callee Callee (SIP Proxy) Server Server
(A) (B) (C)
| RTP F1 | | | | |
|<==========>| | | | |
| 'Hook | INFO(mid-call) F2 | | |
|--Flash'------------------------------o----------->| |
| | 200 OK F3 | | |
|<-------------------------------------o------------| |
| | INVITE (hold) F4 | | |
| |<------------------------o------------| |
| | 200 OK F5 | | |
| |-------------------------o----------->| |
| | ACK F6 | | | |
| RTP hold |<------------------------o------------|INVITE(noSDP)F7
|<//////////>| | | |----------->|
| | | | |200OK(SDP MS)F8
| | reINVITE(SDP MS) F9 | |<-----------|
|<-------------------------------------o------------| |
| | 200 OK (SDP A) F10 | | |
|--------------------------------------o----------->| |
| | | | |ACK(SDP A)F11
| | ACK F12 | | |----------->|
|<-------------------------------------o------------| |
| | RTP F13 | | | |
|<==============================================================>|
| | | | |INFO(pc) F14|
| | | | |----------->|
| | | | |200 OK F15 |
| |"Please input transferring number" F16|<-----------|
Hwang Informational - Expires July 2004 5
INFO usage examples for Network based February 2004
mid-call control
|<**************************************************************>|
| | (user input C's digit number) |INFO(oc,C)F17
| | | | |<-----------|
| | | | | 200 OK F18 |
| | | | |----------->|
| | | | | BYE F19 |
| | | | |----------->|
| | | | | 200 OK F20 |
| | | INVITE (no SDP) F21 |<-----------|
| | |<-----------o------------| |
| | | 200 OK (SDP C) F22 | |
| | |------------o----------->| |
| | reINVITE(SDP C) F23 | | |
| |<------------------------o------------| |
| | 200 OK (SDP B) F24 | | |
| |-------------------------o----------->| |
| | ACK F25 | | | |
| |<------------------------o------------| |
| | | ACK (SDP B) F26 | |
| | RTP F27 |<-----------o------------| |
| |<==========>| | | |
| | BYE F28| | | |
|<-------------------------------------o------------| |
Figure 2. Call Transfer Scenario
- F1: User A and B have conversation with the RTP connection.
- F2~F3: User A decides to transfer the call to User C. He pushes the
'mid-call' button in the phone. Then INFO request is delivered to
Application server through Softswitch (SIP Proxy). Application server
decides that the request comes from Call Transfer subscriber. It
answers with 200 OK. (As we mentioned in the head of the Section 2,
the decision can be made in several ways)
- F4~F6: Application server holds the phone of User B to suspend RTP
packets.
- F7~F16: Application server connects User A and Media Server, and
prompt and collect user information the transferring number. User A
inputs User C's phone number. In this case, we assume that the MCGP
Audio package [4] is used to control the Media Server play
announcement and collect digits and as the transport, INFO method is
used.
- F17~F20: Media server sends the collected number (C) to Application
Server. Application server disconnect with Media server.
- F21~F27: Application server connects User C and User B by 3PCC. The
RTP connection is established.
- F28: Application server sends BYE to User A. The RTP connection
between User A and User B finally released.
2.2 Call Waiting
Call Waiting is the feature that during a call, the subscriber to be
notified another incoming call arrival to his phone.
Network based call waiting scenario is depicted in Figure 3.
Hwang Informational - Expires July 2004 6
INFO usage examples for Network based February 2004
mid-call control
(Call Waiting
Subscriber)
Original Original 2nd Softswitch Application Media
Caller Callee Caller (SIP Proxy) Server Server
(A) (B) (C)
| RTP F1 | | | | |
|<==========>| | | | |
| | | INVITE B (SDP C) F2 | |
| | |------------o----------->| |
| | | 180 Ringing F3 | |
| | |<-----------o------------| |
| | | | |INVITE(noSDP)F4
| | | | |----------->
| | | | |200OK(SDP MS)F5
| | INVITE (SDP MS) F6 | |<-----------|
| |<------------------------o------------| |
| | 200 OK (SDP B) F7 | | |
| |-------------------------o----------->| |
| | ACK F8 | | | |
| |<------------------------o------------| |
| | | | |ACK(SDP B)F9|
| | RTP F10 | | |----------->|
| |<=================================================>|
| | | | INVITE(noSDP)F11
| | | | |----------->
| | | | 200OK(SDP MS)F12
| | INVITE (SDP MS) F13 | |<-----------|
|<-------------------------------------o------------| |
| | 200 OK (SDP A) F14 | | |
|--------------------------------------o----------->| |
| | ACK F15 | | | |
|<-------------------------------------o------------|ACK(SDP B)F16
| | RTP F17 | | |----------->|
|<==============================================================>|
| | | | |INFO(pa) F18|
| | | | |----------->|
| | | | |200 OK F19 |
| | 'Waiting Tone' F20 | |<-----------|
| |<**************************************************|
| "Hook | INFO (mid-call) F21 | | |
| Flash" |-------------------------o----------->| |
| | 200 OK F22 | | |
| |<------------------------o------------INVITE(hold)F23
| | | | |----------->|
| | | | | 200 OK F24 |
| | | | |<-----------|
| | | | | ACK F25 |
| | RTP hold| | |----------->|
|<//////////////////////////////////////////////////////////////>|
| | | | INVITE(noSDP)F26
| | | | |----------->|
Hwang Informational - Expires July 2004 7
INFO usage examples for Network based February 2004
mid-call control
| | | | 200OK(SDP MS)F27
| | | 200 OK (SDP B) F28 |<-----------|
| | |<-----------o------------| |
| | | ACK F29 | | |
| | |------------o----------->|ACK(SDP B)F30
| | | RTP F31 | |----------->|
| | |<====================================>|
Figure 3. Call Waiting Scenario
- F1: User A and B have conversation with the RTP connection.
- F2~F3: User C calls to User B. Application server receives the
INVITE through the Softswitch (SIP Proxy) and know that the called
party (User B) is the Call Waiting subscriber and he is busy now. It
sends 180 Ringing to calling User C
- F4~F10: Application server connects User B with the switching
resource in Media Server. With this, bridging between two party among
three can be established efficiently.
- F11~F17: Application server connects User A and Media Server and
make a bridge between A and B by the switch in Media Server.
- F18~F22: To provide 'Call Waiting Tone' to the subscriber B,
Application server sends INFO with play announcement event and the
tone parameter [4]. Notified by the call waiting tone, User B
requests the mid-call by pushing mid-call button in the phone.
- F23~F25: Application server sends hold INVITE to Media server to
suspend RTP packets between User A and User B.
- F26~F31: Application Server adds the User C to the switch in Media
Server and connects between User B and User C. RTP connection is
established and User B and C can talk each other.
When User B push mid-call button (or Hook Flash), the switch between
User B and C is disconnected, and the User A and B is reconnected and
resume the conversation.
3. Other Possible Examples
Allowing service interactions between user and the services during
the call, the application of the mid-call feature is broad depending
on the applicable service domains.
Other than the scenarios in Section 2, possible mid-call examples
are:
- Attendant connection in IP-PBX
- Call disposition (such as forwarding to Voicemail) during the call
- Any user-service interaction services during the call.
4. Proposed INFO format
We propose that for the INFO message format to be used in mid-call
request, use the media type "midcall" as follows:
Hwang Informational - Expires July 2004 8
INFO usage examples for Network based February 2004
mid-call control
Content-Type: application/midcall
Content-Length:0
5. Security Considerations
This document introduces no new considerations for Security.
6. IANA Considerations
This document introduces no new considerations for IANA.
Hwang Informational - Expires July 2004 9
INFO usage examples for Network based February 2004
mid-call control
References
[1] Donovan, S., "The SIP INFO Method" RFC 2976, October 2000
[2] Vemuri. A., Peterson, J., "SIP-T: Context and Architecture" RFC
3372, September 2002
[3] Johnston, A., Sparks R., Cunningham C. Donovan S., Summers K.
"Session Initiation Protocol Service Examples" draft-ietf-sipping-
service-examples-05 (work in progress), August 29, 2003
[4] Cromwell, D., "Proposal for an MGCP Advanced Audio Package" RFC
2897, August 2000
Author's Addresses
Jinkyung Hwang
KT
17 Woomyun-dong Phone: 82-2-526-6830
Seocho-gu, Seoul Korea Email: jkhwang@kt.co.kr
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 (2004). 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
Hwang Informational - Expires July 2004 10
INFO usage examples for Network based February 2004
mid-call control
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hwang Informational - Expires July 2004 11
| PAFTECH AB 2003-2026 | 2026-04-24 02:52:43 |