- sg16-avd - lists.packetizer.com

Re: H.323 mobility first draft
by Roy, Radhika R, ALARC 24 Aug '99

24 Aug '99

Ed: Thank you so much for clarifcations! I appreciate. Regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Tuesday, August 24, 1999 10:26 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 mobility first draft > Importance: High > > Dear All, > > Roy statements are correct. The official work of Annex-H has not > been started. There is no official Annex-H document at the present. > > The Terms of reference for H.323 Mobility (TD-34) was included > with the Motorola contribution to provide a check list for other > contributors and comments. Basically, does the Motorola > (Annex-H - User and Service Mobility in H.323) > contribution meet the terms of reference? > > Now, as the editor of the upcoming Annex H. I hope on that in the > upcoming SG16 Q.13 meeting in New Jersey. We can get started > on the official Annex-H, so contributions are needed. > Looking forward for your contributions and comments. > > As for the style of the contribution. I have other editorial > duties in other standards and habits are hard to break. > > > Best Regards, > Ed > > > "Roy, Radhika R, ALARC" wrote: > > > Hi Everyone: > > > > We have received two documents from Edgar Martinez with the following > > titles: > > > > 1. Terms of reference for H.323 Mobility > > 2. Annex-H (User and Service Mobility in H.323) > > > > Let me make very clear that the mobility ad hoc group agreed with the > first > > document (Terms of reference for H.323 Mobility). > > > > Th second document (Annex-H - User and Service Mobility in H.323) had > NOT > > been considered at all. Therefore, this document does NOT reference any > > reference with respect to any agreement in the last Berlin meeting. > > > > It is very confusing because Edgar Martinez has been assigned to play > the > > role of "Editor" of H.323 Annex-H. As such, any document produced as an > > editor should reflect the consensus of the delegates. > > > > I suppose that the second document (Annex-H - User and Service Mobility > in > > H.323) is a contribution from Motorola (NOT as an editor of Annex H) > that > > may be discussed in the upcoming SG16 Q.13 meeting ( New Jersey, USA - > > October 18-22, 1999). > > > > I hope that Edgar will clarify the confusion to all of us. > > > > Best Regards, > > > > Radhika R. Roy > > AT&T > > + 1 732 420 1580 > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Monday, August 23, 1999 3:19 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: H.323 mobility first darft > > > > > > Dear All > > > > > > I have uploaded the first H.323 draft, for user > > > and service mobility based on the terms of reference > > > agreed in the SG16 meeting in Berlin. > > > > > > The focus of the document at the moment is to provide full > > > mobility regards of terminal types, that is either fixed or wireless > > > h.323 terminals. Only using H.323 messages with additional > > > extensions to provide seamless wireless handover and > > > terminal roaming. > > > > > > Anyone can pick-up a copy in following wed sites. > > > > > > http://people.itu.int/~emartine/temp/ > > > or > > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > > > The Filename is h323mob01.zip > > > > > > Comments are welcome. > > > > > > Best Regards, > > > -- > > > Edgar Martinez - Principal Staff Engineer > > > Email mailto:martinze@cig.mot.com > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.323 mobility first draft
by Edgar Martinez [1] 24 Aug '99

24 Aug '99

Dear All, Roy statements are correct. The official work of Annex-H has not been started. There is no official Annex-H document at the present. The Terms of reference for H.323 Mobility (TD-34) was included with the Motorola contribution to provide a check list for other contributors and comments. Basically, does the Motorola (Annex-H - User and Service Mobility in H.323) contribution meet the terms of reference? Now, as the editor of the upcoming Annex H. I hope on that in the upcoming SG16 Q.13 meeting in New Jersey. We can get started on the official Annex-H, so contributions are needed. Looking forward for your contributions and comments. As for the style of the contribution. I have other editorial duties in other standards and habits are hard to break. Best Regards, Ed "Roy, Radhika R, ALARC" wrote: > Hi Everyone: > > We have received two documents from Edgar Martinez with the following > titles: > > 1. Terms of reference for H.323 Mobility > 2. Annex-H (User and Service Mobility in H.323) > > Let me make very clear that the mobility ad hoc group agreed with the first > document (Terms of reference for H.323 Mobility). > > Th second document (Annex-H - User and Service Mobility in H.323) had NOT > been considered at all. Therefore, this document does NOT reference any > reference with respect to any agreement in the last Berlin meeting. > > It is very confusing because Edgar Martinez has been assigned to play the > role of "Editor" of H.323 Annex-H. As such, any document produced as an > editor should reflect the consensus of the delegates. > > I suppose that the second document (Annex-H - User and Service Mobility in > H.323) is a contribution from Motorola (NOT as an editor of Annex H) that > may be discussed in the upcoming SG16 Q.13 meeting ( New Jersey, USA - > October 18-22, 1999). > > I hope that Edgar will clarify the confusion to all of us. > > Best Regards, > > Radhika R. Roy > AT&T > + 1 732 420 1580 > > > -----Original Message----- > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > Sent: Monday, August 23, 1999 3:19 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: H.323 mobility first darft > > > > Dear All > > > > I have uploaded the first H.323 draft, for user > > and service mobility based on the terms of reference > > agreed in the SG16 meeting in Berlin. > > > > The focus of the document at the moment is to provide full > > mobility regards of terminal types, that is either fixed or wireless > > h.323 terminals. Only using H.323 messages with additional > > extensions to provide seamless wireless handover and > > terminal roaming. > > > > Anyone can pick-up a copy in following wed sites. > > > > http://people.itu.int/~emartine/temp/ > > or > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > The Filename is h323mob01.zip > > > > Comments are welcome. > > > > Best Regards, > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.323 mobility first draft
by Roy, Radhika R, ALARC 24 Aug '99

24 Aug '99

Hi Everyone: We have received two documents from Edgar Martinez with the following titles: 1. Terms of reference for H.323 Mobility 2. Annex-H (User and Service Mobility in H.323) Let me make very clear that the mobility ad hoc group agreed with the first document (Terms of reference for H.323 Mobility). Th second document (Annex-H - User and Service Mobility in H.323) had NOT been considered at all. Therefore, this document does NOT reference any reference with respect to any agreement in the last Berlin meeting. It is very confusing because Edgar Martinez has been assigned to play the role of "Editor" of H.323 Annex-H. As such, any document produced as an editor should reflect the consensus of the delegates. I suppose that the second document (Annex-H - User and Service Mobility in H.323) is a contribution from Motorola (NOT as an editor of Annex H) that may be discussed in the upcoming SG16 Q.13 meeting ( New Jersey, USA - October 18-22, 1999). I hope that Edgar will clarify the confusion to all of us. Best Regards, Radhika R. Roy AT&T + 1 732 420 1580 > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Monday, August 23, 1999 3:19 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 mobility first darft > > Dear All > > I have uploaded the first H.323 draft, for user > and service mobility based on the terms of reference > agreed in the SG16 meeting in Berlin. > > The focus of the document at the moment is to provide full > mobility regards of terminal types, that is either fixed or wireless > h.323 terminals. Only using H.323 messages with additional > extensions to provide seamless wireless handover and > terminal roaming. > > Anyone can pick-up a copy in following wed sites. > > http://people.itu.int/~emartine/temp/ > or > ftp://standard.pictel.com/avc-site/Incoming/ > > The Filename is h323mob01.zip > > Comments are welcome. > > Best Regards, > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

interpretation of the callSignalAddress parameter
by Wolfgang Bandow 24 Aug '99

24 Aug '99

Dear Sir or Madam, let me please put a question concerning the H.323/H.225 call signalling and RAS parameters. Going on the assumption that the gatekeeper routed call model is chosen, we would like to know how to interpret "destCallSignalAddress" and "srcCallSignalAddress". We focus on following configuration: endpoint A <-> gatekeeper <-> endpoint B, where endpoint A is the initiator of a call. 1. Is it correct that the CallSignalAddress of the gatekeeper is to be used as the destCallSignalAddress for messages sent from endpoint A or endpoint B? 2. Is it correct that the CallSignalAddress of the gatekeeper is to be used as the srcCallSignalAddress for messages sent from the gatekeeper to endpoint A or endpoint B? 3. Is it correct that the CallSignalAddress of endpoint B is to be used as the srcCallSignalAddress for messages sent from endpoint B to the gatekeeper (e.g. ARQ message) although endpoint B is the called party and not the calling one? Maybe there is a generic definition for "source" and "destination" for multi-station-calls. Thanks a lot in advance for your help. Regards, Wolfgang Bandow

1 0

APC-1644 - Report of the Berlin meeting
by Sakae OKUBO 24 Aug '99

24 Aug '99

Dear Q12-14/16 experts, I have uploaded the followin two files at the ftp site: ftp://standard.pictel.com/avc-site/Incoming/APC-1644a.zip ftp://standard.pictel.com/avc-site/Incoming/APC-1644a_wcm.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1644a.zip http://standard.pictel.com/ftp/avc-site/Incoming/APC-1644a_wcm.zip These update the APC-1644.doc with minor editorial improvements. An exception, though it is still of editorial nature, is addition of Annex 9 (communication to Megaco regarding commenting on the requirements for the MGC protocol). APC-1644a_wcm.zip marks the changes relative to APC-1644.doc. APC-1644a.zip will soon be moved to /9908_Ber directory. APC-1644.zip and APC-1644a_wcm.zip will be removed at that time. You see also APC-1645.zip at the /Incoming directory. This is a liaison from TIPHON to be reviewed at the October Rapporteur meeting. It will be moved to /9910_??? directory (??? will be "New" or something else depending on the meeting place). Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

None
by Sherlock, Stuart 23 Aug '99

23 Aug '99

Same here. Thanks Stuart -----Original Message----- From: Mordy Rothberg [mailto:mordy@NET2PHONE.COM] Sent: Sunday, August 22, 1999 11:36 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: how do you unsubscribe? > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Roy, Radhika R, > ALARC > Sent: Thursday, August 19, 1999 8:31 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: > > > Thanks, > Radhika > > > -----Original Message----- > > From: Jangi, Shrirang [SMTP:sjangi@SONUSNET.COM] > > Sent: Wednesday, August 18, 1999 7:47 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: > > > > "subscribe" >

1 0

H.450.3 call forwarding supplementary services
by vjaiswal＠HSS.HNS.COM 23 Aug '99

23 Aug '99

Hi In H.450.3, call forwarding supplementary services, the response to interrogateDiversionQ.Invoke APDU is defined as follows IntResultList ::= SET SIZE (0..29) OF IntResult IntResult ::= SEQUENCE { servedUserNr EndpointAddress, basicService BasicService, procedure Procedure, divertedToAddress EndpointAddress, remoteEnabled BOOLEAN DEFAULT FALSE, extension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL, ? } I would like to know, why the result has been kept a list of maximum 29 nodes. As far as my understanding goes, a list of 3 nodes would suffice, one node for each service type (CFU/CFB/CFNR). Ane help would be appreciated. Thanks Regards Vivek Jaiswal, Hughes Software Systems

1 0

H.323 mobility first darft
by Edgar Martinez [1] 23 Aug '99

23 Aug '99

Dear All I have uploaded the first H.323 draft, for user and service mobility based on the terms of reference agreed in the SG16 meeting in Berlin. The focus of the document at the moment is to provide full mobility regards of terminal types, that is either fixed or wireless h.323 terminals. Only using H.323 messages with additional extensions to provide seamless wireless handover and terminal roaming. Anyone can pick-up a copy in following wed sites. http://people.itu.int/~emartine/temp/ or ftp://standard.pictel.com/avc-site/Incoming/ The Filename is h323mob01.zip Comments are welcome. Best Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Looking for H.332 products
by Annika Kilegran 23 Aug '99

23 Aug '99

Hello, I'm looking for H.332 products (also Beta versions) to be used for example for internal seminars. Thanks, Annika Kilegran Telia -------------------------------------------------- Annika Kilegran Telia Research AB Phone: +46-8-71382926 Vitsandsgatan 9 B211 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-5904032 Sweden E-mail: Annika.W.Kilegran(a)telia.se --------------------------------------------------

1 0

H.225.0 V3 documents
by Glen Freundlich 22 Aug '99

22 Aug '99

Dear colleagues, I've placed 4 files in the Incoming directory of the ftp site: h225v3.zip - H.225.0 V3 white draft h225v3wcm.zip - V3 white draft showing changes from V2 h225v3b.zip - H.225.0 V3 with changes from Berlin meeting and corrections h225v3bcm.zip - h225v3b showing differences from h225v3 Please let me know as soon as possible if you find any errors. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

2 1

None
by Roy, Radhika R, ALARC 22 Aug '99

22 Aug '99

Thanks, Radhika > -----Original Message----- > From: Jangi, Shrirang [SMTP:sjangi@SONUSNET.COM] > Sent: Wednesday, August 18, 1999 7:47 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: > > "subscribe"

2 1

Re: H.245 CommunicationModeCommand question
by Roni Even 22 Aug '99

22 Aug '99

Yes, but note that if the endpoint receives a multipointconference indication it should wait for the communicationmode command. H.323 8.3.5 has the following statement It is presumed that the CommunicationModeCommand is defining the modes of a conference and is therefore sent after the multipointConference indication which notifies an endpoint that it must comply with the commands of the MC. Endpoints should wait for a CommunicationModeCommand before opening logical channels when they have received a multipointConference indication. ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] > Sent: Friday, August 20, 1999 9:58 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.245 CommunicationModeCommand question > > Yes. > > > pjh wrote: > > > > Hi everyone > > > > in multipoint conference, > > when the terminal joining the conference has received the H.245 > > CommunicationModeCommand from MC, > > Should we open logical channels using the > > OpenLogicalChannel-OpenLogicalChannelAck sequence? > > > > Best Regards > > > > Jihye Park(Miss) > > Nada Research Co., Ltd. > > Seoul 137-070 , Korea > > Tel: 82-2-525-3941 > > Fax: 82-2-525-3945 > > pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr> > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001

1 0

Re: [Fwd: Re: Transport layer interface]
by Brian Rosen 20 Aug '99

20 Aug '99

Since Christian Groves has reflected his latest, here is mine. -----Original Message----- From: Brian Rosen [mailto:brosen@fore.com] Sent: Thursday, August 19, 1999 1:44 PM To: MEGACO(a)standards.nortelnetworks.com Subject: Re: Transport layer interface I work for a company that is pretty well involved with ATM. We have customers who would like to run MGCP directly on ATM, not IP over ATM. While there are no actual proposals, if we were to write one, it would almost certainly be ALF over ATM AAL5. In particular, any effort we put into intelligent handling of congestion by letting the application get in on the decisions of what to send and when to send it is 90% applicable to an ATM transport, and we would be foolish to handle the circumstances another way. If we desire to use something like SSCOP providing reliable, ordered delivery, then the transport would look very much like the TCP transport defined in the draft. It may be that some want to deliver MEGACO over an AAL2 subchannel. Fine, and although congestion using AAL2 (assuming that for other reasons the AAL2 QoS is something like rt-VBR) is not the same, the transport mechanism will very, very likely look like ALF if there is no other layer, or like TCP, if something like SSCOP were used. There would clearly need to be some kind of document that described ATM transport of H.248. That document might originate in the ATM Forum, and subsequently be made part of H.248, or it might be done wholly within ITU. Regardless, it will very likely end up being an annex to the main document, just like Annex C of H.323. While the wording of the annex would clearly be different if the layer wording stayed in the main document, there is NO functional difference with or without it, primarily because the layer is not visible outside either the MG or the MGC. The entire layer exercise is defining the IMPLEMENTATION of the protocol, which is usually considered not to be a good idea in a protocol document. There are lots and lots of instances in the ITU and in the IETF that add things like another transport mechanism to a protocol by either editing the base document, adding an annex, or writing a new spec referencing the old spec with the changes required to achieve the goal. The only thing the layer does is make this process a little less like surgery. What you lose is application flexibility. Defining a layer between protocol and transport does not make defining a non-IP transport any more or any less work, does not alter the observable results, and does not affect the feasibility, document organization etc.! And, I'll point out again, that if we did standardize ALF over ATM AAL5 (or AAL2 for that matter), then the layer mechanism as proposed is entirely inadequate. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Thursday, August 19, 1999 3:36 AM > To: MEGACO(a)standards.nortelnetworks.com > Subject: Re: Transport layer interface > > > G'Day all, > > Seeing my name was mentioned several times I guess I better > speak up on > this issue. There were a number of points: > > 1. A contribution was made to be able to use H.248 across non-IP > transport technologies > 2. The rational is that if you have a gateway with ATM, AAL2 > etc you may > not want an IP signalling transpport. > 3. The layered approach was introduced as a way of doing this. > 4. I recognise that IP is the current and primary means of deploying > H.248 I wanted to document H.248 a way that allows continued developed > of the protocol without having to delay it whilst adding seperate > transport technologies. > 5. We wanted the H.248/Megaco specification NOT to be tied to an IP > transport technology that is why we proposed the changes to > the document > structure to allow the actual protocol (procedures & symantics) to be > separated from the transport issues. > 6. ALF is tied to IP and is not suitable to other transport > technologies > this I think is reflected in the specification > 7. I think it was agreed in the Berlin meeting (the italics > section) of > the document that ALF and TCP transport sections should be > re-written to > make them sound like a protocol document rather than a > educational peice > of writing. We suggested some headings. > 8. We made no attempt to change the technical parts of the ALF and TCP > sections the changes we proposed were to aid clarity. > 9. I was not at the Oslo meeting however I understand that there was > still discussion of the transport issues after this meeting as the > outcome was not clear. > 10. If we don't do this then another device control protocol will be > defined for ATM based MGs and we'll end up with the situation where we > have 2 procedurally and symantically different media gateway control > protocols. This will cost. Its better to have to have the > same protocol. > > Therefore I feel strongly that the sections regarding non-IP transport > should remain. > Hopefully I've captured most of the points from this thread. > > Cheers, Christian > > > Brian Rosen wrote: > > > > I'll point out again that the layer is not appropriate for > > ALF under non IP transport. So it would have to be something like: > > > > "The following section illustrates a possible way to define > the interface > > between the protocol implementation and a non-IP > > transport where Application Level Framing does not need to > > interact with the order messages are actually sent. This > > section is informative and implementations need not follow it" > > > > Given that, it has no business taking up space in the document. > > > > Brian > > > > > -----Original Message----- > > > From: Hong Liu [mailto:lhong@RESEARCH.TELCORDIA.COM] > > > Sent: Thursday, August 19, 1999 10:26 AM > > > To: MEGACO(a)standards.nortelnetworks.com > > > Subject: Re: Transport layer interface > > > > > > > > > Rex, > > > > > > I think what Tom meant by "consensus" was from all the > > > participants in the Oslo > > > meeting. In that sense, it was a consensus from that meeting. > > > Of course, > > > Christian Grove was not in that meeting, and his contribution > > > in Berlin reflects > > > a different opinion in this topic. > > > > > > I remember that the transport issue was indeed discussed in > > > Berlin around 4:00am. > > > Instead of debating the pros and cons then, the group decided > > > to just put the > > > text in for further discussion on the list. In other words, > > > the intent was not to > > > reflect any agreement reached in Berlin, rather it was to > > > capture the issue. > > > Maybe Nancy or John can comment on this. > > > > > > Chip made the point a number of times in the meeting that the > > > proposed sublayer, > > > if added, shall be put in a separate session for "non-IP" > > > transport. I think this > > > is a reasonable proposal for compromise. It seems to me that > > > this is also what > > > the many people think from the emails I read along this thread. > > > > > > --Hong > > > > > > Rex Coldren wrote: > > > > > > > Tom, > > > > The one thing you would see that indicates that Oslo > > > didn't capture > > > > consensus is the proposal from Christian Groves and the > reaction to > > > > it in Berlin. The discussion went on for a while. > > > Unfortunately I don't > > > > remember the exact outcome. Working all night tends to > blur things. > > > > Perhaps Christian can summarize for us what was agreed or wasn't > > > > agreed to at that meeting before we kill the idea on the list. > > > > > > > > Rex > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > I kind of agree that this one is surplus to requirements. > > > It's main point > > > > > would be to provide a hook for transport evolution (e.g. > > > to Sigtran), if we > > > > > saw that in our future, but we should probably let the > > > future take care of > > > > > itself. This was an issue over which we took > > > considerable pains at Oslo, > > > > > and I haven't seen anything on the list to make me think > > > Oslo failed to > > > > > capture consensus. > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [SMTP:brosen@ENG.FORE.COM] > > > > > > Sent: Wednesday, August 18, 1999 5:51 PM > > > > > > To: megaco(a)standards.nortelnetworks.com > > > > > > Subject: Transport layer interface > > > > > > > > > > > > Berlin inserted a concept that was discussed and discarded > > > > > > in the IETF process; defining a transport > independent interface > > > > > > to the transport layer. The layer defines a set of > primitives > > > > > > to be used between the protocol implementation and > any transport > > > > > > layer. The goal is to maximize interoperability, > and to permit > > > > > > transport over non-IP networks. > > > > > > > > > > > > One of the major benefits of ALF is that it allows the > > > application > > > > > > to make dynamic decisions on sending of messages in > the face of > > > > > > congestion. You could, for example, queue a > message, discover > > > > > > there was congestion, and decide to send > > > > > > another message before the enqueued message. You could even > > > > > > decide to not send the message at all. The application > > > > > > may make these decisions. Layered interfaces that only have > > > > > > simple "transfer" primitives cannot provide this kind of > > > > > > reaction to congestion. > > > > > > > > > > > > For that reason, I question an attempt to provide a > transport > > > > > > independent layer. The current wording is not > sufficient, as > > > > > > the comments point out, and there are no submissions that > > > > > > would get us to a complete description. > > > > > > > > > > > > The sections on transport using ALF and transport using TCP > > > > > > are, I think, satisfactory without the extra layer. Any > > > > > > additional transports, IP based or not, could be defined in > > > > > > subsequent editions, or in separate documents > without a layer > > > > > > definition. Since there is not any claimed desire > to be able to > > > > > > have a literal "plug this protocol code into that > > > transport code", > > > > > > I don't think we will miss it. > > > > > > > > > > > > > > > > > > What to do? > > > > > > > > > > > > Brian > > > > > > ------------ > > > > > > Brian Rosen, Principal Engineer > > > > > > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > > > > > > (724) 742-6826 mailto:brosen@eng.fore.com > > > >

1 0

Syntax of AND/OR construct in "Native" remote/local descriptors i n H.248
by Brian Rosen 20 Aug '99

20 Aug '99

In Berlin, a proposal from Lucent, et. al. was largely adopted that created a "native" encoding of media descriptors, as an alternative to SDP, and instead of a straight H.245 encoding. This has been accepted by the IETF group. In the original proposal, constructs to describe alternative and simultaneous capabilities was discussed. The resulting TD from Berlin includes much of the concepts brought up in the proposal, including >, <, range, and QuantityOf, but does not have any reference to alternative and simultaneous. I need some of the people who were in this part of the Berlin discussion to tell me what was decided about AND/OR, and what the syntax should be. My usual sources (Paul Sijben and John Segers) are not available at the moment. Brian

1 0

H.245 CommunicationModeCommand question
by pjh 20 Aug '99

20 Aug '99

Hi everyone in multipoint conference, when the terminal joining the conference has received the H.245 CommunicationModeCommand from MC, Should we open logical channels using the OpenLogicalChannel-OpenLogicalChannelAck sequence? Best Regards Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr>

2 1

Re: Transport layer interface
by Christian Groves 20 Aug '99

20 Aug '99

Hello Roy, I don't think the issue is that a complete protocol proposal is needed. In the ITU there are many instances where a protocol is designed and place holders are left for further study. It shows that the issue was explored but for time reasons it was not developed. I would not like to confuse issues by adding detailed transport sections for AAL1, AAL2 at this stage because it will delay the protocol. IP is what is being developed today but we should allow for future additions. Cheers, Christian "Roy, Radhika R, ALARC" wrote: > > Folks: > > I had also a brief discussion with Christian Groves in Berlin related to his > high level contribution. His proposal has some merits. However, I requested > him to provide a complete proposal (Christian can elaborate on this) how the > actual protocol (procedures & semantics) can be separated from the > transport. > > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > > Sent: Thursday, August 19, 1999 3:36 AM > > To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Transport layer interface > > > > G'Day all, > > > > Seeing my name was mentioned several times I guess I better speak up on > > this issue. There were a number of points: > > > > 1. A contribution was made to be able to use H.248 across non-IP > > transport technologies > > 2. The rational is that if you have a gateway with ATM, AAL2 etc you may > > not want an IP signalling transpport. > > 3. The layered approach was introduced as a way of doing this. > > 4. I recognise that IP is the current and primary means of deploying > > H.248 I wanted to document H.248 a way that allows continued developed > > of the protocol without having to delay it whilst adding seperate > > transport technologies. > > 5. We wanted the H.248/Megaco specification NOT to be tied to an IP > > transport technology that is why we proposed the changes to the document > > structure to allow the actual protocol (procedures & symantics) to be > > separated from the transport issues. > > 6. ALF is tied to IP and is not suitable to other transport technologies > > this I think is reflected in the specification > > 7. I think it was agreed in the Berlin meeting (the italics section) of > > the document that ALF and TCP transport sections should be re-written to > > make them sound like a protocol document rather than a educational peice > > of writing. We suggested some headings. > > 8. We made no attempt to change the technical parts of the ALF and TCP > > sections the changes we proposed were to aid clarity. > > 9. I was not at the Oslo meeting however I understand that there was > > still discussion of the transport issues after this meeting as the > > outcome was not clear. > > 10. If we don't do this then another device control protocol will be > > defined for ATM based MGs and we'll end up with the situation where we > > have 2 procedurally and symantically different media gateway control > > protocols. This will cost. Its better to have to have the same protocol. > > > > Therefore I feel strongly that the sections regarding non-IP transport > > should remain. > > Hopefully I've captured most of the points from this thread. > > > > Cheers, Christian > > > > > > Brian Rosen wrote: > > > > > > I'll point out again that the layer is not appropriate for > > > ALF under non IP transport. So it would have to be something like: > > > > > > "The following section illustrates a possible way to define the > > interface > > > between the protocol implementation and a non-IP > > > transport where Application Level Framing does not need to > > > interact with the order messages are actually sent. This > > > section is informative and implementations need not follow it" > > > > > > Given that, it has no business taking up space in the document. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Hong Liu [mailto:lhong@RESEARCH.TELCORDIA.COM] > > > > Sent: Thursday, August 19, 1999 10:26 AM > > > > To: MEGACO(a)standards.nortelnetworks.com > > > > Subject: Re: Transport layer interface > > > > > > > > > > > > Rex, > > > > > > > > I think what Tom meant by "consensus" was from all the > > > > participants in the Oslo > > > > meeting. In that sense, it was a consensus from that meeting. > > > > Of course, > > > > Christian Grove was not in that meeting, and his contribution > > > > in Berlin reflects > > > > a different opinion in this topic. > > > > > > > > I remember that the transport issue was indeed discussed in > > > > Berlin around 4:00am. > > > > Instead of debating the pros and cons then, the group decided > > > > to just put the > > > > text in for further discussion on the list. In other words, > > > > the intent was not to > > > > reflect any agreement reached in Berlin, rather it was to > > > > capture the issue. > > > > Maybe Nancy or John can comment on this. > > > > > > > > Chip made the point a number of times in the meeting that the > > > > proposed sublayer, > > > > if added, shall be put in a separate session for "non-IP" > > > > transport. I think this > > > > is a reasonable proposal for compromise. It seems to me that > > > > this is also what > > > > the many people think from the emails I read along this thread. > > > > > > > > --Hong > > > > > > > > Rex Coldren wrote: > > > > > > > > > Tom, > > > > > The one thing you would see that indicates that Oslo > > > > didn't capture > > > > > consensus is the proposal from Christian Groves and the reaction to > > > > > it in Berlin. The discussion went on for a while. > > > > Unfortunately I don't > > > > > remember the exact outcome. Working all night tends to blur things. > > > > > Perhaps Christian can summarize for us what was agreed or wasn't > > > > > agreed to at that meeting before we kill the idea on the list. > > > > > > > > > > Rex > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > I kind of agree that this one is surplus to requirements. > > > > It's main point > > > > > > would be to provide a hook for transport evolution (e.g. > > > > to Sigtran), if we > > > > > > saw that in our future, but we should probably let the > > > > future take care of > > > > > > itself. This was an issue over which we took > > > > considerable pains at Oslo, > > > > > > and I haven't seen anything on the list to make me think > > > > Oslo failed to > > > > > > capture consensus. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [SMTP:brosen@ENG.FORE.COM] > > > > > > > Sent: Wednesday, August 18, 1999 5:51 PM > > > > > > > To: megaco(a)standards.nortelnetworks.com > > > > > > > Subject: Transport layer interface > > > > > > > > > > > > > > Berlin inserted a concept that was discussed and discarded > > > > > > > in the IETF process; defining a transport independent interface > > > > > > > to the transport layer. The layer defines a set of primitives > > > > > > > to be used between the protocol implementation and any transport > > > > > > > layer. The goal is to maximize interoperability, and to permit > > > > > > > transport over non-IP networks. > > > > > > > > > > > > > > One of the major benefits of ALF is that it allows the > > > > application > > > > > > > to make dynamic decisions on sending of messages in the face of > > > > > > > congestion. You could, for example, queue a message, discover > > > > > > > there was congestion, and decide to send > > > > > > > another message before the enqueued message. You could even > > > > > > > decide to not send the message at all. The application > > > > > > > may make these decisions. Layered interfaces that only have > > > > > > > simple "transfer" primitives cannot provide this kind of > > > > > > > reaction to congestion. > > > > > > > > > > > > > > For that reason, I question an attempt to provide a transport > > > > > > > independent layer. The current wording is not sufficient, as > > > > > > > the comments point out, and there are no submissions that > > > > > > > would get us to a complete description. > > > > > > > > > > > > > > The sections on transport using ALF and transport using TCP > > > > > > > are, I think, satisfactory without the extra layer. Any > > > > > > > additional transports, IP based or not, could be defined in > > > > > > > subsequent editions, or in separate documents without a layer > > > > > > > definition. Since there is not any claimed desire to be able to > > > > > > > have a literal "plug this protocol code into that > > > > transport code", > > > > > > > I don't think we will miss it. > > > > > > > > > > > > > > > > > > > > > What to do? > > > > > > > > > > > > > > Brian > > > > > > > ------------ > > > > > > > Brian Rosen, Principal Engineer > > > > > > > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > > > > > > > (724) 742-6826 mailto:brosen@eng.fore.com > > > >

1 0

[Fwd: Re: Transport layer interface]
by Christian Groves 20 Aug '99

20 Aug '99

Hello, For those interested there are some discussions on the IETF Megaco list about removing/modifying the sections added in Berlin in H.248 on non-IP signalling transport. My response is below. Cheers, Christian -------- Original Message -------- Subject: Re: Transport layer interface Date: Thu, 19 Aug 1999 17:36:13 +1000 From: Christian Groves <Christian.Groves(a)ERICSSON.COM> Reply-To: Christian Groves <Christian.Groves(a)ERICSSON.COM> To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM References: <21565C751365D211BB2D0060089624CC112B65@TERRA> G'Day all, Seeing my name was mentioned several times I guess I better speak up on this issue. There were a number of points: 1. A contribution was made to be able to use H.248 across non-IP transport technologies 2. The rational is that if you have a gateway with ATM, AAL2 etc you may not want an IP signalling transpport. 3. The layered approach was introduced as a way of doing this. 4. I recognise that IP is the current and primary means of deploying H.248 I wanted to document H.248 a way that allows continued developed of the protocol without having to delay it whilst adding seperate transport technologies. 5. We wanted the H.248/Megaco specification NOT to be tied to an IP transport technology that is why we proposed the changes to the document structure to allow the actual protocol (procedures & symantics) to be separated from the transport issues. 6. ALF is tied to IP and is not suitable to other transport technologies this I think is reflected in the specification 7. I think it was agreed in the Berlin meeting (the italics section) of the document that ALF and TCP transport sections should be re-written to make them sound like a protocol document rather than a educational peice of writing. We suggested some headings. 8. We made no attempt to change the technical parts of the ALF and TCP sections the changes we proposed were to aid clarity. 9. I was not at the Oslo meeting however I understand that there was still discussion of the transport issues after this meeting as the outcome was not clear. 10. If we don't do this then another device control protocol will be defined for ATM based MGs and we'll end up with the situation where we have 2 procedurally and symantically different media gateway control protocols. This will cost. Its better to have to have the same protocol. Therefore I feel strongly that the sections regarding non-IP transport should remain. Hopefully I've captured most of the points from this thread. Cheers, Christian Brian Rosen wrote: > > I'll point out again that the layer is not appropriate for > ALF under non IP transport. So it would have to be something like: > > "The following section illustrates a possible way to define the interface > between the protocol implementation and a non-IP > transport where Application Level Framing does not need to > interact with the order messages are actually sent. This > section is informative and implementations need not follow it" > > Given that, it has no business taking up space in the document. > > Brian > > > -----Original Message----- > > From: Hong Liu [mailto:lhong@RESEARCH.TELCORDIA.COM] > > Sent: Thursday, August 19, 1999 10:26 AM > > To: MEGACO(a)standards.nortelnetworks.com > > Subject: Re: Transport layer interface > > > > > > Rex, > > > > I think what Tom meant by "consensus" was from all the > > participants in the Oslo > > meeting. In that sense, it was a consensus from that meeting. > > Of course, > > Christian Grove was not in that meeting, and his contribution > > in Berlin reflects > > a different opinion in this topic. > > > > I remember that the transport issue was indeed discussed in > > Berlin around 4:00am. > > Instead of debating the pros and cons then, the group decided > > to just put the > > text in for further discussion on the list. In other words, > > the intent was not to > > reflect any agreement reached in Berlin, rather it was to > > capture the issue. > > Maybe Nancy or John can comment on this. > > > > Chip made the point a number of times in the meeting that the > > proposed sublayer, > > if added, shall be put in a separate session for "non-IP" > > transport. I think this > > is a reasonable proposal for compromise. It seems to me that > > this is also what > > the many people think from the emails I read along this thread. > > > > --Hong > > > > Rex Coldren wrote: > > > > > Tom, > > > The one thing you would see that indicates that Oslo > > didn't capture > > > consensus is the proposal from Christian Groves and the reaction to > > > it in Berlin. The discussion went on for a while. > > Unfortunately I don't > > > remember the exact outcome. Working all night tends to blur things. > > > Perhaps Christian can summarize for us what was agreed or wasn't > > > agreed to at that meeting before we kill the idea on the list. > > > > > > Rex > > > > > > Tom-PT Taylor wrote: > > > > > > > I kind of agree that this one is surplus to requirements. > > It's main point > > > > would be to provide a hook for transport evolution (e.g. > > to Sigtran), if we > > > > saw that in our future, but we should probably let the > > future take care of > > > > itself. This was an issue over which we took > > considerable pains at Oslo, > > > > and I haven't seen anything on the list to make me think > > Oslo failed to > > > > capture consensus. > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [SMTP:brosen@ENG.FORE.COM] > > > > > Sent: Wednesday, August 18, 1999 5:51 PM > > > > > To: megaco(a)standards.nortelnetworks.com > > > > > Subject: Transport layer interface > > > > > > > > > > Berlin inserted a concept that was discussed and discarded > > > > > in the IETF process; defining a transport independent interface > > > > > to the transport layer. The layer defines a set of primitives > > > > > to be used between the protocol implementation and any transport > > > > > layer. The goal is to maximize interoperability, and to permit > > > > > transport over non-IP networks. > > > > > > > > > > One of the major benefits of ALF is that it allows the > > application > > > > > to make dynamic decisions on sending of messages in the face of > > > > > congestion. You could, for example, queue a message, discover > > > > > there was congestion, and decide to send > > > > > another message before the enqueued message. You could even > > > > > decide to not send the message at all. The application > > > > > may make these decisions. Layered interfaces that only have > > > > > simple "transfer" primitives cannot provide this kind of > > > > > reaction to congestion. > > > > > > > > > > For that reason, I question an attempt to provide a transport > > > > > independent layer. The current wording is not sufficient, as > > > > > the comments point out, and there are no submissions that > > > > > would get us to a complete description. > > > > > > > > > > The sections on transport using ALF and transport using TCP > > > > > are, I think, satisfactory without the extra layer. Any > > > > > additional transports, IP based or not, could be defined in > > > > > subsequent editions, or in separate documents without a layer > > > > > definition. Since there is not any claimed desire to be able to > > > > > have a literal "plug this protocol code into that > > transport code", > > > > > I don't think we will miss it. > > > > > > > > > > > > > > > What to do? > > > > > > > > > > Brian > > > > > ------------ > > > > > Brian Rosen, Principal Engineer > > > > > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > > > > > (724) 742-6826 mailto:brosen@eng.fore.com > >

1 0

H.245 CommunicationModeCommand question
by pjh 19 Aug '99

19 Aug '99

Hi everyone in multipoint conference, when the terminal joining the conference has received the H.245 CommunicationModeCommand from MC, Should we open logical channels using the OpenLogicalChannel-OpenLogicalChannelAck sequence? Best Regards Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr>

1 0

H.245 CommunicationModeCommand question
by pjh 19 Aug '99

19 Aug '99

Hi everyone in multipoint conference, when the terminal joining the conference has received the H.245 CommunicationModeCommand from MC, Should we open logical channels using the OpenLogicalChannel-OpenLogicalChannelAck sequence? Best Regards Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr>

1 0

None
by Jangi, Shrirang 18 Aug '99

18 Aug '99

"subscribe"

1 0

From H.245 tunneling to separate connection?
by Paul Long 17 Aug '99

17 Aug '99

Why would an EP ever want to switch from H.245 tunneling to a separate H.245 connection? What possible use could there be in such a thing? Paul Long Smith Micro Software, Inc.

3 2

CallId/ConfId in LRQ
by Manoj Paul 16 Aug '99

16 Aug '99

Hi, Presently, when a GK needs to resolve some aliasaddress, it sends LRQ to another GK which has a co-located Border Element (BE). This BE may need to generate an Access Request (according to H.225 Annex G), to another BE. It might be mandatory for the requesting BE to include callInformation (callId/ConfId) in this Access Request (depending on the address template it holds). But LRQ message does not have a callId field in it. How can the requesting BE then derive callInformation for Access Request message? Any help will be appreciated. regards Manoj.

2 1

CallId/ConfId in LRQ.
by Manoj Paul 16 Aug '99

16 Aug '99

Hi, Presently, when a GK needs to resolve some aliasaddress, it sends LRQ to another GK which has a co-located Border Element (BE). This BE may need to generate an Access Request (according to H.225 Annex G), to another BE. It might be mandatory for the requesting BE to include callInformation (callId/ConfId) in this Access Request (depending on the address template it holds). But LRQ message does not have a callId field in it. How can the requesting BE then derive callInformation for Access Request message? Any help will be appreciated. regards Manoj.

1 0

Re: RTP question!!
by Aparna Saha 13 Aug '99

13 Aug '99

Hello Deepak, RTP states that in case a source changes its source transport address, it must also choose a new SSRC identifier . ( Refer to the last line of the description of SSRC as a field of the RTP Header. Section A.5.1, H.225 ). Hence, no SSRC collision will be registered. After changing the DSP (also resulting in change of IP address - assuming that it is associated with a different NIC), the source transport address as well as the SSRC changes as a result of which the receiver perceives this participant to be a new member in the session. Due to the soft-state approach of RTP, the information about the old transport address and the old SSRC would be removed subsequently (as it would no longer register any activity). If the application requires a correlation between the new SSRC and the older one, the same can be achieved through the CNAME item. The CNAME item in the RTCP packets generated would be the same for both the sources. However, as one cannot wait for an RTCP packet to arrive to correlate, this is not fool-proof. The above scenario is also the one seen in IPv6 mobility, wherein the IP address of the sender changes. Regards, Aparna. Deepak Jaiswal <djai(a)sasi.com> on 08/13/99 12:15:14 PM Please respond to Deepak Jaiswal <djai(a)sasi.com> To: rakeshj(a)wipinfo.soft.net (rakesh jain) cc: vittaln(a)agcs.com, h323implementors(a)imtc.org (bcc: Aparna Saha/HSS) Subject: Re: RTP question!! > Deepak, > Hi. > If after changing DSP you are sending RTP/RTCP packets from new > IP address that is IP address of new card, than i think, at > receiver end it will be source conflict, because IP adress is > different than the Old one. As a result the packets from the > new card will be discarded. > Pls let me know, if I am wrong. > rakesh Hello Rakesh, You need to open a multicast channel where in a receiver can recieve packets from multiple sources. With Regards, -- Deepak Jaiswal Multimedia Codecs Group djai(a)sasi.com Silicon Automation Systems Ltd. http://www.sasi.com #5, Corporation Division #67, HAL 3rd Stage, Tel: +91-80-5281461 x4115 Jeevan Bhima Nagar, Bangalore 560 075, India. Fax: +91-80-5276125 ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

2 1

H.248 proposed changes being discussed
by Nancy-M Greene 12 Aug '99

12 Aug '99

Based on the msg I sent out after Berlin entitled "Results from the ITU SG16 Berlin mtg", I have just sent out a series of msgs to the megaco list proposing actual edits to Megaco/H.248 to incorporate the changes suggested in Berlin. If you would like to be a part of this discussion, it would be a good idea to join the megaco mailing list. If you would just like to see what is being discussed, you can go to the Megaco archive at http://standards.nortelnetworks.com. I don't think this should be seen as "going back on what was decided on in Berlin". On the contrary, I see it as a way to make progress in a public forum so that we have a complete and reviewed Megaco/H.248 protocol by October. In any case the discussion on the Megaco mailing list does not preclude any contributions being brought into the October meeting. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0