March 2000 - sg16-avd - lists.packetizer.com

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

03 Mar '00

Hi, Christian, Orit, and Bahman: I guess that Orit will put together all the items in the TOR document. Once we agree on the plan, I believe that work will proceed accordingly. We will discuss each item when one brings contributions. We will definitely be able to keep our work progressed according to the TOR document based on our consensus. I believe that we can make it. First, let us agree on TOR. Best regards, Radhika R. Roy AT&T +1 732 420 1580 > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Thursday, March 02, 2000 5:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323-SIP/Internet] The reason. > > G'Day Orit and Bahman, > > Thanks for your support on the proposal. I don't mind this being added > as proposed work method. I think now the task is to start defining step > 1 which I believe is discussed at the moment. I think the challenge will > be to keep people working as per the work plan. > > Cheers, Christian > > Orit Levin wrote: > > > > 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 > > >

1 0

Re: Multiple phone on the same node
by Hans Viens 03 Mar '00

03 Mar '00

Hi Chris, if I understand (please, correct me if I'm wrong) I have to make 4 RRQ to specify the gatekeeper the Enpoint type of each port I have ? i.e. 1. RRQ -> EndpointType=Terminal; 2. RRQ -> EndpointType=Terminal; 3. RRQ -> EndpointType=Terminal; 3. RRQ -> EndpointType=Gateway; I other work I make 4 RRQ with the Enpoint type ? Best regards, Hans > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Friday, March 03, 2000 4:25 AM > To: hviens(a)mediatrix.com > Cc: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Multiple phone on the same node > > > Hans, > > It is perfectly possible to register a single H.323 device > with multiple > functionalities. To put this another way, EndpointType, > which is an element of > RRQ, is a SEQUENCE. > > Chris > > Hans Viens wrote: > > > > 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 > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 >

2 1

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