<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Hello Kundan,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Thanks for the detailed comments.</FONT></DIV>
<DIV><FONT face=Arial size=2>We have put our views and opinions in the <FONT
color=#0000ff>"blue" </FONT><FONT color=#000000>font.</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2>Kindly give us the comments for our
views.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>> Hi Hemant and Vipin,<BR>> <BR>> Its a
very good collection of call flows' translation.<BR>> <BR>> Few
comments:<BR>> <BR>> 1) Might want to include H.323---SIP---H.323 case
where the<BR>> call goes through two SGWs. Since, combining
the<BR>> two call flows (H.323-SIP, sec:1.1) and (SIP-H.323,
sec:2.1)<BR>> may not work. The SIP ACK in sec:1.1 has a different
session<BR>> description, which will trigger some "Mode
Request"<BR>> and/or "Open/Close LogicalChannel" procedures in<BR>>
sec:2.1.<BR>> </FONT></DIV>
<DIV><FONT face=Arial size=2> <FONT color=#0000ff>Fine,
I will prepare this case and send it for comments.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face=Arial size=2>> 2) In sec:1.1,1.2,1.3; it might be better
to send ACK<BR>> immediately after receiving 200 OK, and
send<BR>> re-INVITE once H.245 procedures are complete.<BR>>
This way, we can avoid the retransmissions of 200 OK<BR>>
by SIP EP if H.245 procedures take more time to complete.<BR>>
Comments ??</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2>If you refer to Fig. 11 (Call from
H.323 to SIP with conversion between OLC and SDP) of </FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>"draft-singh-sip-h323-00.txt",
the ACK is sent only towards the completion of H.245 .</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>We have just put it after the last
OLC and OLC Ack. Does it makes too much time</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>difference ?</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2> We </FONT><FONT color=#0000ff
face=Arial size=2>are still looking towards your view of sending re-INVITE
and will come up with this scenario</FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>also for the
comments.</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff><BR><BR></FONT>> 3) In
Fast Connect procedures (sec 3.1), I assume that<BR>> if the
normal H.245 procedure resumes after initial<BR>> call setup
(with faststart), and there is a change in<BR>> H.323 side
session description, then appropriate<BR>> re-INVITE message is
sent to SIP EP.<BR></DIV></FONT>
<DIV><FONT color=#0000ff face=Arial size=2>I feel it will be a special case
of this scenario. We haven't</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>looked for such case and will
definitely look for such possibility.</FONT></DIV>
<DIV> </DIV>
<DIV><BR><FONT face=Arial size=2>> 4) Sec:4 Call transfer may be renamed to
(Blind) Call Tranfer.<BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>We have reffered to the
conditions that needs to be fulfilled for blind</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>transfer from
"draft-ietf-mmusic-sip-cc-01.txt". I don't feel</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>that all of the requirements
are fulfilled in call transfer shown</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>in this section. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Please comment .</FONT></DIV>
<DIV><FONT face=Arial size=2><BR>> 5) Sec:4.1. RTP should be between SIP
EP(B) and SIP EP(C)<BR></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>Agreed, there was a mistake
from our side while drawing the figures.</FONT></DIV></FONT>
<DIV><FONT face=Arial size=2><BR>> 6) Sec: 5.1, you may send "181 Call is
being forwarded"<BR>> response to SIP (A).<BR>>
Can SIP (A) reject the call forwarding here ???<BR>>
Who pays for the call if the forwarded call<BR>>
costs more (longdistance/international) ? Any<BR>>
pointer to this topic is appreciated.<BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>There can be two cases for the
billing. These are the services offered</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>by the service provider and more
often seen in mobile networks . So ,I</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>am considering this also on similar
basis.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2>In those cases, the user use to
get a display/and or announcement that the</FONT></DIV>
<DIV><FONT color=#0000ff><FONT face=Arial size=2>call is being </FONT><FONT
face=Arial size=2>forwarded to a particular destination. Now, at that point, the
</FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>caller can reject the </FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>call to the forwarded party. If he
accepts it, then it means that he agrees to have</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>the forwarded call. In this case, the
bill will be paid by the caller.</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>In other case, the service provider
can give the provision to the called party to</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>either accept or reject the forwarded
call based on the caller identity. In this</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>case, he may have an agreement with
the service provider that he will pay the</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>extra amount for the forwarded call.
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Because of these reasons
only, we had put a ??? in call diagrams because I was</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>looking for the appropriate and the
best suitable way to tell the caller that the call</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>is being forwarded to other
destination.</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>There can be a other way to the call
scenario that we have shown in 5.1 .</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>The Setup with
divertingLegInfo4.inv will be sent only after sending the message
to</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>the caller that the call is being
forwarded and subject to condition that the caller</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2> agrees to accept the forwarded
</FONT><FONT color=#0000ff face=Arial size=2>call .</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><BR>> 7) The call forwarding may be initiated by
the<BR>> proxy (after receipt of 486 Busy Here) or by<BR>>
the SIP endsystem itself (by responding with 302 Moved
Temporarily)<BR>> if it is configured to do so. However, that
will not<BR>> affect the translation much.<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>> 8) Sec:5.3, typo; SIP User (A) should be (B)
and (B) should be (C).<BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>
Agreed</FONT></DIV>
<DIV><FONT face=Arial size=2><BR>> <BR>> Considering the wide variety of
scenarios between<BR>> H.323 and SIP, would it be reasonable to start
with<BR>> a simple call translation specification,<BR>> provide a state
machine/pseudo code for<BR>> message handling by the SGW (signaling
gateway)<BR>> and then extend the state machine/pseudo code<BR>> to handle
all the non-trivial call scenarios.<BR>> <BR>> Once the basic translation
specification is ready,<BR>> profiles for extensions (e.g., blind
transfer<BR>> using GK, call forwarding using proxy,<BR>> translating
forking proxy behaviour to H.323, etc.)<BR>> may be specified.<BR>>
<BR>> Thus, the initial specification may cover following<BR>>
areas:<BR>> - Simple SIP--SGW--H.323 translation, with SGW <BR>>
independent of any GK or proxy.<BR>> - Translating (blind) call transfer by
endsystems.<BR>> - Translating call forwarding by endsystems.<BR>> - How
to handle, SIP re-INVITEs (change<BR>> in session description/or media
transport address) <BR>> and change in <BR>> H.323 logical
channel/mode request.<BR>> - How to handle H.323 fast start.<BR>> <BR>>
Later on other things may be added:<BR>> - Call hold translation<BR>> -
Call transfer/forwarding by GK and/or proxy.<BR>> - SIP--H.323--SIP and
H.323---SIP---H.323 scenarios.<BR>> - SGW coexiting with GK or proxy.<BR>>
...<BR>> <BR>> Motivation for such a separation is to allow<BR>>
the implementors more freedom in deciding what<BR>> configuration to choose,
while still maintaining<BR>> the basic translation framework.<BR>> For
example, call forwarding to voicemail may<BR>> be handled by <BR>> - the
endsystem by sending 302 moved, after say 4 rings.<BR>> - the proxy server on
receipt of 486 busy here<BR>> - the proxy server, forking one branch of the
request to the voicemail<BR>> system which accepts the call after, say, 15
seconds.<BR>> <BR>> It turns out that once we have the initial
specification,<BR>> (as mentioned in above list) the advanced
scenarios<BR>> are just a "special cases"/"combination of cases" of
the<BR>> initial scenarios.<BR>> <BR>> Regards<BR>> <BR>>
Kundan<BR>> --<BR>> Kundan Singh <A
href="http://www.cs.columbia.edu/~kns10">http://www.cs.columbia.edu/~kns10</A><BR>>
<BR>> On Wed, 8 Mar 2000, Hemant Agrawal wrote:<BR>> <BR>> > Hi
All,<BR>> > There was a continuous discussion on the different
configuration for the<BR>> > SIP - H.323 interworking.<BR>> >
<BR>> > In our opinion, it would be better if some basic features (like
Call<BR>> > Transfer, Call Hold and Call forwarding) is also added as part
of the<BR>> > discussion.<BR>> > <BR>> > We are enclosing some
call flow examples of SIP-H.323 interworking. Please<BR>> > give your
comments on these call flows. Our stress is on the call features<BR>> >
and others are just informational. We have specified few issues also
inorder<BR>> > to make these protocols interwork.<BR>> > <BR>>
> Kindly let us know if you agree to include the feature discussion also
as<BR>> > part of the SIP - H.323 interworking. We are ready to put our
efforts for<BR>> > the feature interworking.<BR>> > <BR>> >
Best Regards<BR>> > <BR>> > Hemant Agarwal<BR>> > Vipin
Palawat<BR>> > <BR>> > <BR>> > <BR>> <BR>>
</FONT></DIV></BODY></HTML>