- sg16-avd - lists.packetizer.com

Re: Errors / ambiguities / problems found in specs at last week's interop
by Sherlock, Stuart 13 Mar '00

13 Mar '00

How do I unsubscribe? Thanks Stuart -----Original Message----- From: Gene Schroeder [mailto:erschroeder@LUCENT.COM] Sent: Monday, March 13, 2000 8:41 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Errors / ambiguities / problems found in specs at last week'sinterop One common reason the gatekeeper might want to increase the registration TTL is to control the rate of incoming keep-alive RRQs. If a gatekeeper has many endpoints registered, and these endpoints select a very low TTL (say a few seconds), then the gatekeeper will be forced into processing a high rate of keep-alive RRQs. If the gatekeeper does not require nor need such timely information on endpoint status, then IMHO it should be able to specify a higher TTL in the RCF. And it seems the endpoint should honor this request, just as if it would honor a lower TTL. Regards Gene Schroeder elemedia > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Wayman Purvis > Sent: Monday, March 13, 2000 9:02 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Errors / ambiguities / problems found in specs at last > week'sinterop > > > Comments inline: > > "Johan Gerhardsson (ETX)" wrote: > > > > Hi folks, > > > > To clarify things: > > > > It seems that my writing was a bit sloppy when I wrote the > problems about TTL and SEQUENCE OF... on the interop. I intended > to describe two different problems: > > > > 1) GK cannot increase TTL in RCF. > > This is true. > > > 2) Mandatory parameters of type SEQUENCE OF ... can have empty list. > > This is also true. > > > 1) > > h323v2, 7.2.2: > > "The Gatekeeper may respond with an RCF containing the same > timeToLive or a shorter timeToLive.". > > As I see it, according to this, a GK is not allowed to increase > the timeToLive value proposed by the endpoint in RRQ, regardless > if the endpoint makes a full registration or a keep-alive registration. > > > > I think it should be possible for the gk to do it. > > I disagree. As the endpoint is permitted to renew its > registration any time up > to the assigned time to live, allowing the GK to increase time to > live would > have no effect whatsoever (the endpoint would send keepalives at whatever > frequency it always wanted to). There would be no effect, so > there's no reason > to change. > > As for your second point about SEQUENCE OF being permitted to > have an empty > list, this has always been the case. Is there a specific problem > with this? > It looks more like a (true) observation than a problem to me! I > doubt you'll > get ASN.1 changed in existing stuff to make things SEQUENCE > [1..something] OF > rather than SEQUENCE OF (even if such a structure is permitted - any ASN.1 > experts wish to comment?). > > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 >

1 0

Re: FastStart and payload size
by Francois Audet 13 Mar '00

13 Mar '00

Yep, you are right: it has always been the maximum size. The difference is that if you have capability negotiation before (non fast-start), it is understood that you would attempt to indicate a larger maximum size in the OpenLogicalChannel than what was indicated in the terminal capability negotiation. Also, I would guess that "fixed sized" payload (let say in increments of 10 ms) may be less demanding on the hardware or DSP. > Exactly, the caller has to make a series of educated guesses regarding > outgoing caps, based on the implementor's experience and common sense. > > (Wait a minute. Let me get on my high horse... okay, I'm on... :-) > These fields have always indicated _maximum_ framing. For > example, if I > indicate that I can receive packets containing as many as 20 > frames per > packet (for G.711, a frame happens to be 1ms in duration), > that means you > can send me packets containing 1, 20, 10, 2, 15, 8, etc., > frames. Mix and > match. Put a different number of frames in each successive > packet if you > want to. It doesn't matter. The _only_ constraint is that no > packet may > contain more than 20 frames. It has never meant that you can > only send me 20 > frames per packet for each and every packet, which for G.711 > would be 20ms > packets all the time. However, several vendors apparently have > "extra-normative" technical constraints that they must deal > with regarding > packet size, i.e., DSPs that require being fed chunks of > fixed-size audio, > e.g., 20ms packets. But there is no way in H.245 and > therefore H.323 to > indicate a fixed-size packet. These vendors should either > "fix" their DSPs > or perform re-framing between transport and decoder. In our > software-only > implementation, we have a FIFO into which we shove all incoming audio > frames. Once frames are installed in the FIFO, it doesn't > matter where the > packet boundary was. The decoder just processes frames in the > order they > were received. I'm sure that there are really good technical > reasons why > some implementations require fixed-size audio packets. Based > on our perhaps > too simplistic implementation, however, this has always puzzled me. > > Paul Long > Smith Micro Software, Inc. >

3 2

FYI - SIP-H.323 interworking discussion for IETF BOF
by Joon Maeng 13 Mar '00

13 Mar '00

Hi folks. To consolidate all the discussions related to SIP-H.323 interworking, SIP-H.323 interworking (sip323) BOF at IETF will use the list server at http://www.egroups.com/group/sip-h323/info.html. You can visit the site and register to use it. Regards, Joon

1 0

Re: FastStart and payload size
by Francois Audet 10 Mar '00

10 Mar '00

Hum... That kind of worries me. It means that the burden is on the originating side to "guess" what the terminator is likely to support. I also agree that practically speaking, implementations normally support multiples of 10 ms as the payload size (with the notable exeption of Netmeeting). However, technically speaking, if you advertize 30 ms as the maximum payload size you can support, it implies that in order to comply with the H.323 specification, you would support any value between 0 ms (whatever it means) and 30 ms. I don't think many implementations could do this. But that is a separate issue. In any case, if we all understand that the originator is responsible for accurately describing a decent subset of the capabilities it can support, we probably should describe this in the spec because I am convinced that most people will simply put the maximum payload size they can support... > -----Original Message----- > From: Paul Long [mailto:plong@SMITHMICRO.COM] > Sent: Friday, March 10, 2000 11:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FastStart and payload size > > > Francois, > > You are correct that your first solution would cause > backward-compatibility > problems, because the called EP merely _selects_ which OLCs > it wants to use. > From the caller's proposed OLCs, it returns the ones that it > accepts. It > cannot provide its own OLCs or otherwise modify the proposed OLCs. The > Recommendation is quite clear about this. I can quote from > it, if necessary. > :-) > > I'm afraid that the only solution is the second one you > describe, but IMO it > is not necessary to provide every possible value within a > range, e.g., 100, > 99, 98, 97... From my experience at interops, it seems like > G.711 framing is > limited to either 60, 30, 20, or 10ms frames, so that's what > I would propose > in addition to your own 100ms maximum. (Note that for some > EPs, this is not > their maximum framing but the _exact_ framing that you must use!) > > Our EP currently just proposes one type of media per session > ID (due to > another problem with FC). We propose G.723.1 and H.263. This > is what our > fastStart looks like in order to overcome the problem you describe: > > in G.723.1, maxframes 4, SS > out G.723.1, maxframes 4, SS > out G.723.1, maxframes 4, no SS > out G.723.1, maxframes 1, no SS > in H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO > out H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO > out H.263, QCIF 1, vTSTO > out H.263, QCIF 2, no vTSTO > > Note that it's only necessary to provide maximum caps for > incoming media, > because the called EP can always ignore features it does not > support, e.g., > SS and CIF, and undershoot your maximum framing. Once/if we > support multiple > media per session ID, this is probably what it would look like: > > in G.723.1, maxframes 4, SS > out G.723.1, maxframes 4, SS > out G.723.1, maxframes 4, no SS > out G.723.1, maxframes 1, no SS > in G.711, ALaw, maxFrames 200 > out G.711, ALaw, maxFrames 60 > out G.711, ALaw, maxFrames 30 > out G.711, ALaw, maxFrames 20 > out G.711, ALaw, maxFrames 10 > in G.711, muLaw, maxFrames 200 > out G.711, muLaw, maxFrames 60 > out G.711, muLaw, maxFrames 30 > out G.711, muLaw, maxFrames 20 > out G.711, muLaw, maxFrames 10 > in H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO > out H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO > out H.263, QCIF 1, vTSTO > out H.263, QCIF 2, no vTSTO > in H.261, QCIF 1, CIF 1, vTSTO > out H.261, QCIF 1, CIF 1, vTSTO > out H.261, QCIF 1, vTSTO > out H.261, QCIF 2, no vTSTO > > (whew!) > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] > Sent: Friday, March 10, 2000 12:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: FastStart and payload size > > > Another glitch with fast connect... > > The OpenLogicalChannel indicates in dataType.audioData the MAXIMUM > payload size for the forward channel to be opened. In non-fast start, > the endpoint opening the channel would obviously use the > information it > gathered in the terminal capability exchange in order not to > try to open > a channel that would exceed's the receiver's capabilities. > > In fastStart, there is no terminal capability negotiation. > The endpoint > sending the SETUP message includes the MAXIMUM payload size it can > support in both direction since it can not guess what are the > capabilites of the receiver. The receiver has to "select" > from the list > provided in the SETUP. > > Suppose that A calls B using fast start. A has a big buffer and can > support G.711 at up to 100 ms (send and receive). B can only > support 20 > ms. A calls B using fastStart and advertizes 100 ms for both > direction. > B has no choice but to reject the call, or to initiate H.245 > tunnelling > or a separate H.245 channel. This means to me that it can > actually be a > disadvantage to advertize a bigger maximum payload size than > the default > in fasStart. It also mean that fast start only has a reasonable chance > of working well if by chance the called party can handle an equal or > larger payload size than the originator. > > Any views on this? > > One possibility is that the receiving endpoint would be allowed to > signal a SMALLER payload size in the OLC it sends back to the > originator. This would however mean a change to the specification, and > would potentially mean backward interoperability problems > since current > implementations may not accept OLC contents that do not match what was > originally sent in the OLC in the SETUP message (they might reject the > call, or might ignore the changed values). > > The other possibility is for the sender of the SETUP message to > advertize multiple payload size as alternative OLCs. While it would be > possible in some cases to completely describe one's > capabilities without > creating huge fastStart messages (eg., G.723-30 ms, G.723-60 > ms), it may > not be practical for others (e.g., G.711-100 ms, G.711-99 ms, G.711-98 > ms, ... down to 1 ms). This would mean that in some cases, > you might be > restricted to only a few (maybe advertize the maximum and the > default). > Maybe a trick would be to advertize always at least the > default (20 ms) > if supported, and the maximum if different. > > In any case, I think we should clarify the procedures. > > ----- > François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com > <mailto:audet@NortelNetworks.com> > Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com > <http://www.nortelnetworks.com/> >

2 1

[Robustness] Teleconference 9AM EST USA, March 20
by Maureen Stillman 10 Mar '00

10 Mar '00

The next teleconference will be held at 9AM EST USA on March 20. Please send me e-mail to let me know if you will be able to attend. Attached are the minutes from the last robustness teleconference. The teleconference information is: 1-613-688-2795 The access code is: #4729 ----------------------------------- mintues from Teleconference on 3/1/2000 ------------------------------------------------------------------ Minutes of H.323 Robustness Teleconference - March 1, 2000 Prepared by Maureen Stillman, Nokia Next Teleconference: March 20, 2000 9AM EST USA Action items from this teleconference: 1. Post meeting minutes to mailing list 2. Jorg Ott will provide failure scenarios for gatekeepers for the Robustness Framework document. 3. Terry Anderson will provide H.225 and H.245 state machines for us to review. 4. Terry Anderson will provide failure scenarios involving a GK which exchanges information with a clearinghouse 5. Sasha Ruditsky will work on the SDL for the robustness procedure. Attending the 3/1/2000 teleconference (some names are missing from this list): Jill Caugherty jcaugher(a)cisco.com Maureen Stillman maureen.stillman(a)nokia.com Jorg Ott jo(a)tzi.uni-bremen.de Michael Fortinsky Michael_Fortinsky(a)vocaltec.com Terry Anderson of Lucent tla(a)bell-labs.com Nissani at Radvision Roy Radhika rrroy(a)att.com Summary of Teleconference: We discussed the draft of the robustness framework document. We decided to give priority to three topics specifically, examining failure scenarios and failure detection in detail and writing the SDL for the robustness procedure. 1) Failure detection. Modes of operation for H.225 and H.245 must be enumerated and potential failure states identified. In order to proceed in this direction we must have detailed state information for H.225 and H.245. Terry Anderson of Lucent volunteered to look into this area and develop a draft document. 2) Failure scenarios. We must investigate and describe failure scenarios. The first three that we will investigate focus on the GK. These scenarios are: * (Gatekeeper - endpoint): No relationship yet / anymore. * (Gatekeeper - endpoint): discovered but not registered. * (Gatekeeper - endpoint): discovered and registered. Jorg Ott offered to draft these scenarios for the group. Another important commercial scenario is the case in which the GK fails and is reporting information to a clearinghouse. If the GK fails the new GK must report information correctly to the clearinghouse. Terry Anderson will draft this scenario. 3) SDL for robustness procedures. It is required that we specify the robustness procedure using SDL. Sasha Ruditsky of Radvision will be working on a draft of this specification. A general comment on the robustness framework: The ultimate goal should be to provide a mapping between the failure scenarios and the robustness procedure(s). -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

2 1

FastStart and payload size
by Francois Audet 10 Mar '00

10 Mar '00

Another glitch with fast connect... The OpenLogicalChannel indicates in dataType.audioData the MAXIMUM payload size for the forward channel to be opened. In non-fast start, the endpoint opening the channel would obviously use the information it gathered in the terminal capability exchange in order not to try to open a channel that would exceed's the receiver's capabilities. In fastStart, there is no terminal capability negotiation. The endpoint sending the SETUP message includes the MAXIMUM payload size it can support in both direction since it can not guess what are the capabilites of the receiver. The receiver has to "select" from the list provided in the SETUP. Suppose that A calls B using fast start. A has a big buffer and can support G.711 at up to 100 ms (send and receive). B can only support 20 ms. A calls B using fastStart and advertizes 100 ms for both direction. B has no choice but to reject the call, or to initiate H.245 tunnelling or a separate H.245 channel. This means to me that it can actually be a disadvantage to advertize a bigger maximum payload size than the default in fasStart. It also mean that fast start only has a reasonable chance of working well if by chance the called party can handle an equal or larger payload size than the originator. Any views on this? One possibility is that the receiving endpoint would be allowed to signal a SMALLER payload size in the OLC it sends back to the originator. This would however mean a change to the specification, and would potentially mean backward interoperability problems since current implementations may not accept OLC contents that do not match what was originally sent in the OLC in the SETUP message (they might reject the call, or might ignore the changed values). The other possibility is for the sender of the SETUP message to advertize multiple payload size as alternative OLCs. While it would be possible in some cases to completely describe one's capabilities without creating huge fastStart messages (eg., G.723-30 ms, G.723-60 ms), it may not be practical for others (e.g., G.711-100 ms, G.711-99 ms, G.711-98 ms, ... down to 1 ms). This would mean that in some cases, you might be restricted to only a few (maybe advertize the maximum and the default). Maybe a trick would be to advertize always at least the default (20 ms) if supported, and the maximum if different. In any case, I think we should clarify the procedures. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com <mailto:audet@NortelNetworks.com> Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com <http://www.nortelnetworks.com/>

2 1

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

10 Mar '00

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@wipro.com] > Sent: Thursday, March 09, 2000 1:10 AM > To: Roy, Radhika R, ALARC; Kundan Singh; Hemant Agrawal > Cc: schulzrinne(a)cs.columbia.edu; jdrosen(a)dynamicsoft.com; korpim(a)sbs.de; > karl.klaghofer(a)vs.siemens.de; 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; 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 > > 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(a)att.com> > To: Kundan Singh <kns10(a)cs.columbia.edu>; 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>; <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>; Dilber, Ayse, ALARC > <adilber(a)att.com>; <stephen.terrill(a)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@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 > > > > > > > > > > > >

1 0

FW: 47th IETF: SIP323 BOF
by Dave Walker 09 Mar '00

09 Mar '00

For those who may have missed it, here is the official announcement of the BOF. Dave Walker SS8 Networks Ottawa, Canada -----Original Message----- From: mbeaulie(a)cnri.reston.va.us [mailto:mbeaulie@cnri.reston.va.us]On Behalf Of ietf-secretariat(a)ietf.org Subject: 47th IETF: SIP323 BOF SIP and H.323 Interworking BOF (sip323) Monday, March 27 at 1300-1500 ============================= 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

1 0

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

09 Mar '00

Hi, Dave and All: Yes, discussions are going on in many groups including the group that you have mentioned. I guess that most intense in-depth technical discussions are going on in those groups. However, some discussions also overflow in the SG16 reflector. It is up to the people to decide how they participate in those groups including the SG16 reflector. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Dave Walker [SMTP:drwalker@SS8NETWORKS.COM] > Sent: Thursday, March 09, 2000 9:13 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FYI - SIP-H.323 Interworking BOF > > That's true. However it's also true that regardless of the fact that lots > of people want to contribute to it, SG16 has not officially sanctioned > this work, and neither has the IETF. So I humbly suggest that these > discussions be confined to the neutral mailing list that was started > expressly for the purpose of discussing SIP-H.323 interworking: > http://www.egroups.com/group/sip-h323/ > > Dave Walker > SS8 Networks > Ottawa, Canada > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of VIPIN PALAWAT > Sent: Thursday, March 09, 2000 1:18 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > Hi everyone, > > If I am not wrong, the discussions and the benefits of IMTC groups are > more > or less restricted to IMTC members. > And to become a IMTC member, it costs $7500 anually which will restrict > the > open contribution from small companies > and enthusiastic fellows. > > As mentioned by Radhika, the purpose is to come out with a proposal > which > is widely accepted and commented by a large > community. So , I would rather prefer SG16 to be a better place of > discussion. > > I would like to have the views of other members also from this group. > > Best Regards > Vipin Palawat > > > ----- Original Message ----- > From: Roy, Radhika R, ALARC <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, March 08, 2000 9:57 PM > 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: FYI - SIP-H.323 Interworking BOF
by Roy, Radhika R, ALARC 09 Mar '00

09 Mar '00

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

3 2