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

Versions of Annex E
by Paul E. Jones 26 May '00

26 May '00

Folks, There is a copy of Annex E here: ftp://standard.pictel.com/avc-site/9905_San/Annex_E_rev7.1_changes.zip that appears to be newer, but in fact has no official standing. Mr. Okubo's HTML document describes that it was a proposal to the Santiago meeting, but I've seen a couple of people download it without reading the HTML file, believing that it was the current version. Mr. Okubo, is there something we can do to help prevent people from mistaking this for the latest version? Can we modify the timestamp of the file or rename it? Thanks, Paul

3 3

Use of IRR by Gateways
by Mohamed Mustafa 03 Apr '00

03 Apr '00

Hi All, H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages. As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation? Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct? Thanks, Mohamed

5 11

[Robustness] telecon -- April 6 9AM EST USA
by Maureen Stillman 02 Apr '00

02 Apr '00

The next robustness teleconference will be held on Thursday, April 6 at 9AM EST USA. Please send me e-mail at maureen.stillman(a)nokia.com if you plan to attend (some have sent e-mail already). The number to call is: (613)688-2795 the passcode is 8689# You must enter the pound sign after the passcode. The agenda is: * Terry Anderson will provide H.225 and H.245 state machines for us to review. * Randy Stewart and Qiaobing Xie of Motorola will join us to discuss SCTP and DDP and answer questions. * Discuss the SDL for the robustness procedure produced by Sasha Ruditsky of Radvision (attached). This SDL is for the Geneva SG-16 document from the February 2000 meeting, document TD87 from WP2. SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt) DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt -- maureen <<RobustnessSDL.ZIP>> Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

3 2

Missing FastConnectRefused flag in PROGRESS message
by <Karl Klaghofer> 02 Apr '00

02 Apr '00

In the Geneva 2/2000 meeting, we introduced the fastConnectRefused flag into some H.225.0v3 (Imple Guide) and v4 messages. We forgot to put this new field into PROGRESS as well (especially required for GWY interworking). Otherwise, it is difficult to comply with the following statement: ".....fastConnectRefused - A called endpoint should return this element in any message up to and including the Connect message when establishing a call to indicate that it refuses the Fast Connect procedure. ....." Note: The original contribution D.459 from Orit proposed to add this flag to the H323-UU-PDU structure, which would have enabled the flag for PROGRESS as well as for any other message. I guess we changed this in order to only put the flag to the messages where it makes sense (which should be backwards messages) and missed the PROGRESS. I consider this an an error and propose that the editor should add the missing field to PROGRESS to the next updated draft of H.225.0v4 (I assume that no APC is required for Osaka for this ?). Is there a way to correct this also for H.323/H.225.0v3 ? Thanks and Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN SIB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 31 Mar '00

31 Mar '00

Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Friday, March 31, 2000 9:47 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Mob ad hoc group progress Hi Mob group, See the following High Level Progress report. Please inform group of any important aspect that I may have missed. 1. A conference call was held on 23 March 2000 with representatives from: AT&T, Alcatel, Ericsson, Intel, Lucent, Motorola, Nokia, Siemens. 2. The "All H.323 Scenario" was chosen to be studied and specified (out of the many other scenarios presented). When this work has been completed then the other scenarios will be specified. For the chosen scenario, mobility related contributions are now solicited for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release Also it was decided to progress and add to the architectural work as required. These contributions will enhance/form the base-line Annex H text for paragraphs 6, 7 and 8. 3. Next conference call is scheduled for 17 April, again at 8 a.m. PST. 4. It is now a matter of real concern that nothing much has moved in the Annex I (access and lower layer work). Any contributions to kick start this Annex would be appreciated. 5. For H.246 Annex E, it is important that the companies look at the MAP mapping for GSM and ANSI 41 contained in this annex.... to make sure that any errors are identified before the Osaka meeting. Paul

1 0

[Fwd: Summary of Issues Raised On the List]
by Glen Freundlich 31 Mar '00

31 Mar '00

For those interested in H.248, but not subscribed to the Megaco list, I'm forwarding the summary of issues that Tom Taylor distributed to the Megaco list (and to which he referred in his "Megaco Meeting Summary" email). -- 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

1 0

Mob ad hoc group progress
by Guram Paul-LPG019 31 Mar '00

31 Mar '00

Hi Mob group, See the following High Level Progress report. Please inform group of any important aspect that I may have missed. 1. A conference call was held on 23 March 2000 with representatives from: AT&T, Alcatel, Ericsson, Intel, Lucent, Motorola, Nokia, Siemens. 2. The "All H.323 Scenario" was chosen to be studied and specified (out of the many other scenarios presented). When this work has been completed then the other scenarios will be specified. For the chosen scenario, mobility related contributions are now solicited for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release Also it was decided to progress and add to the architectural work as required. These contributions will enhance/form the base-line Annex H text for paragraphs 6, 7 and 8. 3. Next conference call is scheduled for 17 April, again at 8 a.m. PST. 4. It is now a matter of real concern that nothing much has moved in the Annex I (access and lower layer work). Any contributions to kick start this Annex would be appreciated. 5. For H.246 Annex E, it is important that the companies look at the MAP mapping for GSM and ANSI 41 contained in this annex.... to make sure that any errors are identified before the Osaka meeting. Paul

1 0

R:Megaco Meeting Summary
by Tosco Federico 31 Mar '00

31 Mar '00

Tom, Thank you for the information. I take the occasion to thank you again for your very important contribution to the cooperation between IETF and ITU-T. Best regards. Federico > ---------- > Da: Tom-PT Taylor[SMTP:taylor@NORTELNETWORKS.COM] > Risposta a: Mailing list for parties associated with ITU-T Study Group > 16 > Inviato: venerdì 31 marzo 2000 2.37 > A: ITU-SG16(a)MAILBAG.INTEL.COM > Oggetto: Megaco Meeting Summary > > Apologies to Alison -- I don't have her E-mail address. > > Megaco met for one session on Thursday morning. The agenda included a > review of status, a discussion of the future of work on development of > Megaco/H.248, review of work items in progress, and review of potential > new work items. The main points out of the status review were that we > must close on Last Call items within the next week to make the base > protocol documentation available for the April IESG meeting, and that only > MIB development remains out of the original charter work items. > > Discussion of how the IETF wishes to relate to future development of the > Megaco/H.248 protocol brought out the following points: > > -- painful as it has been, we wish to remain fully involved in > development of the base protocol at every stage > -- leaving that aside, it is desirable for interoperability that package > development be coordinated to minimize unnecessary proliferation > > -- there was a strong consensus that in future work, ITU-T determination > of jointly developed documents should truly indicate that these documents > are technically stable, with rigorous change control applied thereafter to > ensure that changes are restricted to clarifications and error > corrections. > > The consensus was therefore that Megaco should continue to operate, though > perhaps at a lower level of activity. It will be necessary to draw up a > new charter for the Working Group, and the Chair has been tasked with > drawing up a process document to form the basis of a permanent agreement > with the ITU groups with whom we cooperate. (This document will be > offered to the list for discussion before being passed to the AD.) It was > noted in later discussion that within the present organization of the > ITU-T we will need to work with Study Group 11 as well as SG 16. > > A first engineer-to-engineer interoperability event is being planned, > tentatively set for August, somewhere in North America. Nortel will set > up an implementor's E-mail list and web site. We welcome any TIPHON > initiative to develop an H.248 PICS. > > Notes on existing work items: > -- the suggestion from discussion was that each package (including those > currently in H.248 Annex E) will be published as a separate RFC. Megaco- > or ITU-initiated packages will typically be standards-track, but this > decision can be made on a per-package basis. > > -- discussion of the IPPhone profile brought out the following points: > Megaco will not initiate the development of profiles, but will typically > become involved as technical consultants in the final stages of turning > mature documents into Informational RFCs. The IPPhone draft itself will > probably be recycled once more in response to list comments, then sent to > WG Last Call, around mid-April. > > -- the NAS package work continues to be a matter both of controversy and > of an apparently low level of general interest. It will be fleshed out to > meet the published Megaco requirements. We are looking to WG Last Call in > mid- to late April. > > -- MIB work has begun to take off. A recycled draft with a substantial > amount of content should be available within the next couple of weeks. We > are looking toward WG Last Call toward the end of the month. It was noted > that each package will probably engender a corresponding MIB. > > A number of potential new work areas were reviewed. These will be > discussed on the list, with a view to identifying specific WG work items > over the next month. > > -- ISDN-related work should be coordinated with Study Group 11 > -- additional packages proposed in draft-brown-supplpkgs-00.txt will be > generic in intent, although in detail some aspects may be specific to > North America. The work should be coordinated with Study Group 16 in > particular, and possibly also Study Group 11. > > Work on adding ATM capability to SDP is in progress. The work is being > taken to MMUSIC (who are prepared to supervise it -- there was a question > of whether they would refer it back to Megaco.) > > A final presentation on the potential application of H.248 to the control > of UMTS terminals included a request for help in development of the > implied call flows. An I-D will be submitted and can be discussed on the > list. > > As a personal note, I cannot guarantee E-mail connectivity over the next > week -- my modem does not seem to agree with most Australian telephone > circuits. I will be back in full operation April 8. > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > >

1 0

Megaco Meeting Summary
by Tom-PT Taylor 30 Mar '00

30 Mar '00

Apologies to Alison -- I don't have her E-mail address. Megaco met for one session on Thursday morning. The agenda included a review of status, a discussion of the future of work on development of Megaco/H.248, review of work items in progress, and review of potential new work items. The main points out of the status review were that we must close on Last Call items within the next week to make the base protocol documentation available for the April IESG meeting, and that only MIB development remains out of the original charter work items. Discussion of how the IETF wishes to relate to future development of the Megaco/H.248 protocol brought out the following points: -- painful as it has been, we wish to remain fully involved in development of the base protocol at every stage -- leaving that aside, it is desirable for interoperability that package development be coordinated to minimize unnecessary proliferation -- there was a strong consensus that in future work, ITU-T determination of jointly developed documents should truly indicate that these documents are technically stable, with rigorous change control applied thereafter to ensure that changes are restricted to clarifications and error corrections. The consensus was therefore that Megaco should continue to operate, though perhaps at a lower level of activity. It will be necessary to draw up a new charter for the Working Group, and the Chair has been tasked with drawing up a process document to form the basis of a permanent agreement with the ITU groups with whom we cooperate. (This document will be offered to the list for discussion before being passed to the AD.) It was noted in later discussion that within the present organization of the ITU-T we will need to work with Study Group 11 as well as SG 16. A first engineer-to-engineer interoperability event is being planned, tentatively set for August, somewhere in North America. Nortel will set up an implementor's E-mail list and web site. We welcome any TIPHON initiative to develop an H.248 PICS. Notes on existing work items: -- the suggestion from discussion was that each package (including those currently in H.248 Annex E) will be published as a separate RFC. Megaco- or ITU-initiated packages will typically be standards-track, but this decision can be made on a per-package basis. -- discussion of the IPPhone profile brought out the following points: Megaco will not initiate the development of profiles, but will typically become involved as technical consultants in the final stages of turning mature documents into Informational RFCs. The IPPhone draft itself will probably be recycled once more in response to list comments, then sent to WG Last Call, around mid-April. -- the NAS package work continues to be a matter both of controversy and of an apparently low level of general interest. It will be fleshed out to meet the published Megaco requirements. We are looking to WG Last Call in mid- to late April. -- MIB work has begun to take off. A recycled draft with a substantial amount of content should be available within the next couple of weeks. We are looking toward WG Last Call toward the end of the month. It was noted that each package will probably engender a corresponding MIB. A number of potential new work areas were reviewed. These will be discussed on the list, with a view to identifying specific WG work items over the next month. -- ISDN-related work should be coordinated with Study Group 11 -- additional packages proposed in draft-brown-supplpkgs-00.txt will be generic in intent, although in detail some aspects may be specific to North America. The work should be coordinated with Study Group 16 in particular, and possibly also Study Group 11. Work on adding ATM capability to SDP is in progress. The work is being taken to MMUSIC (who are prepared to supervise it -- there was a question of whether they would refer it back to Megaco.) A final presentation on the potential application of H.248 to the control of UMTS terminals included a request for help in development of the implied call flows. An I-D will be submitted and can be discussed on the list. As a personal note, I cannot guarantee E-mail connectivity over the next week -- my modem does not seem to agree with most Australian telephone circuits. I will be back in full operation April 8. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Inconsistencies in the H.225.0/Q.931 text??
by Frank Derks 30 Mar '00

30 Mar '00

When reading through the "Q.931 part" of H.225.0, the text for the "Q.931" messages specifies "who" is supposed to send and act on the messages. Strangely enough, these seem to be somewhat inconsisten with each other. From the list below (extracted from H.225.0), some messages are sent by the user (???), some messages are sent by (any???) H.323 entity, some messages are sent by a specific H.323 entity and some messages are sent by "something" unspecified. Alerting: "This message may be sent by the calling user..." Call Proceeding: "This message may be sent by the called user..." Connect: "This message shall be sent by the called entity..." Information: "This message may be sent by an H.323 entity..." Progress: "This message may be sent by an H.323 gateway..." Release Complete: "This message shall be sent by a terminal..." Setup: "This message shall be sent by a calling H.323 entity..." Setup Acknowledge: "This message may be sent by an H.323 entity..." Status: .... Status Inquiry: ... First of all, it is not correct to state that any of the messages are sent by the user. Secondly, according to the definition in H.323, an "H.323 Entity" is: "Any H.323 component, including Terminals, Gateways, Gatekeepers, MCs, MPs, and MCUs". From the definition for Endpoint it follows that only a Terminal, a Gateway an an MCU can call and be called. This seems to somewhat contradict the definition of which messages can be sent by by which "components". I.e. this seems to restrict the components that are allowed to send H.225.0/Q.931 messages to Endpoints. Thirdly, a Release Complete message can only be sent by a terminal. I can not imagine that this is correct. I would imagine that Gateways, MCUs and even Gatekeepers are also allowed to send this message. Is there anyone who can shed some light on the above? Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0