SIP-H.323 Interworking Call Scenarios

VIPIN PALAWAT vipin.palawat at wipro.com
Thu Mar 9 07:19:36 EST 2000


Hello Kundan,

Thanks for the detailed comments.
We have put our views and opinions in the "blue" font.
Kindly give us the comments for our views.

> 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.
> 
     Fine, I will prepare this case and send it for comments.


> 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 ??

If you refer to Fig. 11 (Call from H.323 to SIP with conversion between OLC and SDP) of 
"draft-singh-sip-h323-00.txt",  the ACK is sent only towards the completion of  H.245 .
We have just put it after the last OLC and OLC Ack. Does it makes too much time
difference ?
 We are still looking towards your view of sending re-INVITE and will come up with this scenario
also for the 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.

I feel it will be a special case of this scenario. We haven't
looked for such case and will definitely look for such possibility.


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

We have reffered to the conditions that needs to be fulfilled for blind
transfer from "draft-ietf-mmusic-sip-cc-01.txt". I don't feel
that  all of the requirements are fulfilled in call transfer shown
in this section. 

Please comment .

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

Agreed, there was a mistake from our side while drawing the figures.

> 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.

There can be two cases for the billing. These are the services offered
by the service provider and more often seen in mobile networks . So ,I
am considering this also on similar basis.

In those cases, the  user use to get a display/and or announcement  that the
call is being forwarded to a particular destination. Now, at that point, the 
caller can reject the 
call to the forwarded party. If he accepts it, then it means that he agrees to have
the forwarded call. In this case, the bill will be paid by the caller.
In other case, the service provider can give the provision to the called party to
either accept or reject the forwarded call based on the caller identity. In this
case, he may have an agreement with the service provider that he will pay the
extra amount for the forwarded call. 

Because of these reasons only, we had put a ??? in call diagrams because I was
looking for the appropriate and the best suitable way to tell the caller that the call
is being forwarded to other destination.
There can be a other way to the call scenario that we have shown in 5.1 .
The Setup with divertingLegInfo4.inv  will be sent only after sending the message to
the caller that the call is being forwarded and subject to condition that the caller
 agrees to accept the forwarded call .



> 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).

    Agreed

> 
> 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
> > 
> > 
> > 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000309/37e68771/attachment-0004.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SIP-H.323 Call Examples.txt
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000309/37e68771/attachment-0008.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SIP-H.323 Call Examples 01.txt
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000309/37e68771/attachment-0009.txt>


More information about the sg16-avd mailing list