Internet DRAFT - draft-bhatia-sip-h323-interworking-3pcc
draft-bhatia-sip-h323-interworking-3pcc
M. Bhatia
Internet-Draft NexTone Communications
draft-bhatia-sip-h323-interworking-3pcc-00.txt
Oct 16, 2001
Expires: Apr 15, 2002
Third Party Call Control in SIP-H.323 Interworking
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 [Apr 15, 2002].
Abstract
This document discusses third party call control in a SIP-H.323
Interworking environment. Third party call control refers to the
ability of one entity to create a call in which communications is
actually between other parties [1]. The SIP-H.323 Interworking
function is discussed in [4]. Here we discuss how the Interworking
entity can function as a controller for third party call
control, as well as an party to it.
1. Introduction
The basic scenarios of third party call control (3pcc) for SIP are
discussed in [1,8]. H.323 can be used to implement such a scenario
on the gatekeeper using the gatekeeper controlled call routing and
pausing mechanisms described in [5].
The basic scenarios of SIP-H.323 Interworking (IWF) are described
in [4]. It defines the logical entity known as the SIP-H.323
Interworking Function (IWF) that will allow the interworking
between the SIP (Session Initiation Protocol) [3] and H.323
protocols [5,6,7]. IWF includes call sequence mapping, message
parameter mapping, translation between H.245 and SDP, state
machines, and handling of different call procedures.
2. Definitions
controller: the entity which sets up a call relationship
between two parties. This has the same meaning as in
[1].
A, B: Peers of the controller in a call setup using third
party call call control. A will be understood to be on
leg 1 of the call, which is set up first and B to be
on the leg 2 of the call which is bridged with leg 1
subsequently.
3. Background
In general, the application logic of third party call control is
completely implemented on the controller, and the parties involved
(A,B) are completely unaware of it. For example the approach
described in [1] suggests two call flows (referred as "flow 1" and
"flow 3" in this document), where the controller sets up calls to
two parties A and B, and then bridges the calls together. The basic
technique used to do this is the INVITE method without SDP. Another
approach described in [8] uses the REFER method [2]. The similarity
between the two approaches is that they allow the controller to
facilitate information (e.g SDP) exchange between the two parties
without getting involved in the details of what gets exchanged.
In this document we focus on the case where the third party call
control logic is based on the IWF. We extend from the call flows
("flow 1" and "flow 3") in [1]. The IWF mode allows either of A or
B to be a SIP or an H.323 endpoint. This leads to two scenarios in
general:
A (SIP) <---> IWF <---> B (H.323)
A (H.323) <---> IWF <---> B (SIP)
In addition "flow 1" may be applied at either the beginning of a
call or in the middle of existing calls, where the IWF may have
an ongoing call with either A or B, which it is bridging with the
other party. In general this ongoing call may be on hold or
connected to a music server.
For describing our flows, we mostly use those described in [4]. All
additional flows we use are described in the auxiliary flows in
section 6. In addition the flows described in section 6 are also
useful when the IWF acts as a party (A or B) in third party call
control.
4. Structure of document
Call flows in this document are essentially divided into two
categories:
(1) Call flows where IWF acs as the controller. Here we extend from
"flow 1" and "flow 3" specified in [1]. (Section 5)
(2) Auxiliary call flows. Although the call flows described in the
first category may appear independent, they depend on the call
flows in this category when either of A or B is also an instance of
IWF. In these situations the controller may be an IWF gateway or a
SIP Proxy or even an H.323 gatekeeper. (Section 6)
In general while presenting call flows here, we have taken a lot of
liberty in excluding messages which may complicate the depiction of
the call flow. The reader is assumed to be familiar with basic IWF
functions and mapping described in [4]. For example, H.323 messages
like H.225 Alerting, Call Proceeding, H.245 Master Slave
Determination etc are not depicted in any call flows even though
they may be utmost necessary for them to happen.
5. IWF is the 3pcc controller
5.1 "flow 1" from 3pcc draft[1]:
5.1.1 Case 1.A: Beginning of call to B, assuming B will immediately
accept the call. The first leg in the flow (A) is assumed
to be a SIP UA. The INVITE to A may be at the start of a
call to A or in the middle of an already ongoing call to A.
If A happens to be an instance of IWF, we may either Flow 3 or
Flow 5 happening when looking at the flow from A's viewpoint.
A (SIP) IWF B (H.323)
| | |
| | |
| INV no SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| | Setup |
| |----------------->|
| | |
| | Connect |
| |<-----------------|
| | |
| | TCS |
| |<---------------->|
| | |
| | OLCs |
| |<---------------->|
| | |
| ACK SDP | |
|<-------------------| |
| | |
Figure 1: Flow 1.A (3pcc)
5.1.2 Case 1.B: Middle of call to B, assuming the call is connected
completely and H.245 is already done on the H.323 leg (leg 2).
The first leg in the flow (A) is assumed to be a SIP
endpoint. The INVITE to A may be at the start of a
call to A or in the middle of an already ongoing call to A.
If A happens to be an instance of IWF, we may either Flow 3 or
Flow 5 happening when looking at the flow from A's viewpoint.
A (SIP) IWF B (H.323)
| | |
| | |
| INV no SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| | TCS |
| |<---------------->|
| | |
| | OLCs |
| |<---------------->|
| | |
| ACK SDP | |
|<-------------------| |
| | |
Figure 2: Flow 1.B (3pcc)
5.1.3 Case 1.C: Beginning or middle of call to B, assuming B will
immediately accept the call. The first leg in the flow (A) is
assumed to be an H.323 endpoint.
A (H.323) IWF B (SIP)
| | |
| | |
| Setup | |
|<-------------------| |
| | |
| Connect | |
|------------------->| |
| | |
from this point we use Flow 1.B:
| | |
| | INV no SDP |
| |----------------->|
| | |
| | 200 OK SDP |
| |<-----------------|
| | |
| TCS | |
|<------------------>| |
| | |
| OLCs | |
|<------------------>| |
| | ACK SDP |
| |----------------->|
| | |
| | |
Figure 3: Flow 1.C (3pcc)
5.1.4 Case 1.D: Middle of call to A, assuming the call is connected
completely and H.245 is already done on the H.323 leg.
The first leg in the flow (A) is assumed to be an H.323
endpoint. A NULL TCS may have been sent to A as part of the
call re-routing and pausing mechanisms described in [5] at the
beginning of the call flow.
The INVITE to B may be the start of a new call to B or in the
middle of an ongoing call between IWF and B.
A (H.323) IWF B (SIP)
| | |
| | |
| TCS | |
|<-------------------| |
| | |
| OLC | |
|------------------->| |
| | |
| | INVITE SDP |
| |----------------->|
| | |
| | 200 OK SDP |
| |<-----------------|
| | |
| OLC ACK | |
|<-------------------| |
| | ACK |
| |----------------->|
| | |
| OLC | |
|<-------------------| |
| | |
| OLC ACK | |
|------------------->| |
| | |
Figure 4: Flow 1.D (3pcc)
5.2 "flow 3" from 3pcc draft[1]:
Flow 3 from the 3pcc draft[1] is used in the general scenario
where no assumption can be made about the nature of A or B or
of the state of the call (beginning or middle of call).
In each case, leg 1 (leg 2) may be either SIP (H.323) or H.323
(SIP).
5.2.1 Case 2.A: The first leg in the flow (A) is assumed to be a SIP
UA. The INVITE to A may be the start of a new call or in the
middle of an ongoing call between A and IWF. The Setup and
Connect depicted in the flow are necessary only when the IWF
is initiating a new call to B.
A (SIP) IWF B (H.323)
| | |
| | |
| INV no SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| ACK Held/Music SDP | |
|<-------------------| |
| | Setup |
| |----------------->|
| | |
| | Connect |
| |<-----------------|
| | |
From here we use flow 1.D:
| | TCS |
| |<---------------->|
| | |
| | OLC |
| |<-----------------|
| | |
| INV SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| | OLC Ack |
| |----------------->|
| | |
| ACK | |
|<-------------------| |
| | |
| | OLC |
| |----------------->|
| | |
| | OLC Ack |
| |<-----------------|
| | |
Figure 5: Flow 2.A (3pcc) (uses Flow 1.D)
5.2.2 Case 2.B: The first leg in the flow (A) is assumed to be an
H.323 endpoint.
A (H.323) IWF B (SIP)
| | |
| | |
| Setup | |
|<-------------------| |
| | |
| Connect | |
|------------------->| |
| | |
| TCS | |
|------------------->| |
| | |
| TCS NULL | |
|<-------------------| |
| | |
From this point we use Flow 1.B:
| | |
| | INV no SDP |
| |----------------->|
| | |
| | 200 OK SDP |
| |<-----------------|
| | |
| TCS | |
|<-------------------| |
| | |
| OLCs | |
|<------------------>| |
| | ACK SDP |
| |----------------->|
| | |
Figure 6: Flow 2.B (3pcc) (uses Flow 1.B)
6. Auxiliary Call Flows:
Although the call flows described in the first category may appear
independent, they depend on the call flows in this category when
either of A or B is also an instance of IWF.
6.1 SIP/H.323 Call flows with INVITE no SDP in middle of call
A (SIP) IWF B (H.323)
| | |
| | |
| INV no SDP | |
|------------------->| |
| | |
| 200 OK SDP | |
|<-------------------| |
| | |
| ACK SDP | |
|------------------->| |
| | |
From here, we use Flow 1.D:
| | |
| | TCS |
| |----------------->|
| | |
| | Close OLCs |
| |<---------------->|
| | |
| | OLC |
| |<-----------------|
| | |
| INVITE SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| | OLC Ack |
| |----------------->|
| | |
| ACK | |
|<-------------------| |
| | |
| | OLC |
| |----------------->|
| | |
| | OLC Ack |
| |<-----------------|
| | |
Figure 7: Flow 3, INVITE no SDP in middle of call (uses Flow 1.D)
6.2 SIP/H.323 Call flows with REFER in beginning of call (REFER
with no call context):
A (SIP) IWF B (H.323)
| | |
| | |
| REFER | |
|------------------->| |
| | |
from this point Flow 2.A:
| | |
| | |
| INV no SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| ACK Held/Music SDP | |
|<-------------------| |
| | Setup |
| |----------------->|
| | |
| | Connect |
| |<-----------------|
| | |
| | TCS |
| |<---------------->|
| | |
| | OLC |
| |<-----------------|
| | |
| INV SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| | OLC Ack |
| |----------------->|
| | |
| | OLC |
| |----------------->|
| | |
| | OLC Ack |
| |<-----------------|
| | |
| ACK SDP | |
|<-------------------| |
| | |
Figure 8: Flow 4, REFER from SIP, beginning of call (uses Flow 2.A)
6.3 SIP/H.323 Call flows using INVITE no SDP in beginning
of call
A (SIP) IWF B (H.323)
| | |
| | |
| INV no SDP | |
|------------------->| |
| | |
| | Setup |
| |----------------->|
| | |
| | Connect |
| |<-----------------|
| | |
| | TCS |
| |<-----------------|
| | |
| | TCS Gen |
| |----------------->|
| | |
| | OLC |
| |<-----------------|
| | |
| 200 OK SDP | |
|<-------------------| |
| | |
| ACK SDP | |
|------------------->| |
| | TCS |
| |----------------->|
| | |
| | OLC Acks/OLJs |
| |----------------->|
| | |
Figure 9: Flow 5, INVITE no SDP from SIP, beginning of call
6.4 SIP/H.323 Call flows with REFER in middle of call (REFER
inside an existing call context)
A (SIP) IWF B (H.323)
| | |
| | |
| REFER | |
|------------------->| |
| | |
| | TCS Gen |
| |----------------->|
| | |
| | OLC |
| |<-----------------|
| | |
| INVITE SDP | |
|<-------------------| |
| | |
| 200 OK SDP | |
|------------------->| |
| | |
| ACK | |
|<-------------------| |
| | TCS |
| |----------------->|
| | |
| | OLC Acks/OLJs |
| |----------------->|
| | |
Figure 10: Flow 6, REFER from SIP, middle of call (uses Flow 5)
6.5 SIP/H.323 Call flows with INVITE SDP in middle of call
A (SIP) IWF B (H.323)
| | |
| | |
| INV SDP | |
|------------------->| |
| | |
| | TCS |
| |----------------->|
| | |
| | OLCs |
| |<---------------->|
| | |
| 200 OK SDP | |
|<-------------------| |
| | |
| ACK | |
|------------------->| |
| | |
| | |
Figure 11: Flow 7, INVITE SDP in middle of call
6.6 SIP/H.323 Call flows with TCS in middle of call
A (H.323) IWF B (SIP)
| | |
| | |
| TCS | |
|------------------->| |
| | |
| | REFER |
| |----------------->|
| | |
| | INV SDP+Replaces |
| |<-----------------|
| | |
| OLCs | |
|<------------------>| |
| | |
| | 200 OK SDP |
| |----------------->|
| | |
| | ACK |
| |<-----------------|
| | |
Figure 12: Flow 8, TCS in middle of call (uses Flow 7)
6.7 SIP/H.323 Call flows using Setup no/failed fast start
A (H.323) IWF B (SIP)
| | |
| | |
| Setup | |
|------------------->| |
| | |
| | INV no SDP |
| |----------------->|
| | |
| | 200 OK SDP |
| |<-----------------|
| | |
| Connect | |
|<-------------------| |
| | |
| TCS | |
|<------------------>| |
| | |
| OLCs | |
|<------------------>| |
| | ACK SDP |
| |----------------->|
| | |
| | |
Figure 13: Flow 9, Setup no fast start
7. References
[1] Rosenberg/Peterson/Schulzrinne/Camarillo, "Third Party Call
Control in SIP" Internet Draft, Internet Engineering Task Force,
Mar 2002. Work in progress.
[2] Sparks, R. "The Refer Method", Internet Draft, Internet
Engineering Task Force, Sep 2001. Work in progress.
[3] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[4] Agrawal, H., "SIP-H.323 Interworking", Internet Draft, Internet
Engineering Task Force, Sep 2001. Work in progress.
[5] "Packet based multimedia communication systems",
Recommendation H.323 Version 2,ITU-T,Geneva,Switzerland,Feb. 1998.
[6] "Call Signaling Protocols and Media Stream Packetization for
Packet Based Multimedia Communications Systems", Recommendation
H.225.0 Version 2, ITU-T, Geneva, Switzerland, March 1997.
[7] "Control protocol for multimedia communication",
Recommendation H.245.0 Version 3, ITU-T, Geneva, Switzerland,
Feb. 1998.
[8] Bhatia, M., "3pcc using the REFER method", Internet Draft, Internet
Engineering Task Force, Sep 2001. Work in progress.
Author's Address
Medhavi Bhatia
NexTone Communications
9700 Great Seneca Highway
Rockville, MD 20874
EMail: mbhatia@nextone.com
Expires: Apr 15, 2002 Third Party Call Control in SIP-H.323 Interworking
