- sg16-avd - lists.packetizer.com

[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

Re: [Mobility]:Ideas from phone conference on scenarios
by Roy, Radhika R, ALARC 29 Mar '00

29 Mar '00

Hi, Steve: You are right that the situation will look like scenarios you have proposed in this email. We would appreciate any Ericsoon's proposals regarding this. It has been long overdue to have something from Ericsson's. We also discussed this in the SG 16 in Feb'00 and got assurances from Ericsson they would bring some contributions. Yet, it is NOT too late. (by the way AT&T contributions also provided many of those scenarios). Please note that a domain consists of a single or more zones. A zone may have many networks (e.g., IP network addresses). A mobile entity may have its home and foreign network in its home zone as well. >From the conference call, it was clear that we may focus our discussion with a very simple case first. If anyone else has any thoughts, please, like Steve, let us know. We appreciate Steve's inputs. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group -----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] Sent: Thursday, March 23, 2000 3:01 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Mobility]:Ideas from phone conference on scenarios Hi All, After the phone conference today, I think that we need to cover the following for the "All-H.323 Scenario). A(home) -> B(home), A & B from same domain A(home) -> B(home), A & B from different domain A(home) -> B(roaming), A & B from same domain A(home) -> B(roaming), A & B from different domain A(roaming) -> B(home), A & B from same domain A(roaming) -> B(home), A & B from different domain A(roaming) -> B(roaming), A & B from same domain A(roaming) -> B(roaming), A & B from different domain This could be represented as follows in the document. xx.1 Registraion xx.1.1 Registration from Home domain xx.1.2 Registration from romaing domain xx.2 Location Update xx.2.1 xx.3 Call establishment xx.3.1 Call originating from terminal at home domain xx.3.2 Call originating from terminal at roaming domain xx.3.3 Call terminating to terminal at home domain xx.3.4 Call terminating to terminal at roaming domain xx.3.5 Call to PSTN from terminal at home domain xx.3.6 Call to PSTN from terminal at roaming domain. Well, this is what I was trying to say in the phone conference. Regards, ..//Steve

1 0

Re: Use of IRR by Gateways
by Francois Audet 29 Mar '00

29 Mar '00

> BTW, this is an example of why it is important for > contributors and editors > to avoid using the passive tense in Recommendations. They > should also be > conscious of the verbs they use, e.g., "shall" is the ITU's > only normative > verb, "is" is not. It depends what the definition of "is" is ;^)

1 0