New subject: SIP-H.323 Interworking Call Scenarios

8 Mar 2000

      Hi, Kundan, Hemant, and Vipin:
It seems to me that Kundan's proposal is quite logical. In our terms of
reference document (TOR), we can scope our work in a 2-step approach as
follows:
The initial scope of the TOR:
- Simple SIP--SGW--H.323 translation, with SGW 
      independent of any GK or proxy.
    - Translating (blind) call transfer by endsystems.
    - Translating call forwarding by endsystems.
    - How to handle, SIP re-INVITEs (change in session description/or
media transport address) and change in H.323 logical channel/mode request.
    - How to handle H.323 fast start.
The expanded scope of the TOR:
- Call hold translation
    - Call transfer/forwarding by GK and/or proxy.
    - SIP--H.323--SIP and H.323---SIP---H.323 scenarios.
    - SGW coexiting with GK or proxy.
     ...
Please provide your comments.
Best regards,
Radhika R. Roy
AT&T
...
-----Original Message-----
From:	Kundan Singh [SMTP:kns10@cs.columbia.edu]
Sent:	Wednesday, March 08, 2000 1:04 PM
To:	Hemant Agrawal
Cc:	schulzrinne@cs.columbia.edu; jdrosen@dynamicsoft.com; korpim@sbs.de;
karl.klaghofer@vs.siemens.de; Roy, Radhika R, ALARC;
alan.johnston@wcom.com; steven.r.donovan@wcom.com; Kevin.Summers@wcom.com;
dean.willis@wcom.com; henry.sinnreich@wcom.com; VIPIN PALAWAT;
agboh@helios.iihe.ac.be; Robert.Sparks@wcom.com;
Chris.Cunningham@wcom.com; orit@radvision.com; taylor@NORTELNETWORKS.COM;
joon_maeng@vtel.com; drwalker@ss8networks.com; paul.jones@TIES.ITU.INT;
Dilber, Ayse, ALARC; stephen.terrill@ericsson.com
Subject:	Re: SIP-H.323 Interworking Call Scenarios
Hi Hemant and Vipin,
Its a very good collection of call flows' translation.
Few comments:

Might want to include H.323---SIP---H.323 case where the

call goes through two SGWs. Since, combining the
  two call flows (H.323-SIP, sec:1.1) and (SIP-H.323, sec:2.1)
  may not work. The SIP ACK in sec:1.1 has a different session
  description, which will trigger some "Mode Request"
  and/or "Open/Close LogicalChannel" procedures in
  sec:2.1.

In sec:1.1,1.2,1.3; it might be better to send ACK
immediately after receiving 200 OK, and send
re-INVITE once H.245 procedures are complete.
This way, we can avoid the retransmissions of 200 OK
by SIP EP if H.245 procedures take more time to complete.
Comments ??

In Fast Connect procedures (sec 3.1), I assume that
if the normal H.245 procedure resumes after initial
call setup (with faststart), and there is a change in
H.323 side session description, then appropriate
re-INVITE message is sent to SIP EP.

Sec:4 Call transfer may be renamed to (Blind) Call Tranfer.

Sec:4.1. RTP should be between SIP EP(B) and SIP EP(C)

Sec: 5.1, you may send "181 Call is being forwarded"
response to SIP (A).
  Can SIP (A) reject the call forwarding here ???
  Who pays for the call if the forwarded call
  costs more (longdistance/international) ? Any
  pointer to this topic is appreciated.

The call forwarding may be initiated by the
proxy (after receipt of 486 Busy Here) or by
the SIP endsystem itself (by responding with 302 Moved Temporarily)
if it is configured to do so. However, that will not
affect the translation much.

Sec:5.3, typo; SIP User (A) should be (B) and (B) should be (C).

Considering the wide variety of scenarios between
H.323 and SIP, would it be reasonable to start with
a simple call translation specification,
provide a state machine/pseudo code for
message handling by the SGW (signaling gateway)
and then extend the state machine/pseudo code
to handle all the non-trivial call scenarios.
Once the basic translation specification is ready,
profiles for extensions (e.g., blind transfer
using GK, call forwarding using proxy,
translating forking proxy behaviour to H.323, etc.)
may be specified.
Thus, the initial specification may cover following
areas:

Simple SIP--SGW--H.323 translation, with SGW 
independent of any GK or proxy.
Translating (blind) call transfer by endsystems.
Translating call forwarding by endsystems.
How to handle, SIP re-INVITEs (change
in session description/or media transport address) 
and change in 
H.323 logical channel/mode request.
How to handle H.323 fast start.

Later on other things may be added:

Call hold translation
Call transfer/forwarding by GK and/or proxy.
SIP--H.323--SIP and H.323---SIP---H.323 scenarios.
SGW coexiting with GK or proxy.

...
Motivation for such a separation is to allow
the implementors more freedom in deciding what
configuration to choose, while still maintaining
the basic translation framework.
For example, call forwarding to voicemail may
be handled by

the endsystem by sending 302 moved, after say 4 rings.
the proxy server on receipt of 486 busy here
the proxy server, forking one branch of the request to the voicemail

system which accepts the call after, say, 15 seconds.
It turns out that once we have the initial specification,
(as mentioned in above list) the advanced scenarios
are just a "special cases"/"combination of cases" of the
initial scenarios.
Regards
Kundan
Kundan Singh     http://www.cs.columbia.edu/~kns10
On Wed, 8 Mar 2000, Hemant Agrawal wrote:
...
Hi All,
There was a continuous discussion on the different configuration for the
SIP - H.323 interworking.
In our opinion, it would be better if some basic features (like Call
Transfer, Call Hold and Call forwarding) is also added as part of the
discussion.
We are enclosing some call flow examples of SIP-H.323 interworking.
Please
...
give your comments on these call flows. Our stress is on the call
features
...
and others are just informational. We have specified few issues also
inorder
...
to make these protocols interwork.
Kindly let us know if you agree to include the feature discussion also
as
...
part of the SIP - H.323 interworking. We are ready to put our efforts
for
...
the feature interworking.
Best Regards
Hemant Agarwal
Vipin Palawat

RE: SIP-H.323 Interworking Call Scenarios

Roy, Radhika R, ALARC

Kundan

VIPIN PALAWAT

Kundan

tags (0)

participants (2)