- sg16-avd - lists.packetizer.com

Re: H.323 Mobility Contribution
by Roy, Radhika R, ALARC 09 Mar '00

09 Mar '00

Hi, Jaakko: It is in the ITU-T SG16 WP2 Delayed server site. If you have problems, please let me know. I will send a copy of D.354 to you. Best regards, Radhika PS: March 16 seems to be a good date for submitting contributions. > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, March 09, 2000 8:32 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility Contribution > > Hi Radhika and Paul G., > > Radhika, could you inform me (us) the URL, where your contribution (D.354) > can be found. I did not seem to be able to find it. > > Paul G., the next teleconference is on 23rd March, so is the deadline for > the MDs a week earlier (that is, 16th March)? I seem to remember a mention > about an earlier date (10th), but my memory isn't so clear on this. Also I > would like to have an MD-number allocated for my contribution, so could > you > send me the number. > > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > ------------------------------------------------------- > > -----Original Message----- > From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Wednesday, March 08, 2000 7:57 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.323 Mobility Contribution > > Hi, Paul and Jaakko: > > With respect to our upcoming H.323 mobility conference > call, > I like to point > out that I plan to discuss "Mobility Management" > scenarios. > The contribution > related to this scenario can be found in "Section 6 - > Mobility Management > (Pages 32-41)" of AT&T Contribution - "D.354 (WP/2/16): > H.323 Mobility > Architecture and Protocol for Terminal, User, and Service > Mobility" provided > in the last SG16 Feb'00 meeting held in Geneva. > > I would appreciate, if you would upload the document in > the > server. This > contribution is available in the ITU-T SG16 Web site as > well. > > (If time permits, I may re-write this as a stand-alone > paper > before the > conference call. I am not sure whether I would be able to > do > this.) > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 Tel > rrroy(a)att.com

1 0

Re: H.323 Mobility Contribution
by Jaakko Sundquist 09 Mar '00

09 Mar '00

Hi Radhika and Paul G., Radhika, could you inform me (us) the URL, where your contribution (D.354) can be found. I did not seem to be able to find it. Paul G., the next teleconference is on 23rd March, so is the deadline for the MDs a week earlier (that is, 16th March)? I seem to remember a mention about an earlier date (10th), but my memory isn't so clear on this. Also I would like to have an MD-number allocated for my contribution, so could you send me the number. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. ------------------------------------------------------- -----Original Message----- From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Wednesday, March 08, 2000 7:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 Mobility Contribution Hi, Paul and Jaakko: With respect to our upcoming H.323 mobility conference call, I like to point out that I plan to discuss "Mobility Management" scenarios. The contribution related to this scenario can be found in "Section 6 - Mobility Management (Pages 32-41)" of AT&T Contribution - "D.354 (WP/2/16): H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility" provided in the last SG16 Feb'00 meeting held in Geneva. I would appreciate, if you would upload the document in the server. This contribution is available in the ITU-T SG16 Web site as well. (If time permits, I may re-write this as a stand-alone paper before the conference call. I am not sure whether I would be able to do this.) Best regards, Radhika R. Roy AT&T +1 732 420 1580 Tel rrroy(a)att.com

1 0

Re: SIP-H.323 Interworking Call Scenarios
by VIPIN PALAWAT 09 Mar '00

09 Mar '00

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

1 0

Re: SIP-H.323 Interworking Call Scenarios
by VIPIN PALAWAT 09 Mar '00

09 Mar '00

Hello Kundan, Thanks for your detailed comments. We will come back to you with our opinions by today evening. Best Regards Hemant Agrawal Vipin Palawat ----- Original Message ----- From: Kundan Singh <kns10(a)cs.columbia.edu> To: Hemant Agrawal <hemantag(a)graffiti.net> Cc: <schulzrinne(a)cs.columbia.edu>; <jdrosen(a)dynamicsoft.com>; <korpim(a)sbs.de>; <karl.klaghofer(a)vs.siemens.de>; <rrroy(a)ATT.COM>; <alan.johnston(a)wcom.com>; <steven.r.donovan(a)wcom.com>; <Kevin.Summers(a)wcom.com>; <dean.willis(a)wcom.com>; <henry.sinnreich(a)wcom.com>; VIPIN PALAWAT <vipin.palawat(a)wipro.com>; <agboh(a)helios.iihe.ac.be>; <Robert.Sparks(a)wcom.com>; <Chris.Cunningham(a)wcom.com>; <orit(a)radvision.com>; <taylor(a)NORTELNETWORKS.COM>; <joon_maeng(a)vtel.com>; <drwalker(a)ss8networks.com>; <paul.jones(a)TIES.ITU.INT>; <adilber(a)ATT.COM>; <stephen.terrill(a)ericsson.com> Sent: Wednesday, March 08, 2000 11:34 PM 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 > > > > > > > >

1 0

RE: SIP-H.323 Interworking Call Scenarios
by Roy, Radhika R, ALARC 09 Mar '00

09 Mar '00

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@cs.columbia.edu] > Sent: Wednesday, March 08, 2000 1:04 PM > To: Hemant Agrawal > Cc: schulzrinne(a)cs.columbia.edu; jdrosen(a)dynamicsoft.com; korpim(a)sbs.de; > karl.klaghofer(a)vs.siemens.de; Roy, Radhika R, ALARC; > alan.johnston(a)wcom.com; steven.r.donovan(a)wcom.com; Kevin.Summers(a)wcom.com; > dean.willis(a)wcom.com; henry.sinnreich(a)wcom.com; VIPIN PALAWAT; > agboh(a)helios.iihe.ac.be; Robert.Sparks(a)wcom.com; > Chris.Cunningham(a)wcom.com; orit(a)radvision.com; taylor(a)NORTELNETWORKS.COM; > joon_maeng(a)vtel.com; drwalker(a)ss8networks.com; paul.jones(a)TIES.ITU.INT; > Dilber, Ayse, ALARC; stephen.terrill(a)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 > > > > > >

2 1

Re: proposal for SIP as single call control protocol in 3GPP
by Barry Aronson 09 Mar '00

09 Mar '00

Bob, Do you perhaps mean RFC 2543? Barry At 05:23 3/6/00 -0800, Callaghan, Robert wrote: >It should be noted that an important phase is contained in this document. >It states that SIP is "position SIP as an ideal protocol to modify and >enhance to meet the R2000 requirements." This can be translated into "We >want our own protocol based in SIP." > >It will be interest to see if the results are fully compatible with RFC 2546 >(SIP). > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Information and Communication Networks >Tel: +1.561.997.3756 Fax: +1.561.997.3403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ > > >-----Original Message----- >From: Michaely, Boaz [mailto:Boaz_Michaely@ICOMVERSE.COM] >Sent: Monday, March 06, 2000 2:54 AM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: proposal for SIP as single call control protocol in 3GPP > > >All, >This proposal comes from: >AT&T, BT, Japan Telecom, Lucent, Nokia, Nortel, Rogers Wireless, T-Mobil, >Telenor, Telia. >For those who are unaware, Release 2000 is conceived as THE most important >activity regarding the future of VoIP in the sense that in a few short years >wireless will become the dominant way of communication (more than wireline). >3GPP now discusses "Release 2000" which is the architecture for that future >mobile network, where everything is over IP, including the media. > >This material is for discussion in Tokyo, March 6-9. > >Thought you should know, > Boaz > >Boaz Michaely >Senior System Architect, Corporate >Comverse Network Systems >Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 >http://people.itu.int/~michaely >mailto:boaz_michaely@comverse.com > > > > > -----Original Message----- > > From: Lobley,NC,Nigel,NZCA R [mailto:nigel.lobley@BT.COM] > > Sent: Friday, March 03, 2000 1:40 PM > > To: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > > Subject: Inputs from BT and a number of companies > > > > > > Dear all > > > > Please find attached a couple of papers for S2 next week. > > > > See you in Japan > > > > Nigel > > Barry Aronson E-mail: baronson(a)ieee.org Toshiba Corp. Voice: +1 978-232-3994 33 Lake Shore Ave. Fax: +1 978-232-9220 Beverly, MA 01915-1907 Video: H.320, H.323, and H.324 by prior arrangement

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Dear Colleagues, It is not a bad idea that people should discuss this item as a small group depending on their interest. However, if people have a general interest to discuss it in the SG16 reflector, it is their choice. No one individual or a company should restrict it. Let us understand the norm of using the SG16 reflector first. Best regards, Radhika R. Roy > -----Original Message----- > From: Sebestyen Istvan ICN M CS 27 [SMTP:Istvan.Sebestyen@ICN.SIEMENS.DE] > Sent: Wednesday, March 08, 2000 12:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FYI - SIP-H.323 Interworking BOF > Importance: High > > Dear Colleagues, > > I don't want to hurt anybody,... > > but I understand that Martin Euchner is getting a bit inpatient, me too. > It > is really necessary that for an issue that has received in the last ITU-T > SG16 meeting let me say a relatively modest support, now everybody on the > SG16 Reflector has to "listen" the detailed discussion what should be > done, > why, where, when... etc. Would it not be possible that those individuals, > who have an apparent interest in the SIP/H.323 interoperability topic > discuss this first among themselves and the contributions get introduced > only at the next SG16 meeting in May or at least when the contributions > are > finished? > > I hope on your understanding. > > Many regards, > Istvan Sebestyen > -------------------------------------------------------------------------- > Dr. Istvan Sebestyen > Siemens AG, ICN M CS27, > Hofmannstr. 51 D-81359 Munich > Tel:+49-89-722-47230 > Fax:+49-89-722-47713 > E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de > E-mail private: istvan_sebestyen(a)yahoo.com; > Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 > Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de > -------------------------------------------------------------------------- > -- > ---------------- > > > ---------- > > From: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > > Reply To: Mailing list for parties associated with ITU-T Study Group > > 16 > > Sent: Wednesday, March 08, 2000 5:27 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Hi, Everyone: > > > > ITU-T and IETF are the formal standard bodies to create standards for > > H.323 > > and SIP, respectively, and the interworking standard between the two is > > also > > a part of it.. > > > > However, all inputs from other organizations will definitely be > welcomed. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > > -----Original Message----- > > > From: Euchner Martin [SMTP:Martin.Euchner@MCHP.SIEMENS.DE] > > > Sent: Wednesday, March 08, 2000 4:16 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > just for your information for those interested in H.323/SIP: > > > > > > I would like to draw your attention to an activity group already > > debating > > > H.323-SIP interworking for quite a while: IMTC aHIT!. To my knowledge > > they > > > already came out with some first results on architectures and > > interworking > > > scenarios. Please get in touch with this group and consider their > > results. > > > see also http://www.imtc.org/act_ahit.htm > > > <http://www.imtc.org/act_ahit.htm> > > > and discussions on their mailing list. > > > > > > Thus, it appears to me that there are already quite a few groups > (IETF, > > > IMTC, ETSI) discussing H323/SIP interworking. I do not quite see > > necessity > > > to have ITU-T SG16 as yet another group for this topic. > > > > > > regards > > > > > > Martin. > > > > > > > ----------------------------------------------------------------------- > > > | Dipl.-Inf. Phone: +49 89 636-46201 > > > | Martin Euchner Fax : +49 89 636-48000 > > > | Siemens AG > > > | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > > > | mailto:martin.euchner@ties.itu.int > > > | Otto-Hahn-Ring 6 Intranet: > > > > > > http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG1 > > > 6/ > > > index.html > > > | D-81730 Muenchen Internet: http://www.siemens.de > > > | __________________ > > > | Germany > > > > ----------------------------------------------------------------------- > > > > > > > > > -----Original Message----- > > > From: Joon Maeng [SMTP:joon_maeng@VTEL.COM] > > > Sent: Saturday, March 04, 2000 6:56 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > Roy, you your are right. It is focused on the SIP and H.323 > > > interworking. > > > I attached the tentative agenda for the BOF. Depending on the > > > speakers we > > > identify, the agenda may inlcude some presenters but the main > > > focus > > > will not > > > be modified. > > > Regards, > > > Joon > > > > > > > ------------------------------------------------------------------------ > > > BOF: SIP and H.323 Interworking (sip323) > > > Area: Transport > > > Time requested: one 1 hour slot > > > Chairs: Joon Maeng <joon_maeng(a)vtel.com> > > > Dave Walker <drwalker(a)ss8networks.com> > > > > > > Description: > > > > > > There are two competing standards in the industry for > > establishing > > > and > > > managing real-time interactive media communications over IP. > > One > > > is > > > the > > > proposed IETF standard, Session Initiation Protocol (RFC > 2543), > > > and > > > the > > > other is the ITU recommendation, H.323. Although they use the > > > same > > > protocol (RTP) for media streaming, they cannot establish > calls > > > between > > > them. In the absence of any formal interoperability > standards, > > > many > > > vendors are beginning to develop proprietary application > > gateways > > > for > > > interworking between SIP and H.323. > > > > > > In order to provide interoperability between the two > standards, > > it > > > is > > > urgent to define a common interworking specifications for the > > > industry. > > > The recognition of the need for this interworking > specification > > > has > > > lead > > > to calls for its development from both manufacturers and > service > > > providers, individually and through industry consortia (such > as > > > IMTC) > > > and other bodies concerned with interoperability (such as > ETSI). > > > > > > In this BOF, we are going to discuss SIP and H.323 > interworking > > > issues, > > > execution plans and the scope of the work. > > > > > > Agenda: > > > > > > - Do we need SIP-H.323 interworking? > > > - Coordination with other groups? > > > - Scope of interworking > > > - Outcome of the work? > > > - Suggestions? > > > > > > Helpful reading: > > > - draft-singh-sip-h323-00.txt > > > - SIP: Session Initiation Protocol (RFC 2543) > > > - SDP: Session Description Protocol (RFC 2327) > > > - ITU recommendations: H.323, H.225.0, H.245 > > > > > > > -----Original Message----- > > > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > > > Sent: Friday, March 03, 2000 3:12 PM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > > > Hi, Everyone: > > > > > > > > It appears that BOF is focused only on SIP-H.323 > Interworking > > > (not > > > > H.323-Internet Interworking as titled by Orit). I guess > that > > > > Joon and Dave > > > > will clarify this better. > > > > > > > > Best regards, > > > > Radhika R. Roy > > > > AT&T > > > > > > > > > -----Original Message----- > > > > > From: Orit Levin [SMTP:orit@radvision.com] > > > > > Sent: Friday, March 03, 2000 3:57 PM > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > Great! > > > > > I am attaching the revised so far TOR. Please, send your > > > comments. > > > > > Hope you will find it useful in Australia. > > > > > Best regards, > > > > > Orit Levin > > > > > RADVision Inc. > > > > > 575 Corporate Drive Suite 420 > > > > > Mahwah, NJ 07430 > > > > > Tel: 1 201 529 4300 (230) > > > > > Fax: 1 201 529 3516 > > > > > www.radvision.com > > > > > orit(a)radvision.com > > > > > -----Original Message----- > > > > > From: Joon Maeng <joon_maeng(a)VTEL.COM> > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > <ITU-SG16(a)MAILBAG.INTEL.COM> > > > > > Date: Thursday, March 02, 2000 8:18 PM > > > > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > > > > the IETF meeting > > > > > in > > > > > >Australia. Dave Walker with SS8 Networks and I will > chair > > > > the BOF. You > > > > > can > > > > > >find the agenda at > > > http://www.ietf.org/meetings/IETF-47.html when IETF > > > > posts > > > > >agendas. > > > > >Regards, > > > > >Joon << File: H323-Internet.zip >> > >

1 0

H.323 Mobility Contribution
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Hi, Paul and Jaakko: With respect to our upcoming H.323 mobility conference call, I like to point out that I plan to discuss "Mobility Management" scenarios. The contribution related to this scenario can be found in "Section 6 - Mobility Management (Pages 32-41)" of AT&T Contribution - "D.354 (WP/2/16): H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility" provided in the last SG16 Feb'00 meeting held in Geneva. I would appreciate, if you would upload the document in the server. This contribution is available in the ITU-T SG16 Web site as well. (If time permits, I may re-write this as a stand-alone paper before the conference call. I am not sure whether I would be able to do this.) Best regards, Radhika R. Roy AT&T +1 732 420 1580 Tel rrroy(a)att.com

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Sebestyen Istvan ICN M CS 27 08 Mar '00

08 Mar '00

Dear Colleagues, I don't want to hurt anybody,... but I understand that Martin Euchner is getting a bit inpatient, me too. It is really necessary that for an issue that has received in the last ITU-T SG16 meeting let me say a relatively modest support, now everybody on the SG16 Reflector has to "listen" the detailed discussion what should be done, why, where, when... etc. Would it not be possible that those individuals, who have an apparent interest in the SIP/H.323 interoperability topic discuss this first among themselves and the contributions get introduced only at the next SG16 meeting in May or at least when the contributions are finished? I hope on your understanding. Many regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Roy, Radhika R, ALARC[SMTP:rrroy@ATT.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, March 08, 2000 5:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: FYI - SIP-H.323 Interworking BOF > > Hi, Everyone: > > ITU-T and IETF are the formal standard bodies to create standards for > H.323 > and SIP, respectively, and the interworking standard between the two is > also > a part of it.. > > However, all inputs from other organizations will definitely be welcomed. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Euchner Martin [SMTP:Martin.Euchner@MCHP.SIEMENS.DE] > > Sent: Wednesday, March 08, 2000 4:16 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > just for your information for those interested in H.323/SIP: > > > > I would like to draw your attention to an activity group already > debating > > H.323-SIP interworking for quite a while: IMTC aHIT!. To my knowledge > they > > already came out with some first results on architectures and > interworking > > scenarios. Please get in touch with this group and consider their > results. > > see also http://www.imtc.org/act_ahit.htm > > <http://www.imtc.org/act_ahit.htm> > > and discussions on their mailing list. > > > > Thus, it appears to me that there are already quite a few groups (IETF, > > IMTC, ETSI) discussing H323/SIP interworking. I do not quite see > necessity > > to have ITU-T SG16 as yet another group for this topic. > > > > regards > > > > Martin. > > > > ----------------------------------------------------------------------- > > | Dipl.-Inf. Phone: +49 89 636-46201 > > | Martin Euchner Fax : +49 89 636-48000 > > | Siemens AG > > | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > > | mailto:martin.euchner@ties.itu.int > > | Otto-Hahn-Ring 6 Intranet: > > > http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG1 > > 6/ > > index.html > > | D-81730 Muenchen Internet: http://www.siemens.de > > | __________________ > > | Germany > > ----------------------------------------------------------------------- > > > > > > -----Original Message----- > > From: Joon Maeng [SMTP:joon_maeng@VTEL.COM] > > Sent: Saturday, March 04, 2000 6:56 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Roy, you your are right. It is focused on the SIP and H.323 > > interworking. > > I attached the tentative agenda for the BOF. Depending on the > > speakers we > > identify, the agenda may inlcude some presenters but the main > > focus > > will not > > be modified. > > Regards, > > Joon > > > > ------------------------------------------------------------------------ > > BOF: SIP and H.323 Interworking (sip323) > > Area: Transport > > Time requested: one 1 hour slot > > Chairs: Joon Maeng <joon_maeng(a)vtel.com> > > Dave Walker <drwalker(a)ss8networks.com> > > > > Description: > > > > There are two competing standards in the industry for > establishing > > and > > managing real-time interactive media communications over IP. > One > > is > > the > > proposed IETF standard, Session Initiation Protocol (RFC 2543), > > and > > the > > other is the ITU recommendation, H.323. Although they use the > > same > > protocol (RTP) for media streaming, they cannot establish calls > > between > > them. In the absence of any formal interoperability standards, > > many > > vendors are beginning to develop proprietary application > gateways > > for > > interworking between SIP and H.323. > > > > In order to provide interoperability between the two standards, > it > > is > > urgent to define a common interworking specifications for the > > industry. > > The recognition of the need for this interworking specification > > has > > lead > > to calls for its development from both manufacturers and service > > providers, individually and through industry consortia (such as > > IMTC) > > and other bodies concerned with interoperability (such as ETSI). > > > > In this BOF, we are going to discuss SIP and H.323 interworking > > issues, > > execution plans and the scope of the work. > > > > Agenda: > > > > - Do we need SIP-H.323 interworking? > > - Coordination with other groups? > > - Scope of interworking > > - Outcome of the work? > > - Suggestions? > > > > Helpful reading: > > - draft-singh-sip-h323-00.txt > > - SIP: Session Initiation Protocol (RFC 2543) > > - SDP: Session Description Protocol (RFC 2327) > > - ITU recommendations: H.323, H.225.0, H.245 > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > > > Sent: Friday, March 03, 2000 3:12 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > > Hi, Everyone: > > > > > > It appears that BOF is focused only on SIP-H.323 Interworking > > (not > > > H.323-Internet Interworking as titled by Orit). I guess that > > > Joon and Dave > > > will clarify this better. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > > > > > -----Original Message----- > > > > From: Orit Levin [SMTP:orit@radvision.com] > > > > Sent: Friday, March 03, 2000 3:57 PM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > > > > > Great! > > > > I am attaching the revised so far TOR. Please, send your > > comments. > > > > Hope you will find it useful in Australia. > > > > Best regards, > > > > Orit Levin > > > > RADVision Inc. > > > > 575 Corporate Drive Suite 420 > > > > Mahwah, NJ 07430 > > > > Tel: 1 201 529 4300 (230) > > > > Fax: 1 201 529 3516 > > > > www.radvision.com > > > > orit(a)radvision.com > > > > -----Original Message----- > > > > From: Joon Maeng <joon_maeng(a)VTEL.COM> > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > > > Date: Thursday, March 02, 2000 8:18 PM > > > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > > > the IETF meeting > > > > in > > > > >Australia. Dave Walker with SS8 Networks and I will chair > > > the BOF. You > > > > can > > > > >find the agenda at > > http://www.ietf.org/meetings/IETF-47.html when IETF > > > posts > > > >agendas. > > > >Regards, > > > >Joon << File: H323-Internet.zip >> >

1 0

Re: [sip-h323] Re: H323/SIP Interworking - way forward
by Roy, Radhika R, ALARC 08 Mar '00

08 Mar '00

Hi, David and Orit: David has a raised an interesting point. I guess that we can start with an interworking GW approach first: SIP Network and H.323 Network. Replacing GK and SIP server with a super server is an interesting idea. One way of looking into it may be that the supper server contains the properties of the SIP-H.323 interworking GW. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Wang, Dave [SMTP:dwang@NUERA.COM] > Sent: Tuesday, March 07, 2000 6:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [sip-h323] Re: H323/SIP Interworking - way forward > > Hi Orit, > > To support and extend existing install base, let say an existing H.323 > network, with working GW and GK, how would we add this super-Server ? > Would > we need to remove existing GK first ? > > In cases that we want to connect a working H.323 network with a working > SIP > network operated by two separate administrations, not sure how to replace > both GK and SIP Server with a single super-Server ? > > David > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Tuesday, March 07, 2000 12:25 PM > > To: sip-h323(a)egroups.com; ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > > Hello folks! > > Scoping our work in terms of scenarios... > > There are a lot of possible topologies that we would like to > > address. It > > will be difficult to prioritize among them because it depends on each > > company niche. I think that an exercise, done by the authors of > > "Interworking Between SIP/SDP and H.323" Internet Draft, is a > > great example > > for this statement. In all cases it would involve Gatekeeper/Proxy and > > Gateway of some kind, as either logical or physical entities. > > > > In my opinion, the first requirement for our work should be > > defined as: "the > > end devices should be interoperable regardless of signaling > > protocol they > > support". The fastest way to address this requirement is to cover the > > topology where the end users are connected to a super-Server > > supporting > > both H.323 and SIP and solving the IWF as an internal logic (including > > address translation). The outcome of this work should be the > > recognition of > > protocols' details or/and features preventing from transparent (to the > > users) interworking. Then we can either profile further or, > > alternatively, > > feed the new requirements into the protocols. > > > > It is, by no means, prevents us from discussion about more complicated > > topologies. Nevertheless, without solving the simplest case, > > it is hard to > > get focused. > > My two cents, > > Orit Levin > > RADVision Inc. > > 575 Corporate Drive Suite 420 > > Mahwah, NJ 07430 > > Tel: 1 201 529 4300 (230) > > Fax: 1 201 529 3516 > > www.radvision.com > > orit(a)radvision.com > > -----Original Message----- > > From: Kundan Singh <kns10(a)cs.columbia.edu> > > To: 'sip-h323(a)egroups.com' <sip-h323(a)egroups.com> > > Date: Tuesday, March 07, 2000 10:51 AM > > Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > > > > > > > > >> Hi Paul, > > >> > > >> Thanks for the understanding. I like your ideas very much > > and would love > > to > > >> limit my implementation to just this five. How about we > > all bounce this > > with > > >> other contacts of ours and see how long this can hold up. > > >> > > >> My one remainimg question, in regards to the trivial cases > > that we ruled > > out > > >> early on that doesn't involve any IWF : how does we know > > a-prior that we > > >> don't need, or need, the IWF ? Therefore, from a end-to-end service > > >> prespective, i.e. above the protocol conversion, we would > > still need to > > have > > >> a way to identify when IWF is needed. > > > > > >This functionality may be provided by the registration servers > > >(e.g., SIP registrars and H.323 gatekeepers) present in the > > >network. Ideally, one H.323 gatekeeper with SIP/H323 IWF > > >listening at the gatekeepers multicast address can resolve > > >all address requests originated from H.323 network and > > >destined for a SIP entity. So an H.323 entity just need to > > >send LRQ to the gatekeeper's welknown multicast address > > without knowing > > >whether the destination is in SIP or H.323 network. > > >GK/IWF will capture the message find out if the > > >destination is reachable in SIP network (e.g., using SIP > > >OPTIONS message). > > > > > >In the other direction, its simple. Since the GK is equipped with > > >IWF (SIP/H323 translation) it can forward all H.323 registrations to > > >the SIP server. So, the H323 entities can be reached through that > > >particular SIP server. > > > > > >Likewise, SR/IWF may also be used to provide transparent > > >address resolution. > > > > > >However, it would be nice if the IWF is not part of > > >a regitration server and, still, can resolve the address. > > > > > >Regards > > > > > >Kundan > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > ----------- > > >To Post a message, send it to: sip-h323(a)eGroups.com > > >To Unsubscribe, send a blank message to: > > sip-h323-unsubscribe(a)eGroups.com > > > > > >------------------------------------------------------------- > > ----------- > > >DON'T HATE YOUR RATE! > > >Get a NextCard Visa, in 30 seconds! Get rates as low as > > >0.0% Intro or 9.9% Fixed APR and no hidden fees. > > >Apply NOW! > > >http://click.egroups.com/1/2065/2/_/302437/_/952444292/ > > > > > >eGroups.com Home: http://www.egroups.com/group/sip-h323/ > > >http://www.egroups.com - Simplifying group communications > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: > > sip-h323-unsubscribe(a)eGroups.com > > > > -------------------------------------------------------------- > > ---------- > > Planning a party? iParty.com is your complete source for > > party planning and > > supplies, with everything you need to throw the perfect party! > > http://click.egroups.com/1/1635/2/_/302437/_/952460660/ > > > > -- Check out your group's private Chat room > > -- http://www.egroups.com/ChatPage?listName=sip-h323&m=1 > > > >

1 0