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