SIP-H.323 Interworking Call Scenarios

Roy, Radhika R, ALARC rrroy at att.com
Wed Mar 8 14:30:12 EST 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 at cs.columbia.edu]
> Sent:	Wednesday, March 08, 2000 1:04 PM
> To:	Hemant Agrawal
> Cc:	schulzrinne at cs.columbia.edu; jdrosen at dynamicsoft.com; korpim at sbs.de;
> karl.klaghofer at vs.siemens.de; Roy, Radhika R, ALARC;
> alan.johnston at wcom.com; steven.r.donovan at wcom.com; Kevin.Summers at wcom.com;
> dean.willis at wcom.com; henry.sinnreich at wcom.com; VIPIN PALAWAT;
> agboh at helios.iihe.ac.be; Robert.Sparks at wcom.com;
> Chris.Cunningham at wcom.com; orit at radvision.com; taylor at NORTELNETWORKS.COM;
> joon_maeng at vtel.com; drwalker at ss8networks.com; paul.jones at TIES.ITU.INT;
> Dilber, Ayse, ALARC; stephen.terrill at 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:
> 
> 1) 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.
> 
> 2) 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 ??
> 
> 3) 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.
> 
> 4) Sec:4 Call transfer may be renamed to (Blind) Call Tranfer.
> 
> 5) Sec:4.1. RTP should be between SIP EP(B) and SIP EP(C)
> 
> 6) 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.
> 
> 7) 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.
> 
> 8) 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
> > 
> > 
> > 



More information about the sg16-avd mailing list