SIP-H.323 Interworking Call Scenarios

Roy, Radhika R, ALARC rrroy at att.com
Fri Mar 10 08:33:12 EST 2000


Hi, Hemant and Vipin:

I think that we can include 4 items as you have mentioned. I like to know
the opinion of others as well. If it is so, we can start drafting the TOR
immediately.

Best regards,
Radhika R. Roy
AT&T

> -----Original Message-----
> From:	VIPIN PALAWAT [SMTP:vipin.palawat at wipro.com]
> Sent:	Thursday, March 09, 2000 1:10 AM
> To:	Roy, Radhika R, ALARC; Kundan Singh; Hemant Agrawal
> Cc:	schulzrinne at cs.columbia.edu; jdrosen at dynamicsoft.com; korpim at sbs.de;
> karl.klaghofer at vs.siemens.de; 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; 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
> 
> Hello Radhika,
> 
> We too feel that it is better to come up with a proposal as early as
> possible without adding much complexity to it.
> I fully agree with you and Kundan singh on this point.
> 
> Somethings more that I would like to be added to either initial or
> expanded
> scope (preffered) of the  TOR are:
> 1) H.245 tunnelling in H.323
> 2) Pre Granted ARQ in H.323
> 3) Overlapped Sending in H.323
> 4) Single line extension in SIP
> 
> Are you in  favour of giving a detailed call scenario examples covering
> all
> the possible call scenarios as per initial
> scope of the TOR . This will be something similar to the latest draft
> "draft-ietf-sip-call-flows-00.txt" .
> 
> I am lokking for your comments.
> 
> Best Regards
> Hemant Agarwal
> Vipin Palawat
> 
> 
> 
> ----- Original Message -----
> From: Roy, Radhika R, ALARC <rrroy at att.com>
> To: Kundan Singh <kns10 at cs.columbia.edu>; Hemant Agrawal
> <hemantag at graffiti.net>
> Cc: <schulzrinne at cs.columbia.edu>; <jdrosen at dynamicsoft.com>;
> <korpim at sbs.de>; <karl.klaghofer at vs.siemens.de>; <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
> <vipin.palawat at wipro.com>; <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
> <adilber at att.com>; <stephen.terrill at ericsson.com>
> Sent: Thursday, March 09, 2000 1:00 AM
> Subject: RE: SIP-H.323 Interworking Call Scenarios
> 
> 
> > 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