- sg16-avd - lists.packetizer.com

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Rosen, Brian 03 Mar '00

03 Mar '00

If this document is stand-alone, not a part of the Megaco document, then it should stand on its merits. The IETF is free, as is the ITU, and any other organization, to define any profile it desires, with any set of options resolved any way it wants. The market will decide if such profiles are worthy. The agreement specifically did NOT include subsequent profiles, packages or other transports, and there are already planned annexes to H.248 which will not have IETF standard status. Please note that while I personally do prefer this profile specifying text, I would make the same argument if someone wanted to define a trunk gateway protocol as binary only. I might try to get that profile defined the other way, but I'd defend the right of the organization to define it binary only if it so chose. In this specific case, you clearly have an issue with code size. If the protocol specifies that both encodings will be implemented, that blows up the code, I would think, unacceptably. If you specify either, you create incompatible systems. Of course, that is the entire problem with the compromise. Brian Brian > -----Original Message----- > From: mikebuckley(a)attmail.com [mailto:mikebuckley@attmail.com] > Sent: Friday, March 03, 2000 8:35 AM > To: Rosen, Brian; ITU-SG16(a)mailbag.cps.intel.com > Cc: MEGACO(a)STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I agree wholeheartedly with Keith Drage's comment: > > >Surely it also dishonours the agreement between the ITU-T > and IETF groups, > >as they participated in agreeing the words that go in > H.248/MEGACO, but do > >not apparently participate in discussing the profile that then gets > >subsequently published by IETF. > > This attempt to sidestep the agreement with the ITU can only > create bad faith > between the two organizations. The Megaco wording was > arrived at after lengthy > discussions and compromise on both sides. The consequences > of unilaterally > trying to pursue one line will ony result in the ITU going > off in an incompatible > direction. Is this what the market wants - an IETF package > specifying text > encoding and an ITU Annex specifying binary? > > This is not the way to resolve the text v. binary issue and > it is not the way to built > good relations between the two Standards bodies. > > Agreements should be honoured by both sides in the spirit as > well as the letter. > > Mike Buckley > > > ____________________ Begin Original Message > ___________________________ > Date: Fri Mar 3 08:05:04 -0500 2000 > From: internet!FORE.COM!brosen (Rosen, Brian) > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO > Content-Type: Generic-Text > Content-Length: 5599 > > There are two threads in this message I wish to comment on. > 1. The issue of text encoding. Text/Binary Encoding is defined > in the protocol as optional. A profile could make a choice. > It is acceptable to me that such a choice be made in this profile. > > 2. Subsets of the protocol. I have been vociferous in positing > that profiles cannot subset the protocol. If the protocol > defines something as optional, then the profile can declare > what options shall be implemented. Where there is not an option, > profiles should not make something optional. If it does, it's > a new protocol. Call it that, and we can decide if we want > to standardize a new protocol. I personally do not believe that > an IPPhone needs to subset the Megaco protocol. > > Brian > > > > > -----Original Message----- > > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > > Sent: Friday, March 03, 2000 4:43 AM > > To: MEGACO(a)standards.nortelnetworks.com > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > I note that this proposed profile contains the text: > > > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > > specified in the Megaco/H.248 Protocol document [3]." > > > > While I DO NOT want to reopen the encoding debate, it seems > > inappropriate to > > me that MEGACO should create a profile that further restricts it own > > product. I understood the summary of the text versus binary > > debate was that > > the decision on encoding would be made by market forces, and was NOT > > application dependent. If there is an application dependency, then > > guidelines to that dependency should surely be given in the > > main MEGACO > > protocol document. > > > > Surely it also dishonours the agreement between the ITU-T and > > IETF groups, > > as they participated in agreeing the words that go in > > H.248/MEGACO, but do > > not apparently participate in discussing the profile that then gets > > subsequently published by IETF. > > > > I would have therefore thought that if TIA wish to restrict > > the encoding > > choice, then it is up to TIA to publish the profile, rather > > than the IETF. > > > > Looking further, I notice that the document also defines > > constraints on the > > usage of Events, etc. Reading the main MEGACO protocol document, I > > understand that variations on termination characteristics should be > > implemented by specification of a package. Should these restrictions > > therefore be defined by a new package? > > > > I guess we need some general discussion on what is possible > > in profiles, as > > opposed to packages, and whether MEGACO should define > > profiles that are > > still nominally called MEGACO, but do not exhibit all the > > requirements of > > the main document. Rephrasing in a slightly different way, > > which are the > > options, and which of these options that are selected based > > on the type of > > application (and therefore suitable for specification in > > profiles for a > > particular application), and which are implementation options > > (and selected > > because an implementor wishes to make his product different > > and presumably > > better/cheaper/fit the available memory than another market > entrant). > > > > Rephrasing the question a different way, with the > > restrictions imposed by > > this "profile", can the result still be MEGACO/H.248, or > has it really > > invented a new protocol? > > > > Let me stress again, I do not want to see any responses that > > it is done this > > way because text is better than binary, or more efficient. > > The answer to > > that is irrelevant to the point I am trying to make. > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage(a)siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > are solely > > > those of the author and do not necessarily represent those > > of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > This draft is a work item of the Media Gateway Control > > > Working Group of the IETF. > > > > > > Title : Megaco IP Phone Media Gateway > > > Application Profile > > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > > Filename : draft-ietf-megaco-ipphone-02.txt > > > Pages : 13 > > > Date : 01-Mar-00 > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage(a)siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > >

1 0

Re: H.323 Annex D
by Francois Audet 03 Mar '00

03 Mar '00

By default, I believe that editor would be me. This annex was intended to work with H.323v2 systems and later, but you are correct that there was no way to specify T.38 until H.245v4. Of course, H.323v2 systems used H.245v3. H.323v3 systems used H.245v3 or higher (the key element). So, I suppose the question is: is H.323v3 required? Surely not, as there are implementations out there. We have argued about whether H.323v2 systems could use later versions of H.245. The outcome was "no"-- perhaps that needs to be revisited. Interesting: I tought H.323v2 used H.245v2... Side issue anyways. There have been recent changes to H.245 ASN.1 to support T.38. At least there have been some proposed changes. Unfortunately, I missed much of that discussion. The meeting report says that those changes were added to H.245v6. Mike, is it true that the T.38-related changes from H.245v4 to H.245v6 were nothing more than additions to H.245-- not "changes", per se. Also, did the proposed changes (from TD8/WP2, I believe) make it into H.245v6? My understanding would be that the changes were introduced in H.245v4, but had mistakes that were corrected in H.245v6. As for Annex D, I am considering just pulling that into the H.323 document, rather than keeping it as a separately published annex-- does anybody object to that? That would certainly address questions related to references going forward. However, we need to reach a decision about the current publication. I suspect we need something for the IG, but the problem is that H.323v2 is "old news" now. What to do.... I would support including Annex D in the main H.323v4 document (wich would imply H.245v6). The other alternatives would be to mandate H.323v4/H.245v6 in Annex D. But I prefer the first alternative.

3 2

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Mike Buckley 03 Mar '00

03 Mar '00

I agree wholeheartedly with Keith Drage's comment: >Surely it also dishonours the agreement between the ITU-T and IETF groups, >as they participated in agreeing the words that go in H.248/MEGACO, but do >not apparently participate in discussing the profile that then gets >subsequently published by IETF. This attempt to sidestep the agreement with the ITU can only create bad faith between the two organizations. The Megaco wording was arrived at after lengthy discussions and compromise on both sides. The consequences of unilaterally trying to pursue one line will ony result in the ITU going off in an incompatible direction. Is this what the market wants - an IETF package specifying text encoding and an ITU Annex specifying binary? This is not the way to resolve the text v. binary issue and it is not the way to built good relations between the two Standards bodies. Agreements should be honoured by both sides in the spirit as well as the letter. Mike Buckley ____________________ Begin Original Message ___________________________ Date: Fri Mar 3 08:05:04 -0500 2000 From: internet!FORE.COM!brosen (Rosen, Brian) Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 5599 There are two threads in this message I wish to comment on. 1. The issue of text encoding. Text/Binary Encoding is defined in the protocol as optional. A profile could make a choice. It is acceptable to me that such a choice be made in this profile. 2. Subsets of the protocol. I have been vociferous in positing that profiles cannot subset the protocol. If the protocol defines something as optional, then the profile can declare what options shall be implemented. Where there is not an option, profiles should not make something optional. If it does, it's a new protocol. Call it that, and we can decide if we want to standardize a new protocol. I personally do not believe that an IPPhone needs to subset the Megaco protocol. Brian > -----Original Message----- > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > Sent: Friday, March 03, 2000 4:43 AM > To: MEGACO(a)standards.nortelnetworks.com > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I note that this proposed profile contains the text: > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > specified in the Megaco/H.248 Protocol document [3]." > > While I DO NOT want to reopen the encoding debate, it seems > inappropriate to > me that MEGACO should create a profile that further restricts it own > product. I understood the summary of the text versus binary > debate was that > the decision on encoding would be made by market forces, and was NOT > application dependent. If there is an application dependency, then > guidelines to that dependency should surely be given in the > main MEGACO > protocol document. > > Surely it also dishonours the agreement between the ITU-T and > IETF groups, > as they participated in agreeing the words that go in > H.248/MEGACO, but do > not apparently participate in discussing the profile that then gets > subsequently published by IETF. > > I would have therefore thought that if TIA wish to restrict > the encoding > choice, then it is up to TIA to publish the profile, rather > than the IETF. > > Looking further, I notice that the document also defines > constraints on the > usage of Events, etc. Reading the main MEGACO protocol document, I > understand that variations on termination characteristics should be > implemented by specification of a package. Should these restrictions > therefore be defined by a new package? > > I guess we need some general discussion on what is possible > in profiles, as > opposed to packages, and whether MEGACO should define > profiles that are > still nominally called MEGACO, but do not exhibit all the > requirements of > the main document. Rephrasing in a slightly different way, > which are the > options, and which of these options that are selected based > on the type of > application (and therefore suitable for specification in > profiles for a > particular application), and which are implementation options > (and selected > because an implementor wishes to make his product different > and presumably > better/cheaper/fit the available memory than another market entrant). > > Rephrasing the question a different way, with the > restrictions imposed by > this "profile", can the result still be MEGACO/H.248, or has it really > invented a new protocol? > > Let me stress again, I do not want to see any responses that > it is done this > way because text is better than binary, or more efficient. > The answer to > that is irrelevant to the point I am trying to make. > > Keith Drage > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage(a)siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented are solely > > those of the author and do not necessarily represent those > of Siemens > > Communications Limited unless otherwise specifically stated. > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Media Gateway Control > > Working Group of the IETF. > > > > Title : Megaco IP Phone Media Gateway > > Application Profile > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > Filename : draft-ietf-megaco-ipphone-02.txt > > Pages : 13 > > Date : 01-Mar-00 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage(a)siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented > are solely those > > of the author and do not necessarily represent those of Siemens > > Communications Limited unless otherwise specifically stated. > > > > >

1 0

[openh323] Multiple phone on the same node
by Hans Viens 03 Mar '00

03 Mar '00

Hi, I have a product which has a unique IP address (one node). This device has 1 Ethernet port, 1 PSTN port and 3 phones connected on it. I want to take advantage of the PSTN port and Ethernet port to make it act like a H.323/PSTN gateway. Also, each phone can be use as a H.323 terminal endpoint. My problem is: how could I registered my device to a gatekeeper (knowing the Gateway functionnality of the device and its 3 terminal endpoints) ? Is it possible to registered a device (1 IP address) which has multiple functionnalities (i.e. Terminal and Gateway) ? If anyone could help, I would appreciate it! Hans ----------------------------------------------------- OpenH323 mailing list - openh323(a)openh323.org OpenH323 home page - http://www.openh323.org Maintained by Equivalence Pty Ltd - http://www.equival.com.au Using majordomo 1.94.1 - for information on commands, send email to "majordomo(a)openh323.org" with the text "info openh323" in the body of the message -----------------------------------------------------

2 1

FYI - SIP-H.323 Interworking BOF
by Joon Maeng 02 Mar '00

02 Mar '00

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

1 0

Re: [H.323-SIP/Internet] The reason.
by Orit Levin 02 Mar '00

02 Mar '00

Hello Bahman! I agree (without furiously) that Christian's proposal is excellent. I already incorporated it into the proposed ToR. (I hope he doesn't mind...) It also reflects most of the points raised on the mailing list so far. In my opinion it applies very good to H.323-SIP interworking issue. As to H.323 using Internet services, I haven't change my opinion. I will clarify it in the document adding new examples (based on inputs I am receiving from people). 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: Bahman Mobasser <bahman.mobasser(a)alcatel.fr> To: Orit Levin <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, March 02, 2000 12:35 PM Subject: RE: [H.323-SIP/Internet] The reason. >Orit- > >I think, as they say, we're furiously agreeing. What I wrote on your option >two was a bit in shorthand. Of course, like you, I consider that H.323 has >been designed for RTP and Internet use from the beginning. What I meant was >if we (i.e., COM16), now say we're *starting* work on H.323 interworking >with internet that would confuse everybody and me specially. It would >suggest that H.323 does not work on internet today. > >I found the organisation of work proposed by Christian Groves very good and >logical. I read his proposal as being sequential, i.e., a number of steps >which follow each other. This could be our work-plan. > >Bahman > >----------------------------------------------------- >Bahman Mobasser Tel: +33 1 30771608 >Alcatel Mobile: +33 6 12091822 >10 rue Latécoère Fax: +33 1 30779914 >78140 Vélizy Voice & Fax Mail: +33 1 5301 0789 >France Roaming email: Bahman(a)Bahman.org >----------------------------------------------------- > >[[ MAPI 1.0 storage : 4355 in winmail.dat ]] > >-----Original Message----- >From: Mailing list for parties associated with ITU-T Study Group 16 >[mailto:ITU-SG16@mailbag.cps.intel.com] On Behalf Of Orit Levin >Sent: mardi 29 février 2000 18:28 >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Re: [H.323-SIP/Internet] The reason. > >Bahman, >I definitely agree with the interpretation of (1). I think that protocol's >requirements and reasonable topology definition should be addressed by SG16. >In regards to (2), I tend to disagree. H.323 has been using RTP >specification from the very beginning. I don't think that today anyone >doubts the intelligence behind this decision. I believe the benefit of >using required services in an interoperable manner is more important that >being afraid of sending the wrong signals. >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: Bahman Mobasser <bahman.mobasser(a)ALCATEL.FR> >To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> >Date: Tuesday, February 29, 2000 11:40 AM >Subject: Re: [H.323-SIP/Internet] The reason. > > >Orit- > >In my opinion what would most useful would a restrictive interpretation of >1, and I will explain: what is needed is the specification of an H.323-SIP >call. Depending on the network configuration assumptions (i.e., what >equipment is between the two end-points), the mapping needs will become >clear. > >On this option I share your point of view- while this may be politically >incorrect, I think inviting everybody to the Picnic does not necessarily >advance things. If one organisation (IETF) has taken the lead in doing this, >then the best thing to do is to encourage them by taking proposals there. > >2 confuses me too much and sends, in my opinion, completely the wrong >signals and should be avoided. > >Bahman > >----------------------------------------------------- >Bahman Mobasser Tel: +33 1 30771608 >Alcatel Mobile: +33 6 12091822 >10 rue Latécoère Fax: +33 1 30779914 >78140 Vélizy Voice & Fax Mail: +33 1 5301 0789 >France Roaming email: Bahman(a)Bahman.org >----------------------------------------------------- > >[[ MAPI 1.0 storage : 4140 in winmail.dat ]] > >-----Original Message----- >From: Mailing list for parties associated with ITU-T Study Group 16 >[mailto:ITU-SG16@mailbag.cps.intel.com] On Behalf Of Orit Levin >Sent: lundi 28 février 2000 17:25 >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Re: [H.323-SIP/Internet] The reason. > >Hello! >I can see two (hardly overlapping) directions to move forward: >(1) H.323 - SIP interworking by mapping/translation >(2) Definition of how H.323 takes use of Internet services being defined by >IETF > >In the regards to (1), my personal preference would be to leave this work >under the IETF process. I suspect they had a perfect reason being the first >to start this work. It doesn't mean SG16 shouldn't prevent them from making >mistakes on H.323 side. > >In regards to (2), I think it has to be addressed by H.323 as a part of >H.323. I would love to see more comments on this (less political) part of >the work. > >In the meanwhile I am putting all the suggestions and alternatives in the >updated paper (which is not attached yet). >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: Henning Schulzrinne <hgs(a)CS.COLUMBIA.EDU> >To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> >Date: Sunday, February 27, 2000 10:57 PM >Subject: Re: [H.323-SIP/Internet] The reason. > > >>Since my name popped up in a recent email discussion, a few remarks: >> >>1) Yes, the SIP-H.323 list was created by myself; it is open to anybody. >>While its creation was triggered by the interest generated by a proposal >>(Internet draft) written by Kundan Singh (a student of mine) and myself, >>it is open to any discussion related to the topic of interworking. >>(Discussions about the relative merits of protocols are decidedly less >>appreciated.) Whether people use this mailing list or create something >>new and different is obviously beyond my control. >> >>The creation of the mailing list was done without any implied IETF >>endorsement or even endorsement of other SIP authors. (I hope they don't >>mind too much...) >> >>2) In this context, there is one important difference between the ITU >>and IETF standardization process which particularly affects this >>discussion. While all ITU recommendations are "standards", most IETF >>RFCs are not. For the case at hand, it would probably be considered >>inappropriate for a standards-track RFC except, with lots of stretch of >>the imagination, a BCP (best current practice). If an interoperability >>document does get published within the IETF, it is likely to appear as >>an Informational or possibly Experimental RFC. In this particular case, >>as long as the signaling gateway looks like a valid SIP or H.323 entity, >>the other SIP and H.323 entities won't know that it is talking to the >>"other side" (you can insert "dark side" or "the enemy" if you are so >>inclined). >> >>As our initial document points out, there is probably a range of >>solutions that satisfy this basic criterion, depending on (for example) >>to what extent X entities are visible in Y land. >> >>In my view, publishing any such interoperability document has the >>primary benefit of saving implementors of such devices, should they >>become popular, a bit of thinking time and maybe avoid some pitfalls. >>They are not strictly *necessary* - anybody could derive one of the >>modes that we described or something different, as long as it satisfies >>the basic "in Rome, do as the Romans" criterion mentioned earlier. >> >>Thus, given that a standards-track document is not really called for on >>the IETF side, this effort could be significantly simpler than, say, the >>Megaco/H.248 effort. My rough perception is that the IESG will basically >>ask at publication time whether the document suggested as an >>Informational RFC violates IETF protocols (SIP and SDP, in this case). >>If not, and it does no other harm (e.g., broadcasting a RAS-like query >>to all SIP nodes in the Internet or something similarly stupid), the >>IETF process should be relatively straightforward, even without a lot of >>cooperation machinery, liaison agreements and the like. I realize that >>this assessment is probably hopelessly naive, but I am concerned that >>the collective effort expended on meta-discussions is rapidly >>approaching the effort that seems to be necessary to write an >>interoperability document for basic services, including the time to >>implement it. >> >>We'd be happy to provide the infrastructure for meetings, allowing the >>ITU participants to use their H.323 phones to call our SIP phones using >>our gateway implementation :-) No, we won't charge the ITU for these >>translation services :-) >> >>Regards, >> >>Henning >

2 1

[H.323-SIP/Internet] DHCP option tags
by Orit Levin 02 Mar '00

02 Mar '00

Hello all! I would like to bring your attention to the topic in the attached e-mail. The intend of the proposed procedure is to use DHC Protocol at the bootstrap time in order to receive the IP address(es) of SIP (Proxy) Server(s). In other words, a kind of RAS Discovery procedure for SIP. The purpose to this e-mail is not to compare between the two procedures. My thinking is that end devices should support more then one procedure for the same purpose (especially when it is a configuration issue). In this way they are flexible and can be deployed in various environments. My concern is that the functionality described in this proposal (see the attachment) is by no means SIP-specific. There are many application level protocols that require this sort of functionality, i.e. they relay on application-specific Server (or a list of possible Servers), whose IP address(es) should be discovered. The examples only in our area are H.323 and MEGACO. Taking a look into "Procedure for Defining New DHCP Options" RFC-2489 you will find that "the option number space for publicly defined DHCP options has almost been exhausted" and this is the whole reason for the new procedure defined by RFC-2489. More then that: in order to solve this allocation problem "groups of related options may be combined into a single specification and reviewed as a set by the IESG". Based on this I would like to request from SIP Working group to review their proposal (possibly as a part of "fast track" procedure). Opinions? 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

1 0

Re: ATMParameters in H.245
by Francois Audet 02 Mar '00

02 Mar '00

Yes, I have mentioned this a few times in the meetings. Somebody should bring a precise proposal to change the names from ATM Forum centric terminology to ITU-T terminology (SBR, etc.). The problem is finding an ATM-minded person who cares enought to actually write the contribution... ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com > -----Original Message----- > From: Srini Beereddy [mailto:srini@TRILLIUM.COM] > Sent: Thursday, March 02, 2000 10:40 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: ATMParameters in H.245 > > > Hi, > > There is a editorial comment about ATM Parameters in all the > versions of > H.245 (I checked in V3, V5 and V6). I guess these parameters > need to be > aligned with I.371 and the never been done so far. Can anyone > throw some > light on this. > > -- Ed. Replace with ITU-T ATM Transfer Capability Types > ATMParameters ::=SEQUENCE > { > maxNTUSize INTEGER(0..65535), --units in octets > atmUBR BOOLEAN, --unspecified bit rate > atmrtVBR BOOLEAN, --real > time variable > bit rate > atmnrtVBR BOOLEAN, --non real time > variable bit rate > atmABR BOOLEAN, --available bit rate > atmCBR BOOLEAN, --constant bit rate > ... > } > > thanks, > Srini, > Trillium Digital Systems, Inc. >

1 0

ATMParameters in H.245
by Srini Beereddy 02 Mar '00

02 Mar '00

Hi, There is a editorial comment about ATM Parameters in all the versions of H.245 (I checked in V3, V5 and V6). I guess these parameters need to be aligned with I.371 and the never been done so far. Can anyone throw some light on this. -- Ed. Replace with ITU-T ATM Transfer Capability Types ATMParameters ::=SEQUENCE { maxNTUSize INTEGER(0..65535), --units in octets atmUBR BOOLEAN, --unspecified bit rate atmrtVBR BOOLEAN, --real time variable bit rate atmnrtVBR BOOLEAN, --non real time variable bit rate atmABR BOOLEAN, --available bit rate atmCBR BOOLEAN, --constant bit rate ... } thanks, Srini, Trillium Digital Systems, Inc.

1 0

Re: [H.323-SIP/Internet] The reason.
by Orit Levin 02 Mar '00

02 Mar '00

Bahman, I definitely agree with the interpretation of (1). I think that protocol's requirements and reasonable topology definition should be addressed by SG16. In regards to (2), I tend to disagree. H.323 has been using RTP specification from the very beginning. I don't think that today anyone doubts the intelligence behind this decision. I believe the benefit of using required services in an interoperable manner is more important that being afraid of sending the wrong signals. 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: Bahman Mobasser <bahman.mobasser(a)ALCATEL.FR> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Tuesday, February 29, 2000 11:40 AM Subject: Re: [H.323-SIP/Internet] The reason. Orit- In my opinion what would most useful would a restrictive interpretation of 1, and I will explain: what is needed is the specification of an H.323-SIP call. Depending on the network configuration assumptions (i.e., what equipment is between the two end-points), the mapping needs will become clear. On this option I share your point of view- while this may be politically incorrect, I think inviting everybody to the Picnic does not necessarily advance things. If one organisation (IETF) has taken the lead in doing this, then the best thing to do is to encourage them by taking proposals there. 2 confuses me too much and sends, in my opinion, completely the wrong signals and should be avoided. Bahman ----------------------------------------------------- Bahman Mobasser Tel: +33 1 30771608 Alcatel Mobile: +33 6 12091822 10 rue Latécoère Fax: +33 1 30779914 78140 Vélizy Voice & Fax Mail: +33 1 5301 0789 France Roaming email: Bahman(a)Bahman.org ----------------------------------------------------- [[ MAPI 1.0 storage : 4140 in winmail.dat ]] -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.intel.com] On Behalf Of Orit Levin Sent: lundi 28 février 2000 17:25 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323-SIP/Internet] The reason. Hello! I can see two (hardly overlapping) directions to move forward: (1) H.323 - SIP interworking by mapping/translation (2) Definition of how H.323 takes use of Internet services being defined by IETF In the regards to (1), my personal preference would be to leave this work under the IETF process. I suspect they had a perfect reason being the first to start this work. It doesn't mean SG16 shouldn't prevent them from making mistakes on H.323 side. In regards to (2), I think it has to be addressed by H.323 as a part of H.323. I would love to see more comments on this (less political) part of the work. In the meanwhile I am putting all the suggestions and alternatives in the updated paper (which is not attached yet). 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: Henning Schulzrinne <hgs(a)CS.COLUMBIA.EDU> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Sunday, February 27, 2000 10:57 PM Subject: Re: [H.323-SIP/Internet] The reason. >Since my name popped up in a recent email discussion, a few remarks: > >1) Yes, the SIP-H.323 list was created by myself; it is open to anybody. >While its creation was triggered by the interest generated by a proposal >(Internet draft) written by Kundan Singh (a student of mine) and myself, >it is open to any discussion related to the topic of interworking. >(Discussions about the relative merits of protocols are decidedly less >appreciated.) Whether people use this mailing list or create something >new and different is obviously beyond my control. > >The creation of the mailing list was done without any implied IETF >endorsement or even endorsement of other SIP authors. (I hope they don't >mind too much...) > >2) In this context, there is one important difference between the ITU >and IETF standardization process which particularly affects this >discussion. While all ITU recommendations are "standards", most IETF >RFCs are not. For the case at hand, it would probably be considered >inappropriate for a standards-track RFC except, with lots of stretch of >the imagination, a BCP (best current practice). If an interoperability >document does get published within the IETF, it is likely to appear as >an Informational or possibly Experimental RFC. In this particular case, >as long as the signaling gateway looks like a valid SIP or H.323 entity, >the other SIP and H.323 entities won't know that it is talking to the >"other side" (you can insert "dark side" or "the enemy" if you are so >inclined). > >As our initial document points out, there is probably a range of >solutions that satisfy this basic criterion, depending on (for example) >to what extent X entities are visible in Y land. > >In my view, publishing any such interoperability document has the >primary benefit of saving implementors of such devices, should they >become popular, a bit of thinking time and maybe avoid some pitfalls. >They are not strictly *necessary* - anybody could derive one of the >modes that we described or something different, as long as it satisfies >the basic "in Rome, do as the Romans" criterion mentioned earlier. > >Thus, given that a standards-track document is not really called for on >the IETF side, this effort could be significantly simpler than, say, the >Megaco/H.248 effort. My rough perception is that the IESG will basically >ask at publication time whether the document suggested as an >Informational RFC violates IETF protocols (SIP and SDP, in this case). >If not, and it does no other harm (e.g., broadcasting a RAS-like query >to all SIP nodes in the Internet or something similarly stupid), the >IETF process should be relatively straightforward, even without a lot of >cooperation machinery, liaison agreements and the like. I realize that >this assessment is probably hopelessly naive, but I am concerned that >the collective effort expended on meta-discussions is rapidly >approaching the effort that seems to be necessary to write an >interoperability document for basic services, including the time to >implement it. > >We'd be happy to provide the infrastructure for meetings, allowing the >ITU participants to use their H.323 phones to call our SIP phones using >our gateway implementation :-) No, we won't charge the ITU for these >translation services :-) > >Regards, > >Henning

2 1

[H.323-SIP/Internet] Re: H323/SIP Interworking - way forward
by Orit Levin 02 Mar '00

02 Mar '00

Hello guys! I have exactly same point of view on this path. I would like to be sure that we are talking about the same path. In my understanding (1) and (3) are the same combined (GK and SIP Server) entity (2) is a GK++ being able to talk to SIP Server using SIP only(?) (4) is a SIP Server++ being able to talk to GK using RAS (?) using Annex G/H.225.0 (?) Based on this I would vote for (1) and (3) only (which are the same). "Now, to thin it some more..." Considerations in regards to GK Routed/Direct modes and SIP Proxy flavors ... I vote for - GK Routed mode only - SIP Server having a logic of Statefull Proxy, Registrar and Redirect Server 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: Paul E. Jones <paul.jones(a)ties.itu.int> To: sip-h323(a)egroups.com <sip-h323(a)egroups.com> Date: Thursday, March 02, 2000 2:44 AM Subject: [sip-h323] Re: H323/SIP Interworking - way forward >David, > >Dave Walker suggested removing the first 5 scenarios. I'd agree with that >recommendation. > >Now, to thin it some more... > >Would it not be a reasonable thing to state that interworking between H.323 >networks/devices and SIP networks/devices should be performed by either a GK >or proxy that contains the interworking functions. If folks agree with >that, then we could just have these scenarios: > >HT-----GK/IWF---------------------------ST >HT-----GK/IWF--------------------SR-----ST >HT-----------------------------SR/IWF---ST >HT-----GK----------------------SR/IWF---ST > >Of course, the first two and the last two above are virtually identical. If >the IWF is designed appropriately, there should be no need to make a special >case for #2 and #4 above. > >The reason I would propose this is that it makes sense to collocate the >interworking function within such a device. Additionally, it removes burden >(both new signaling procedures and complexity) from the endpoints, which I >think should be a goal. > >Paul > >----- Original Message ----- >From: "Wang, Dave" <dwang(a)nuera.com> >To: <sip-h323(a)egroups.com> >Sent: Wednesday, March 01, 2000 9:53 AM >Subject: [sip-h323] Re: H323/SIP Interworking - way forward > > >> I 2nd Christian's 4 things and their ordering. >> >> We have started working on the 1st 3 things in IMTC aHIT and ETSI TIPHON, >> but would definitely use more input. >> >> Therefore, could we start having some suggestion and discussion here on >the >> 1st thing : "Architecture and Call Scenarios" ? >> >> There was a very short discussion in this thread about "combination" in >> January started by Joon Maeng, and Kundan Singh. Here is a set of >> combinations that I've expanded from that discussion. I don't mean to make >> the scenarios more comprehensive and complicated. I'm just trying to show >> the various combinations and ask whether we can explicity decided to >ignore >> some of them : >> >> HT-------(H.323)----------------------------------HT >> >> ST------------------------------------(SIP)-------ST >> >> HT---GK--(H.323)----------------------------------HT >> >> ST------------------------------------(SIP)--SR---ST >> >> HT-------(H.323)--IWF-----------------(SIP)-------HT >> >> HT-------(H.323)--IWF-----------------(SIP)-------ST >> >> HT---GK--(H.323)--IWF-----------------(SIP)-------ST >> >> HT---GK--(H.323)--IWF-----------------(SIP)--SR---ST >> >> HT-------(H.323)--IWF-----------------(SIP)--SR---ST >> >> HT-------(H.323)--IWF---(SIP)---IWF--(H.323)------HT >> >> ST--------(SIP)---IWF--(H.323)--IWF---(SIP)-------ST >> >> HT == H.323 Terminal >> ST == SIP Terminal >> GK == H.323 Gate Keeper >> SR == SIP Server >> IWF == SIP/H.323 Inter-working Function >> >> Its has already been pointed out that we should also include Clearing >House >> in the scenarios, however, may be we should have some more discussion and >> possibly some thinning down before thickening it up yet. >> >> >> > -----Original Message----- >> > From: Christian Groves [mailto:Christian.Groves@ericsson.com] >> > Sent: Wednesday, March 01, 2000 2:43 AM >> > To: SG16; sip-h323 >> > Subject: [sip-h323] H323/SIP Interworking - way forward >> > >> > >> > G'Day all, >> > >> > The [H.323-SIP/Internet] thread has lead to some interesting >> > discussion. >> > Being personally involved in the H248 "success" and having actually >> > having had to fight through the process of having to work between SG16 >> > and IETF I think there's a few steps that need to be taken >> > before we go >> > into mapping information elements. >> > >> > I believe the first thing we need to do is define what >> > architecture and >> > call scenarios we are working with. H323 has several architectural >> > elements, SIP is not so strong on architecture so we need to show what >> > elements are talking to each other. Only then we can define what >> > interfaces need to be interworked. In H248 this was relatively easy as >> > the interface was between an MGC and MG. The H323-SIP >> > interworking would >> > be another degree of difficulty as there are potentially several >> > interfaces. This architecture work would not slow down the work but >> > would lead to a structured way of working were people agree >> > on a problem >> > space. One of the issues with H248 was that the problem space was not >> > agree on and we went back and forth trying to figure out >> > where we were. >> > >> > As I mentioned at the SG16 I invite people to make contributions on >> > this. Anything more detailed at this stage I believe is counter >> > productive. Even Orit's first proposal I think is too detailed at this >> > stage. Look at the early H248 work where we had many detailed >> > protocols. >> > There was an inordinate amount of work spent (and many late nights) >> > trying to get from details to architecture. Then we had to go >> > back again >> > and define the protocol. >> > >> > The 2nd thing to do is to define the set of capabilities we intend to >> > interwork. This needs to be a clear statement of scope. Interworking >> > basic audio with no conferencing and services is >> > significantly different >> > than interworking full audio, video and data conferencing. In H248 the >> > scope was so large that people were working on completely different >> > things without appreciating the other people's requirements. >> > >> > Thirdly, we must choose our base. What H323version will be interwork >> > with what SIP flavour and functionalities? Of course in today's world >> > there needs to be flexibility to address new functionality but we >> > shouldn't add a new work item every time of version 0 of an internet >> > draft from Joe Bloggs comes out. >> > >> > Fourthly, I believe that once the above is done, then we have a very >> > good idea of what functional interworking work needs to be >> > done. Once we >> > have an idea of the work we can also figure out where the >> > responsibilities would lie. >> > >> > Once we know the work and who is responsible for the work then we MUST >> > make sure this is agreed upon and documented in both the ITU >> > and IETF by >> > the people who can make decisions. Too many things were hidden in the >> > H248 work and people that could make decisions were not at the >> > appropriate meetings. >> > >> > Finally we can then produce the detailed documents in a way that >> > everyone understands. >> > >> > I do think that at the end of the day H.248 was a success and that the >> > co-operation between the IETF and ITU was made to work. This >> > was because >> > of the large amount of work and sacrifices made by a few >> > individuals and >> > companies who wanted to make this happen. Many of the individuals >> > working on H248 will probably contribute on H323/SIP interworking so >> > lets learn from the mistakes and have another go at making H323-SIP >> > interworking work without having to kill ourselves to achieve >> > the goal. >> > >> > Cheers, Christian >> > >> > -------------------------------------------------------------- >> > ---------- >> > 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 >> > >> > -------------------------------------------------------------- >> > ---------- >> > Shabang!com is the place to get your FREE eStore, Absolutely FREE >> > Forever. If you have any desires to sell your products or services >> > online, or you want to expand your customer base for FREE, Come check >> > out Shabang!com FREE eStores! >> > http://click.egroups.com/1/1299/2/_/302437/_/951907402/ >> > >> > -- Easily schedule meetings and events using the group calendar! >> > -- http://www.egroups.com/cal?listname=sip-h323&m=1 >> > >> > >> >> ------------------------------------------------------------------------ >> 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 >> >> ------------------------------------------------------------------------ >> GET A NEXTCARD VISA, in 30 seconds! Get rates >> as low as 0.0% Intro APR and no hidden fees. >> Apply NOW! >> http://click.egroups.com/1/969/2/_/302437/_/951922564/ >> >> -- 20 megs of disk space in your group's Document Vault >> -- http://www.egroups.com/docvault/sip-h323/?m=1 >> >> > > >------------------------------------------------------------------------ >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 > >------------------------------------------------------------------------ >You have a voice mail message waiting for you at iHello.com: >http://click.egroups.com/1/2130/2/_/302437/_/951983045/ > >-- Create a poll/survey for your group! >-- http://www.egroups.com/vote?listname=sip-h323&m=1 > >

1 0

Errors / ambiguities / problems found in specs at last week's int erop
by Reinhard Scholl 02 Mar '00

02 Mar '00

The following errors / ambiguities / problems were reported at last week's ETSI-TIPHON/IMTC interop event at ETSI: - Terminal capabilities for G.729 and G.729 Annex A. Though mutually compatible, TCS often fails if vendors only specify support for one or the other. E.g. 729 <--> 729a should work but TCS fails. - H323: GK cannot increase TTL in RCF. Mandatory parameters of type SEQUENCE OF ... can have empty list. - H.225 says that call reference value should be same in ARQ and SETUP. H.323 says that call reference value should be different in ARQ and SETUP. - In H.323, the destination address in UUIE in SETUP is mandatory, in H.225.0 it is not. - H.245: if a capability being sent includes G.711 "20 msec", the other side may think that the sender supports both "20 msec" and "10 msec" rates. But it can be that the originator supports only 20 msec. Ambiguity. - MCU should probably also have "prefix", not just the gateway. - Need BE message formats so that packet dumps can be quickly interpreted. - When using a GK, should the CRV in the admission and setup be the same? Reinhard Scholl ETSI

3 2

Progress syntax changed v2 to v3?
by Paul Long 02 Mar '00

02 Mar '00

It looks like the syntax for Progress changed between H.225.0v2 and v3. Seems like this would present some rather basic interoperability problems. Do I simply have the wrong syntax for v3? This is the syntax for Progress in the published H.225.0v2 Recommendation from the ITU: Progress-UUIE ::= SEQUENCE { protocolIdentifier ProtocolIdentifier, destinationInfo EndpointType, h245Address TransportAddress OPTIONAL, callIdentifier CallIdentifier, h245SecurityMode H245Security OPTIONAL, ..., tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, fastStart SEQUENCE OF OCTET STRING OPTIONAL, } ...and this is the syntax for the same type in v3: Progress-UUIE ::= SEQUENCE { protocolIdentifier ProtocolIdentifier, destinationInfo EndpointType, h245Address TransportAddress OPTIONAL, callIdentifier CallIdentifier, h245SecurityMode H245Security OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, fastStart SEQUENCE OF OCTET STRING OPTIONAL, ..., multipleCalls BOOLEAN, maintainConnection BOOLEAN } Paul Long Smith Micro Software, Inc.

2 1

Re: H.323 Annex D
by Francois Audet 02 Mar '00

02 Mar '00

I will seriously consider pulling Annex D into the main document. It makes my life a bit easier, too. However, I suppose it's worth noting which version of H.323 an Annex will work with in general. I have had similar inquiries about Annex E and Annex F. Perhaps a new section in the Implementers Guide is in order to address those issues? I think that it should be in the summary of the Recommendation, if we pusblish it separatly. Not everybody reads the implementor's guide (although they should). That is what we have done for H.323 to relate it to different versions of H.225.0 and H.245.

2 1

Re: Errors / ambiguities / problems found in specs at last week's int erop
by Hutton, Charles 01 Mar '00

01 Mar '00

Paul: 729 and 729A do indeed use the same encoder. Only the decoder is different. Performance of 729A is poorer, particularly with respect to tandeming. I can see that it may sometimes be beneficial to control whether the 729 or 729A algorithm (if a choice is available) is used by the decoder in order to prevent significant degradation of audio quality. If that is a real scenario, then it becomes more than "a local issue". Perhaps others can comment on the "realness" of this possibility. Charles (Chuck) Hutton Strategic Architecture Engineering Wireless Local Technology Group AT&T Wireless Services PO Box 97059 Redmond, WA 98073 (USPS only) 9461 Willows Road Redmond, WA 98052 (FEDEX/UPS) 425-702-2938 Voice 425-702-2518 FAX charles.hutton(a)attws.com > ---------- > From: Paul Long[SMTP:plong@SMITHMICRO.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, March 01, 2000 10:00 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Errors / ambiguities / problems found in specs at last > week's int erop > > Reinhard, > > I have responded to each of the items you listed. > > - I've wondered myself why there is a separate codepoint for G.729a. From > my > understanding, the use of G.729 or G.729a is a local issue and does not > change the bits on the wire. Maybe we need to state in a future version of > H.323 that they are equivalent with respect to signaling. > > - Are you saying that a GK cannot return a TTL in RCF that is larger than > the TTL in the corresponding RRQ or that it cannot subsequently increase > the > TTL without first having received a lightweight RRQ? I believe that a GK > could return a larger value, but you are correct that there is no way for > it > to update this value without responding to a lightweight RRQ. > > I don't see how the mandatory-parameters issue is related to TTL. > Regardless, this points out a general weakness in semantics for later > additions to H.245 (since H.245v2) and especially H.225.0. IMO, the > description of all SEQUENCE OF and SET OF components should include the > semantics for these situations, even if it is "obvious" to the author what > the semantics should be: > - OPTIONAL component whose encoding is absent > - zero components (empty) > - exactly one component > - more than one component > - component order (we should also use SEQUENCE OF and SET OF where > appropriate) > > We continue to have interoperability problems due to the differing > interpretations as to what these mean. > > - Regarding call reference value, since H.323 is the top-level > Recommendation that references H.225.0, if there is a conflict, H.323 is > always normative. This is true in all referencing relationships between > Recommendations, e.g., between H.225.0 and Q.931. > > - I can't find in H.323 where destinationAddress is required. H.225.0v2 > does > require it, though, "if available" (whatever that means). > > - The audio framing expressed in H.245 is _not_ ambiguous. It is clearly > stated that this is the maximum framing. B.2.2.6/H.245v5: "When an H.225.0 > multiplex is used, these numbers indicate the maximum number of audio > frames > per packet." The problem is that some _implementations_ do not support > variable framing, e.g., some DSPs used in GWs can only process 30ms > frames. > Possible solutions: "fix" decoders so that they support variable framing, > reframe into fixed-size frames before passing along to decoder, add > ability > to express fixed framing in H.245. > > - MCU prefix. I surprisingly have nothing to say about this one. :-) > > - What is a "BE message format?" > > - CRV. Wasn't this already described in a previous item? > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Reinhard Scholl [mailto:Reinhard.Scholl@etsi.fr] > Sent: Wednesday, March 01, 2000 10:34 AM > To: 'h323implementors(a)imtc.org'; 'ITU-SG16(a)MAILBAG.INTEL.COM'; > TIPHON_WG6 > Subject: Errors / ambiguities / problems found in specs at last week's > int erop > > > > The following errors / ambiguities / problems were reported at last > week's > ETSI-TIPHON/IMTC interop event at ETSI: > > > - Terminal capabilities for G.729 and G.729 Annex A. Though mutually > compatible, TCS often fails if vendors only specify support for one or > the other. E.g. 729 <--> 729a should work but TCS fails. > > - H323: GK cannot increase TTL in RCF. Mandatory parameters of type > SEQUENCE OF ... can have empty list. > > - H.225 says that call reference value should be same in ARQ and SETUP. > H.323 says that call reference value should be different in ARQ and > SETUP. > > - In H.323, the destination address in UUIE in SETUP is mandatory, in > H.225.0 it is not. > > - H.245: if a capability being sent includes G.711 "20 msec", the other > side may think that the sender supports both "20 msec" and "10 msec" > rates. But it can be that the originator supports only 20 msec. > Ambiguity. > > - MCU should probably also have "prefix", not just the gateway. > > - Need BE message formats so that packet dumps can be quickly > interpreted. > > - When using a GK, should the CRV in the admission and setup be the > same? > > > Reinhard Scholl > ETSI >

2 1

[Robustness] telecon today! March 1, 2000 at 11AM EST USA
by Maureen Stillman 01 Mar '00

01 Mar '00

This is a reminder that the robustness teleconference will be held today at 11AM EST USA. Please join us. The dial in number is: (613)688-2795 The passcode is: 1235# (you must put in the pound sign) Agenda: 1) Discussion of the Robutness Framework document outline (attached) and 2) Solicit volunteers to fill in text for the outlined sections <<Robustness Framework 01.ZIP>> -- 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

1 0

[sip-h323] H323/SIP Interworking - way forward
by Christian Groves 01 Mar '00

01 Mar '00

G'Day all, The [H.323-SIP/Internet] thread has lead to some interesting discussion. Being personally involved in the H248 "success" and having actually having had to fight through the process of having to work between SG16 and IETF I think there's a few steps that need to be taken before we go into mapping information elements. I believe the first thing we need to do is define what architecture and call scenarios we are working with. H323 has several architectural elements, SIP is not so strong on architecture so we need to show what elements are talking to each other. Only then we can define what interfaces need to be interworked. In H248 this was relatively easy as the interface was between an MGC and MG. The H323-SIP interworking would be another degree of difficulty as there are potentially several interfaces. This architecture work would not slow down the work but would lead to a structured way of working were people agree on a problem space. One of the issues with H248 was that the problem space was not agree on and we went back and forth trying to figure out where we were. As I mentioned at the SG16 I invite people to make contributions on this. Anything more detailed at this stage I believe is counter productive. Even Orit's first proposal I think is too detailed at this stage. Look at the early H248 work where we had many detailed protocols. There was an inordinate amount of work spent (and many late nights) trying to get from details to architecture. Then we had to go back again and define the protocol. The 2nd thing to do is to define the set of capabilities we intend to interwork. This needs to be a clear statement of scope. Interworking basic audio with no conferencing and services is significantly different than interworking full audio, video and data conferencing. In H248 the scope was so large that people were working on completely different things without appreciating the other people's requirements. Thirdly, we must choose our base. What H323version will be interwork with what SIP flavour and functionalities? Of course in today's world there needs to be flexibility to address new functionality but we shouldn't add a new work item every time of version 0 of an internet draft from Joe Bloggs comes out. Fourthly, I believe that once the above is done, then we have a very good idea of what functional interworking work needs to be done. Once we have an idea of the work we can also figure out where the responsibilities would lie. Once we know the work and who is responsible for the work then we MUST make sure this is agreed upon and documented in both the ITU and IETF by the people who can make decisions. Too many things were hidden in the H248 work and people that could make decisions were not at the appropriate meetings. Finally we can then produce the detailed documents in a way that everyone understands. I do think that at the end of the day H.248 was a success and that the co-operation between the IETF and ITU was made to work. This was because of the large amount of work and sacrifices made by a few individuals and companies who wanted to make this happen. Many of the individuals working on H248 will probably contribute on H323/SIP interworking so lets learn from the mistakes and have another go at making H323-SIP interworking work without having to kill ourselves to achieve the goal. Cheers, Christian ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ Shabang!com is the place to get your FREE eStore, Absolutely FREE Forever. If you have any desires to sell your products or services online, or you want to expand your customer base for FREE, Come check out Shabang!com FREE eStores! http://click.egroups.com/1/1299/2/_/302437/_/951907402/ -- Easily schedule meetings and events using the group calendar! -- http://www.egroups.com/cal?listname=sip-h323&m=1

1 0

MAC21 Art Fair 2000
by feria＠MAC21.COM 29 Feb '00

29 Feb '00

M A C 2 1 - 2000 International Contemporary Art Fair Feria Internacional de Arte Contemporáneo =============================================== Contenido: 1 ................. ENGLISH TEXT 2 ................. TEXTO EN ESPAŃOL **************** ENGLISH TEXT **************** You can visit actualized: www.mac21.com with complete information of 3 Edition of MAC21 - International Contemporary Art Fair, that will take place in the Fairs and Congresses Center of Marbella (Spain), from 19 to 23 July, 2000. Galleries, conditions, application, prices,... Moreover, information of the 2 Edition of Art-e-mail, International Exhibition of E-mails of Artists. MAC21 feria(a)mac21.com art-e-mail(a)mac21.com =============================================== We adhere to responsible e-mail ethics if you wish to be "removed" from future mailings, please click on this link mailto: publicidad@mac21.com?subject=REMOVE:itu-sg16@mailbag.cps.intel.com and hit send. =============================================== **************** TEXTO ESPAŃOL **************** Ya puedes visitar actualizada: www.mac21.com con toda la información de la 3 edicion de MAC21-Feria Internacional de Arte Contemporaneo, que se celebrara en el Palacio de Ferias y Congresos de Marbella (Espańa), del 19 al 23 de julio del 2000. Galerías, condiciones, inscripcion, precios,... Además, información de la 2 Edición de Art-e-mail, Exposición Internacional de E-mails de Artistas. MAC21 feria(a)mac21.com art-e-mail(a)mac21.com =============================================== Acogiendonos a la etica de la comunicacion por e-mail, si desea ser "borrado" de futuros envios, por favor pulse el siguiente link mailto: publicidad@mac21.com?subject=BORRAR:itu-sg16@mailbag.cps.intel.com y envie. ===============================================

1 0

Re: [H.323-SIP/Internet] The reason.
by Roy, Radhika R, ALARC 29 Feb '00

29 Feb '00

Hi, Bahman and Orit, I agree with Bahman. Orit, would you please clarify more what do you expect with respect to your proposals 1 and 2? Best regards, Radhika > -----Original Message----- > From: Bahman Mobasser [SMTP:bahman.mobasser@ALCATEL.FR] > Sent: Tuesday, February 29, 2000 11:23 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > Orit- > > In my opinion what would most useful would a restrictive interpretation of > 1, and I will explain: what is needed is the specification of an H.323-SIP > call. Depending on the network configuration assumptions (i.e., what > equipment is between the two end-points), the mapping needs will become > clear. > > On this option I share your point of view- while this may be politically > incorrect, I think inviting everybody to the Picnic does not necessarily > advance things. If one organisation (IETF) has taken the lead in doing > this, > then the best thing to do is to encourage them by taking proposals there. > > 2 confuses me too much and sends, in my opinion, completely the wrong > signals and should be avoided. > > Bahman > > ----------------------------------------------------- > Bahman Mobasser Tel: +33 1 30771608 > Alcatel Mobile: +33 6 12091822 > 10 rue Latécoère Fax: +33 1 30779914 > 78140 Vélizy Voice & Fax Mail: +33 1 5301 0789 > France Roaming email: Bahman(a)Bahman.org > ----------------------------------------------------- > > [[ MAPI 1.0 storage : 4140 in winmail.dat ]] > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com] On Behalf Of Orit Levin > Sent: lundi 28 février 2000 17:25 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > Hello! > I can see two (hardly overlapping) directions to move forward: > (1) H.323 - SIP interworking by mapping/translation > (2) Definition of how H.323 takes use of Internet services being defined > by > IETF > > In the regards to (1), my personal preference would be to leave this work > under the IETF process. I suspect they had a perfect reason being the > first > to start this work. It doesn't mean SG16 shouldn't prevent them from > making > mistakes on H.323 side. > > In regards to (2), I think it has to be addressed by H.323 as a part of > H.323. I would love to see more comments on this (less political) part of > the work. > > In the meanwhile I am putting all the suggestions and alternatives in the > updated paper (which is not attached yet). > 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: Henning Schulzrinne <hgs(a)CS.COLUMBIA.EDU> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > Date: Sunday, February 27, 2000 10:57 PM > Subject: Re: [H.323-SIP/Internet] The reason. > > > >Since my name popped up in a recent email discussion, a few remarks: > > > >1) Yes, the SIP-H.323 list was created by myself; it is open to anybody. > >While its creation was triggered by the interest generated by a proposal > >(Internet draft) written by Kundan Singh (a student of mine) and myself, > >it is open to any discussion related to the topic of interworking. > >(Discussions about the relative merits of protocols are decidedly less > >appreciated.) Whether people use this mailing list or create something > >new and different is obviously beyond my control. > > > >The creation of the mailing list was done without any implied IETF > >endorsement or even endorsement of other SIP authors. (I hope they don't > >mind too much...) > > > >2) In this context, there is one important difference between the ITU > >and IETF standardization process which particularly affects this > >discussion. While all ITU recommendations are "standards", most IETF > >RFCs are not. For the case at hand, it would probably be considered > >inappropriate for a standards-track RFC except, with lots of stretch of > >the imagination, a BCP (best current practice). If an interoperability > >document does get published within the IETF, it is likely to appear as > >an Informational or possibly Experimental RFC. In this particular case, > >as long as the signaling gateway looks like a valid SIP or H.323 entity, > >the other SIP and H.323 entities won't know that it is talking to the > >"other side" (you can insert "dark side" or "the enemy" if you are so > >inclined). > > > >As our initial document points out, there is probably a range of > >solutions that satisfy this basic criterion, depending on (for example) > >to what extent X entities are visible in Y land. > > > >In my view, publishing any such interoperability document has the > >primary benefit of saving implementors of such devices, should they > >become popular, a bit of thinking time and maybe avoid some pitfalls. > >They are not strictly *necessary* - anybody could derive one of the > >modes that we described or something different, as long as it satisfies > >the basic "in Rome, do as the Romans" criterion mentioned earlier. > > > >Thus, given that a standards-track document is not really called for on > >the IETF side, this effort could be significantly simpler than, say, the > >Megaco/H.248 effort. My rough perception is that the IESG will basically > >ask at publication time whether the document suggested as an > >Informational RFC violates IETF protocols (SIP and SDP, in this case). > >If not, and it does no other harm (e.g., broadcasting a RAS-like query > >to all SIP nodes in the Internet or something similarly stupid), the > >IETF process should be relatively straightforward, even without a lot of > >cooperation machinery, liaison agreements and the like. I realize that > >this assessment is probably hopelessly naive, but I am concerned that > >the collective effort expended on meta-discussions is rapidly > >approaching the effort that seems to be necessary to write an > >interoperability document for basic services, including the time to > >implement it. > > > >We'd be happy to provide the infrastructure for meetings, allowing the > >ITU participants to use their H.323 phones to call our SIP phones using > >our gateway implementation :-) No, we won't charge the ITU for these > >translation services :-) > > > >Regards, > > > >Henning

1 0

Re: H.323 Annex D
by Francois Audet 29 Feb '00

29 Feb '00

Paul, do you have a copy of H.245v3? All I can find are v1, v2, v4, v5, v6... -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: Monday, February 28, 2000 9:13 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex D Francois, Actually, I went back to look and we do allow newer versions of H.245 to be used with H.323v2 systems. It was inserted into the H.323 IG in May 1999 and is also in H.323v3. Unfortunately, the text is not as clear as it should be. That's something I will address. You are correct that new additions were made to H.245v6 (as confirmed by Mike Nilsson) to support T.38. I don't recall now what the specific issue were: whether H.245v4 would not work at all or whether the additions were merely improvements. I do remember that at one point, Annex B/T.38 has ASN.1 that differed from H.245-- that was certainly an issue. As far as I know, though, Annex D/H.323 will work with H.245v4. Can anyone else comment? I will seriously consider pulling Annex D into the main document. It makes my life a bit easier, too. However, I suppose it's worth noting which version of H.323 an Annex will work with in general. I have had similar inquiries about Annex E and Annex F. Perhaps a new section in the Implementers Guide is in order to address those issues? Paul ----- Original Message ----- From: Francois Audet <mailto:audet@NORTELNETWORKS.COM> To: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> Sent: Monday, February 28, 2000 12:18 PM Subject: Re: H.323 Annex D By default, I believe that editor would be me. This annex was intended to work with H.323v2 systems and later, but you are correct that there was no way to specify T.38 until H.245v4. Of course, H.323v2 systems used H.245v3. H.323v3 systems used H.245v3 or higher (the key element). So, I suppose the question is: is H.323v3 required? Surely not, as there are implementations out there. We have argued about whether H.323v2 systems could use later versions of H.245. The outcome was "no"-- perhaps that needs to be revisited. Interesting: I tought H.323v2 used H.245v2... Side issue anyways. There have been recent changes to H.245 ASN.1 to support T.38. At least there have been some proposed changes. Unfortunately, I missed much of that discussion. The meeting report says that those changes were added to H.245v6. Mike, is it true that the T.38-related changes from H.245v4 to H.245v6 were nothing more than additions to H.245-- not "changes", per se. Also, did the proposed changes (from TD8/WP2, I believe) make it into H.245v6? My understanding would be that the changes were introduced in H.245v4, but had mistakes that were corrected in H.245v6. As for Annex D, I am considering just pulling that into the H.323 document, rather than keeping it as a separately published annex-- does anybody object to that? That would certainly address questions related to references going forward. However, we need to reach a decision about the current publication. I suspect we need something for the IG, but the problem is that H.323v2 is "old news" now. What to do.... I would support including Annex D in the main H.323v4 document (wich would imply H.245v6). The other alternatives would be to mandate H.323v4/H.245v6 in Annex D. But I prefer the first alternative.

1 0

Re: [H.323-SIP/Internet] The reason.
by Orit Levin 29 Feb '00

29 Feb '00

Hello! I can see two (hardly overlapping) directions to move forward: (1) H.323 - SIP interworking by mapping/translation (2) Definition of how H.323 takes use of Internet services being defined by IETF In the regards to (1), my personal preference would be to leave this work under the IETF process. I suspect they had a perfect reason being the first to start this work. It doesn't mean SG16 shouldn't prevent them from making mistakes on H.323 side. In regards to (2), I think it has to be addressed by H.323 as a part of H.323. I would love to see more comments on this (less political) part of the work. In the meanwhile I am putting all the suggestions and alternatives in the updated paper (which is not attached yet). 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: Henning Schulzrinne <hgs(a)CS.COLUMBIA.EDU> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Sunday, February 27, 2000 10:57 PM Subject: Re: [H.323-SIP/Internet] The reason. >Since my name popped up in a recent email discussion, a few remarks: > >1) Yes, the SIP-H.323 list was created by myself; it is open to anybody. >While its creation was triggered by the interest generated by a proposal >(Internet draft) written by Kundan Singh (a student of mine) and myself, >it is open to any discussion related to the topic of interworking. >(Discussions about the relative merits of protocols are decidedly less >appreciated.) Whether people use this mailing list or create something >new and different is obviously beyond my control. > >The creation of the mailing list was done without any implied IETF >endorsement or even endorsement of other SIP authors. (I hope they don't >mind too much...) > >2) In this context, there is one important difference between the ITU >and IETF standardization process which particularly affects this >discussion. While all ITU recommendations are "standards", most IETF >RFCs are not. For the case at hand, it would probably be considered >inappropriate for a standards-track RFC except, with lots of stretch of >the imagination, a BCP (best current practice). If an interoperability >document does get published within the IETF, it is likely to appear as >an Informational or possibly Experimental RFC. In this particular case, >as long as the signaling gateway looks like a valid SIP or H.323 entity, >the other SIP and H.323 entities won't know that it is talking to the >"other side" (you can insert "dark side" or "the enemy" if you are so >inclined). > >As our initial document points out, there is probably a range of >solutions that satisfy this basic criterion, depending on (for example) >to what extent X entities are visible in Y land. > >In my view, publishing any such interoperability document has the >primary benefit of saving implementors of such devices, should they >become popular, a bit of thinking time and maybe avoid some pitfalls. >They are not strictly *necessary* - anybody could derive one of the >modes that we described or something different, as long as it satisfies >the basic "in Rome, do as the Romans" criterion mentioned earlier. > >Thus, given that a standards-track document is not really called for on >the IETF side, this effort could be significantly simpler than, say, the >Megaco/H.248 effort. My rough perception is that the IESG will basically >ask at publication time whether the document suggested as an >Informational RFC violates IETF protocols (SIP and SDP, in this case). >If not, and it does no other harm (e.g., broadcasting a RAS-like query >to all SIP nodes in the Internet or something similarly stupid), the >IETF process should be relatively straightforward, even without a lot of >cooperation machinery, liaison agreements and the like. I realize that >this assessment is probably hopelessly naive, but I am concerned that >the collective effort expended on meta-discussions is rapidly >approaching the effort that seems to be necessary to write an >interoperability document for basic services, including the time to >implement it. > >We'd be happy to provide the infrastructure for meetings, allowing the >ITU participants to use their H.323 phones to call our SIP phones using >our gateway implementation :-) No, we won't charge the ITU for these >translation services :-) > >Regards, > >Henning

2 1

Re: H.323/SIP interworking mailing list
by Sebestyen Istvan ICN M CS 27 29 Feb '00

29 Feb '00

Many thanks for this, I have looked at the mailing list. I agree that this is an excellent "neutral" forum for discussing further any SIP/H.323 interworking problems. Already some people from TIPHON, IETF; SG16 are partcipating. We have to make it sure that also key "interworking" individuals from IMTC and Softwswitch participate. An additional advantage that I see from this would be a common wisdom on what (if anything) should be done by the standards bodies (as standards), such as IETF, ITU and ETSI, the Interop Specs Groups such as IMTC, ETSI (also here) (as Requirements, Interop Specs, Guidelines....) and the Interoperability Test Groups (such as IMTC and Softswitch). 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: Henning Schulzrinne[SMTP:schulzrinne@CS.COLUMBIA.EDU] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, February 28, 2000 7:28 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.323/SIP interworking mailing list > > It has been pointed out that I forgot to give details about the > interworking mailing list. Here they are: > > I've set a mailing list for those interested in the discussion of > SIP/H.323 interworking. Discussion is *not* limited to the draft written > by Kundan Singh and myself. The list is not moderated, but you have to > be a member to post (to minimize spam). Discussions about the merits of > signaling protocols are considered off-topic. An archive of the > discussion is available at the URL below. > > You can subscribe at http://www.egroups.com/group/sip-h323/ by clicking > on "group info" or by sending email to sip-h323-subscribe(a)egroups.com > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs >

1 0

[H.323Moblility:] Documents uploaded
by Jaakko Sundquist 29 Feb '00

29 Feb '00

Hi all, I have uploaded the documents: H323AnnexDraft03.zip and H323AnnexHTOR.zip to: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/ . The Annex H draft is the output of Geneva meeting (so it does not yet contain the changes based on Mr. Tran's comments) as is the Terms of Reference (which I hope, we do not have to change anymore). - 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. -------------------------------------------------------

1 0

Priorities (RE: [H.323-SIP/Internet] The reason.)
by Michaely, Boaz 29 Feb '00

29 Feb '00

Radhika and all We have a crying need to move forward with H.323, in order to offer value to our customers (such as your company :-). A lot of expert time is being spent on REAL needs such as H.248, robustness, better signalling support, better service control and mobility. It is a question of priorities that each delegate should make on how they best serve their industry. As has always been the case in SG16, if there is a willingness of people to contribute, then the topic advances, otherwise it stalls. (good example is H.246 Annex D). In my humble opinion, it is unfare to ask people like Paul to spend their time here. Let's wait for the interested parties to come up with proposals. For what it's worth, I second Orit's motion on her #2 option. Again - SG16 should be focusing on added value, rather than on added market confusion. Boaz > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Monday, February 28, 2000 6:19 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323-SIP/Internet] The reason. > > > Hi, Everyone: > > I understand what Paul has pointed out. We know that a lot > work needs to be > done when it comes to an agreement between the two standard > organizations: > ITU-T SG16 and IETF. We have seen how other works had been > done in the past > cooperatively despite the difficulty. > > However, there is a crying need in the industry for the H.323-SIP > interoperability standard. We are always optimistic that the > good-will will > always prevail for the benefit of the user community of the > whole world as > these standard organizations are committed to provide > interoperability. > > We not talking about the work for the H.323-SIP > interoperability that is > being done in other forums (e.g., IMTC, ETSI/TIPHON, and > others). These > works will go on and they did in the past, and as they will > be doing now. > > We are working for an internationally acceptable standard > where both ITU-T > and IETF will make it a formal standard. Accordingly, we are > working as per > agreement made in the last SG16 (Feb'00) meeting: To bring > contributions in > the SG16 ( - in Q.14/16 and joint discussions will be held > for both Q.13 and > Q.14). > > It can also been seen that a request has also been sent to > the IETF for a > BOF session in the upcoming meeting (March'00). > > Efforts are underway to overcome all difficulties. I > appreciate Paul to > clarify all aspects of difficulties that we might have to > face for working > in this new area and we are also counting on Paul's support > for our effort > as well. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] > > Sent: Sunday, February 27, 2000 1:15 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > Folks, > > > > I agree that the goal of a standards body is to create > specifications to > > allow interoperability. However, this is "delicate" > territory. This work > > is not similar to creating a new annex to H.246 wherein the > ITU specifies > > interoperability between various systems or protocols > defined elsewhere in > > the ITU. This work involves describing how to interwork an > ITU system > > with > > an IETF RFC. > > > > It's not an impossible task, but one that may lead to > tremendous debate. > > It > > is quite obvious that some members of the ITU and some > members of the IETF > > have very basic philosophical differences. I can tell you that some > > members > > of the IETF will quickly reject anything the ITU does to standardize > > interoperability. I can also tell you that some of those > members will > > also > > reject anything ETSI does, as well. > > > > This is not to say that I am opposed to such an effort-- if > companies > > support the idea, that is enough of an indication to me > that people feel > > it's necessary and should be done. However, if we head > down that path, I > > really believe that this should be a joint effort between > the ITU and the > > IETF. Why? Because there are strengths and weaknesses with both > > protocols > > and one could easily introduce bias into such a > specification in such a > > way > > as to highlight the strengths of one protocol and the > weaknesses of the > > other. > > > > And, of course, everyone here knows that H.323 is far > superior to SIP, > > right? :-) > > > > Again, I do not disagree with the work. However, as sad > and pathetic as > > this statement may sound, it's true: the IETF members > (especially the > > supporters of SIP) have little respect for the ITU and, > unless we do this > > jointly, our lone efforts are likely to not be well received. I've > > already > > heard enough negative remarks about the efforts the ITU is > undertaking > > (especially in SG13) to describe new Internet protocols; > the claims are > > that > > "that is work the IETF does and the ITU has no business doing it". > > > > It has already been suggested that a third party may be the > better choice > > for such a work. Mr. Taylor mentioned that ETSI may > already be doing > > this. > > Did I understand that correctly? If that's the case, and > if we can get > > the > > IETF to agree to allow them to do such work, we should > probably let them > > do > > the work. > > > > Paul > > > > ----- Original Message ----- > > From: "Roy, Radhika R, ALARC" <rrroy(a)ATT.COM> > > To: <ITU-SG16(a)mailbag.cps.intel.com> > > Sent: Friday, February 25, 2000 7:58 AM > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > Hi, Everyone: > > > > > > I am in full agreement with Orit. I guess that this has > also been the > > case > > > for many people who had been present in the SG16 meeting. > > > > > > More importantly, when I talked to Glen, he clearly > indicated that we > > should > > > bring contributions to get the work started. The > interworking between > > H.323 > > > and SIP may belong Q.14 (although it has to be discussed > jointly with > > Q.13 > > > and Q.14). > > > > > > There has been a very strong interest for the work of H.323-SIP > > > Interworking. A large number of people throughout the > world (starting > > from > > > the ITU-T and IETF) is contacting me. > > > > > > The primary goal of the standard bodies is to provide > > "INTEROPERABILITY." > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > +1 732 420 1580 > > > rrroy(a)att.com > > > > > > > -----Original Message----- > > > > From: Orit Levin [SMTP:orit@radvision.com] > > > > Sent: Thursday, February 24, 2000 4:42 PM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > Dear Rob! > > > > Yes, believe me, I read the official report very carefully. > > > > The whole idea is to present "the terms of reference" as a > > contribution > > > > for > > > > Osaka meeting. > > > > I do not see how it prevents to move the work forward, > especially if > > many > > > > people see it as valuable. > > > > > > > > BTW: Who said the work shouldn't be done jointly? My > point was that > > it > > > > may > > > > start from documents and people, rather then from "ITU > and IETF". And > > > > after > > > > all we are NOT talking about joined standard > definition. In worst case > > > > about > > > > joined Network definition. :-)) > > > > > > > > Cheers, > > > > 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: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > > > > To: 'Orit Levin' <orit(a)radvision.com>; > ITU-SG16(a)mailbag.cps.intel.com > > > > <ITU-SG16(a)mailbag.cps.intel.com> > > > > Date: Thursday, February 24, 2000 4:09 PM > > > > Subject: RE: [H.323-SIP/Internet] The reason. > > > > > > > > > > > > Orit, > > > > > > > > This is the statement from the Q.14 meeting report: > > > > > > > > ======= Start > > > > > > > > 3.8.5.1 D.352 - H.323-SIP Interworking [AT&T, et al] > > > > This was presented together with D.413. Comments included: > > > > · Concerns about joint development with IETF > > > > · Which version of SIP would be used? > > > > · Suggest postponing this until the next study period - > need to look > > > > at how Q.13 and Q.14 were formulated 4 years ago and > see how output > > > > compares > > > > with phrasing of work in these questions > > > > · Activities should include comparing call models, > media signaling > > > > · Concerns about increased travel - maybe this should > not be done in > > > > SG16 > > > > · Forming a new question might not be the best answer - > this would > > > > split the expertise in SG16 again (as Q.13 and Q.14 > have moved away > > from > > > > joint sessions) > > > > · Need to work from official process of IETF (i.e., use > only the IETF > > > > equivalent of a Recommendation) > > > > · Consider gatekeepers working with TRIP > > > > Individuals saw merit in the work. Invite contributions > on how to > > approach > > > > the work. Need to get scenarios for progressing work in > a controlled > > > > architectural approach. Ms. Levin has volunteered to draft a > > framework. > > > > See additional notes in Q.13 meeting report. > > > > > > > > ======= End > > > > > > > > This is the statement in the Q.13 report: > > > > > > > > ======= Start > > > > > > > > D.413(2/16) [Canada] - Interworking Between H.323 > and SIP Networks > > > > > > > > This calls for the creation of an interoperability > question in SG16, > > that > > > > would cover among other things, H.323/SIP interworking. > > > > > > > > With regard to both D.352/D.413, it was noted that > there are several > > > > versions of SIP, it is hard to start any work to > interoperate with SIP > > as > > > > SIP is ill-defined at this point in time. The wisdom > of starting a > > new > > > > question near the end of the study period was also > questioned. It was > > > > also > > > > mentioned that a great deal of work needs to be done in terms of > > defining > > > > the procedures and architecture that would apply to > this work. One > > > > suggestion is that interoperability should be between standards > > bodies > > > > such > > > > as the ITU and IETF, and this should be the focus of > the work, i.e. > > that > > > > the > > > > target is official IETF RFCs and not SIP type documents > produced by > > > > various > > > > other bodies. There were various expressions of > support that this > > should > > > > be > > > > studied, and contributions related to architectures and > priorities are > > > > solicited. It was agreed that contributions should > address both Q13 > > and > > > > Q14. > > > > > > > > ======= End > > > > > > > > I cannot see in these statements any thing representing > an agreement > > as > > to > > > > the work to be performed. Your attached terms of > reference were not > > > > approved at the working party, which is required, nor > in the Question > > > > meeting. Without an agreement as to the scope, I do > not see how to > > move > > > > the > > > > work forward, even if many people see it as valuable. > Therefore you > > paper > > > > on > > > > terms of reference can be accepted as a contribution to > the Osaka > > meeting > > > > for discussion. > > > > > > > > I do know that the proposal for a new question was > rejected at the > > > > question > > > > level, and not brought forward to the working party or > study group > > level. > > > > > > > > Talking to Dale, I know that he wants to start the work > with H.225.0 > > Annex > > > > G > > > > to TRIP. Other items are to follow. > > > > > > > > For me one of the problems is the culture clash. I do > not feel that > > the > > > > ITU > > > > should represent itself as SIP experts and I do not > accept any IETF > > person > > > > as an H.323 expert. Therefore the work should be done > jointly. No > > one > > > > wants to repeat the process used by H.248, so what is > the process to > > be > > > > used? > > > > > > > > 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: Orit Levin [mailto:orit@radvision.com] > > > > Sent: Thursday, February 24, 2000 2:27 PM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: [H.323-SIP/Internet] The reason. > > > > > > > > > > > > Hello Sebestyen! > > > > There is additional chapter from Q.14 Report with the > same meaning, > > but > > I > > > > am > > > > sure it doesn't answer your question. During Geneva > meeting additional > > > > related aspects were discussed. In my previous mail I > was referring to > > the > > > > attached paper. (You will find references to relevant > contributions in > > > > this > > > > paper.) Currently this paper is one of the opinions and possible > > > > directions. > > > > We are having this discussion on the list in order to get an > > understanding > > > > of the work we would like to pursue and prepare > contributions for > > Osaka > > > > meeting. > > > > 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: Sebestyen Istvan ICN M CS 27 > <Istvan.Sebestyen(a)icn.siemens.de> > > > > To: ITU-SG16(a)mailbag.cps.intel.com > <ITU-SG16(a)mailbag.cps.intel.com>; > > 'Orit > > > > Levin' <orit(a)radvision.com> > > > > Date: Thursday, February 24, 2000 2:02 PM > > > > Subject: RE: [H.323-SIP/Internet] The reason. > > > > > > > > > > > > >Orit, > > > > >I am a bit confused on what should be done here. I > have only found in > > > > TD-74 > > > > >(ITU-T SG16 Working Party 2 Report) the following passages: > > > > > > > > > >"D.352(2/16) [Various] - H.323 SIP Interworking > > > > > > > > > >This document calls for a joint ITU-T/IETF study of H.323/SIP > > > > interworking. > > > > > > > > > > > > > > >D.413(2/16) [Canada] - Interworking Between H.323 > and SIP Networks > > > > > > > > > >This calls for the creation of an interoperability > question in SG16, > > that > > > > >would cover among other things, H.323/SIP interworking. > > > > > > > > > >With regard to both D.352/D.413, it was noted that > there are several > > > > >versions of SIP, it is hard to start any work to > interoperate with > > SIP > > as > > > > >SIP is ill-defined at this point in time. The wisdom > of starting a > > new > > > > >question near the end of the study period was also > questioned. It > > was > > > > also > > > > >mentioned that a great deal of work needs to be done > in terms of > > defining > > > > >the procedures and architecture that would apply to > this work. One > > > > >suggestion is that interoperability should be between > standards > > bodies > > > > such > > > > >as the ITU and IETF, and this should be the focus of > the work, i.e. > > that > > > > the > > > > >target is official IETF RFCs and not SIP type > documents produced by > > > > various > > > > >other bodies. There were various expressions of > support that this > > should > > > > be > > > > >studied, and contributions related to architectures > and priorities > > are > > > > >solicited. It was agreed that contributions should > address both Q13 > > and > > > > >Q14." > > > > > > > > > >Is there anything else as "Mission Statement" for the > interim work? > > > > > > > > > >Regards, > > > > >Istvan > > > > > > > > > > > > >------------------------------------------------------------- > ------------ > > > > - > > > > >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: Orit Levin[SMTP:orit@radvision.com] > > > > >> Reply To: Orit Levin > > > > >> Sent: Thursday, February 24, 2000 6:53 PM > > > > >> To: ITU-SG16(a)mailbag.cps.intel.com > > > > >> Subject: [H.323-SIP/Internet] The reason. > > > > >> > > > > >> Hi! > > > > >> I would like to highlight the reason of "H.323-XXX" > work in ITU-T > > as > > > > >> described in the initial paper. > > > > >> > > > > >> H.323 is NOT new to Internet. Internet is evolving and new > > > > specifications > > > > >> in "IP telephony" area are being defined in IETF. > This is a time to > > > > >> consider each one of these specifications to be > applied to H.323. > > If > > > > found > > > > >> useful from technical point of view (as a kind of Back End > > Services) > > or > > > > >> just as required for interworking purposes (such as H.323-SIP > > > > scenarios), > > > > >> standard definitions for H.323 should be formulated. > These two are > > > > >> connected since the first definitely helps the second. > > > > >> > > > > >> The written above agenda is a proposal for the work > scope. Based on > > our > > > > >> discussions, it seems like more then one company > would like to see > > this > > > > >> work beyond the topic of H.323-SIP interoperability. > (forget the > > name > > > > :-) > > > > >> ) If we agree that standardization is needed for > this kind of work, > > the > > > > >> only possible way to do it is to participate in > ITU-T process (with > > all > > > > >> its meaning). > > > > >> > > > > >> Currently we are in the beginning of the process > sorting out topics > > of > > > > our > > > > >> interest. I think most of us are aware of the work > being done in > > other > > > > >> organizations. We would like to see experts > (including from TIPHON > > and > > > > >> IETF) presenting their concepts to ITU (starting > from the mailing > > list) > > > > >> keeping us from repeating their work and being > aligned with them. > > > > >> > > > > >> 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 > > > > >> > > > >

1 0

In Defense Of Cooperation
by Tom-PT Taylor 29 Feb '00

29 Feb '00

Paul Jones used the term "H.248/Megaco fiasco", and Dale Skran was quite intemperate in his criticism of the joint effort when he spoke in Geneva. I was not in a position to raise much of a defense there, because it would have conflicted with Glen's positioning of the H.248 work as stable. Now that that issue is water under the bridge, I would like to suggest that it really has been quite a successful project. I don't think we should go at it in quite the same way in the future, but we should not come away totally discouraged about the prospects for IETF/ITU-T cooperation. Here are bases for my conclusion: We have been technically successful, and what we have created is better than it would have been if created in either body separately. To be specific, we retained a great deal of the thinking and experience which went into MGCP, but escaped the limitations MGCP's connection model imposed on the use of different bearer types and multiple media. There is a perception that the IETF decision model is lacking because so much had to be done at the ITU-T meetings. However, the grueling effort put in at the latter resulted partly because of fundamental conflict to which Q.13-14 has been unaccustomed (Monterey and much of Red Bank in particular) and partly because there was so much to cover. This may have given the impression that the IETF didn't do anything on their watch, but we did work through a lot of material. Moreover, both Q. 14/16 and Megaco made a host of decisions which have shaped the final protocol. I have pleaded guilty to a failure to complete IETF process in timely fashion. There was a brief window of opportunity in early December when it seemed that the list was quieting down. If I had made Last Call at that point, the long list of issues which was contributed into the Geneva meeting would instead have been forced into the open at an early enough point that IETF process could still have been completed in time for the Geneva meeting. I consider this to be a tactical failure, in that real work was done in the intervening month and a half, and the protocol specification is the better for it. We have come to a point where SG 16 is thoroughly mistrustful of the IETF as a partner, and has shown this distrust by negotiating a contract for further progress on H.248/Megaco down to the last detail. The pity is that I could see that SG 16 was overly anxious to do its part, from Santiago onwards. We were not really ready for determination at that point, and we were not ready for decision coming out of Red Bank. I can understand that SG 16 feels betrayed because the IETF was not finished in time, but the fact is that the job was bigger than the schedule allowed for. This is why, if I am ever involved in a project like this again, I will insist that the IETF and ITU-T working together create an IETF Proposed Standard before determination ever happens. The opportunity for false expectations and artificially tight deadlines will thus never arise, and both sides will be the happier for it. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

2 1