April 2001 - sg16-avd - lists.packetizer.com

Megaco File Repository -- Addition Of Sample Call Flows
by Tom-PT Taylor 03 Apr '01

03 Apr '01

This note has two purposes: to remind people of the Megaco file repository and to announce the availability of a sample call flow document created by Madhu Babu Brahmanapally <madhubabu(a)kenetec.com> and colleagues, which could be the strating point for an Informational RFC. I have place these call flows in the Current/IETF/ sub-directory (see below). The Megaco file repository is at ftp://standards.nortelnetworks.com/megaco/docs/ and has the following structure: docs/ Approved/ Current/ ATMF/ IETF/ ITU-SG11/ ITU-SG16/ Expired/ Related/ The documents in Approved/ have all been formally approved by the IETF and/or ITU-T SG 16, hence represent the current state of standardization. In particular, this directory holds the latest formally approved H.248 Implementor's Guide, which all developers should have to hand as a supplement to H.248/RFC 3015. The documents in Current/ represent work in progress in various organizations. They all need refreshing at the moment. In particular, I don't have the latest from SG 11 and the SG 16 meeting last month. The ITU-SG16 directory holds the latest draft of the H.248 Implementor's Guide. NOTE THAT THIS IS NOT FORMALLY APPROVED, HENCE CAN CHANGE. The next meeting at which formal approval will take place is in early June. Expired/ holds old drafts, long gone from the IETF archive. Related/ holds documents of interest to Megaco. File names ending in _PDF are PDF documents; those ending in _MSW are Microsoft Word documents. The remainder are text. Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 taylor(a)nortelnetworks.com

1 0

What does 'exchange' mean and which H.245 message gets to be sent first?
by Frank Derks 03 Apr '01

03 Apr '01

H.323 talks about capability exchange, but it is not clear to me whether exchange really means that communicating endpoints send their capability sets to _each other_ or that one endpoint sends its capability set. An example of this can be found in the below text. It talks about succesfully completing capability exchange, but does this means that the initiating endpoint has sent its capability set and that this was acknowledge by the receiver or does it mean that it has also received the capability set of the other party? 8.2/H.323 states: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent unless the endpoint is indicating that it understands the parallelH245Control field (see section 8.2.4). If prior to successful completion of terminal capability exchange, any other procedure fails, (i.e. rejected, not understood, not supported) then the initiating endpoint should initiate and successfully complete terminal capability exchange before attempting any other procedure. " The second sentence mandates that the terminalCapabilitySet message be the first message sent (given that "parallelH245Control" is not used). Which "failing procedures" are then being referred to in the third sentence? If terminalCapabilitySet has to be the first message to be sent, does this mean that an endpoint that has not sent a terminalCapabilitySet message yet and receives this message, it first has to send a terminalCapabilitySet message before acknowledging the received capability set? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

AW: [imtch323implementors] H.323v4 Facility reason in conjunction with H.450apdus
by Klaghofer Karl ICN EN HC ID 71 03 Apr '01

03 Apr '01

Vladimir, With H.450 apdus to be sent within H.323 versions up to v3 your may choose not to include the Facility-UUIE construct at all (but set the "empty" h323-message-body choice instead). The disadvantage with this is that for such messages you miss the Call Identifier. Therefore, it has been agreed to make the Facility-UUIE mandatory with H.323v4, even if only H.450 would have to be transmitted in the H.225.0 message (mainly to get the call identifier). Since the FacilityReason is mandatory in Facility-UUIE, you have to select a reason that fits best to the situation. E.g. use "routeCallToMc" if your scenario is an H.450.2 Transfer to an MCU or use starth245 in conjunction with a FACILITY that also contains an H.450.3 callReroute.Inv if this is what you want to achieve, etc. If none of the reasons are suitable, the new value "transportedInformation" I guess is intended to be used. Value undefinedReason should be accepted always. However, H.225.0 v4 clause 7.4 (third para, last sentense) is misleading, since someone may interpret that the only FacilityReason that is allowed in conjunction with transmitted H.450 apdus may be the new value transportedInformation, which would limit combination of applications significantly. Therefore, the sentense should be rewored to say: "... In H.225.0 version 4 and higher, a sender of an H.450 apdu shall include a Facility-UUIE carrying a callIdentifier field in every Facility message. The FacilityReason field should be set to value transportedInformation if no other reason fields are suitable." I propose to add this clarification to the v4 Implementers Guide. Regards, Karl Klaghofer -----Ursprüngliche Nachricht----- Von: Vladimir Burlik [mailto:vladbph@home.com] Gesendet: Dienstag, 3. April 2001 04:14 An: imtch323implementors(a)mail.imtc.org Betreff: [imtch323implementors] Facility reason Hello all, Could somebody tell me what facility reason should be used when transferring supplementary services messages? For example CallRerouting.Invoke? Thanks Vlad --- You are currently subscribed to imtch323implementors as: Karl.Klaghofer(a)icn.siemens.de To unsubscribe send a blank email to leave-imtch323implementors-35014H(a)mail.imtc.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Report of the Launceston meeting
by OKUBO Sakae 03 Apr '01

03 Apr '01

Dear SG16 experts, A little bit belatedly I have placed the meeting report at the following place: http://standard.pictel.com/ftp/avc-site/0103_Lau/AVD-2100a.zip This has the status of "confirmed by participants" with minor editorial refinements from AVD-2100. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: H.248 Implementors' Guide Additions V5 Update
by Alf Heidermark (UAB) 02 Apr '01

02 Apr '01

How do I reference this implementors guide. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: den 2 april 2001 02:32 To: Blatherwick, Peter Cc: megaco ietf; SG16 Subject: Re: H.248 Implementors' Guide Additions V5 Update Hello Peter, The change bars in v5 are relative to the decided version of H.248. There is an Approved Implementors' Guide which you should look at see td-plen 39 from the Geneva 12/00 SG16 meeting. It contains approved changes up until the 12/00. The implementors' guide additions v5 contains non-approved changes from 12/00 until now. Regards, Christian "Blatherwick, Peter" wrote: > > Hi Christian: > > Quick questions (apologies if I have just been out of > the loop for too long). > > - What are the change bars in v5 relative to? > > - Is there a complete Implementors Guide to look at, > including proposed additions. If not, where can I > locate the latest version that the proposed additions > would apply to? > > Cheers, > Peter Blatherwick > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, March 29, 2001 23:28 > To: megaco ietf; SG16 > Subject: H.248 Implementors' Guide Additions V5 Update > > G'Day all, > > I have come up with an interim version of the H.248 Implementors' Guide > Additions v5. It contains additional correction to ones reviewed at the > SG16 Launceston meeting. > > It can be found at: > ftp://standard.pictel.com/avc-site/Incoming/ > filenames: > TD-xxx_H248_Implementors_Additions_v5.doc > TD-xxx_H248_Implementors_Additions_v5.pdf > > Please check it for correctness and that it contains the points > discussed on the list. There were also some corrections added that were > not discussed on the list. If you have an issue please propose a > solution giving the wording that you would like to see. As mentioned in > the introduction this document is liable to change until final approval. > > v4 was my own edition and was not published to any external network/list > so please don't look for it. > > Let the editor bashing begin. > > Cheers, Christian

1 0

RE: H.248 Implementors' Guide Additions V5 Update
by Blatherwick, Peter 02 Apr '01

02 Apr '01

Hi Christian: Quick questions (apologies if I have just been out of the loop for too long). - What are the change bars in v5 relative to? - Is there a complete Implementors Guide to look at, including proposed additions. If not, where can I locate the latest version that the proposed additions would apply to? Cheers, Peter Blatherwick -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Thursday, March 29, 2001 23:28 To: megaco ietf; SG16 Subject: H.248 Implementors' Guide Additions V5 Update G'Day all, I have come up with an interim version of the H.248 Implementors' Guide Additions v5. It contains additional correction to ones reviewed at the SG16 Launceston meeting. It can be found at: ftp://standard.pictel.com/avc-site/Incoming/ filenames: TD-xxx_H248_Implementors_Additions_v5.doc TD-xxx_H248_Implementors_Additions_v5.pdf Please check it for correctness and that it contains the points discussed on the list. There were also some corrections added that were not discussed on the list. If you have an issue please propose a solution giving the wording that you would like to see. As mentioned in the introduction this document is liable to change until final approval. v4 was my own edition and was not published to any external network/list so please don't look for it. Let the editor bashing begin. Cheers, Christian

2 1

Issues and Solutions: H.MMS.1 (Mobility for H.323)
by Roy, Radhika R, ALCOO 01 Apr '01

01 Apr '01

Hi, Folks: Further to my earlier message, I am sending a note related to the fundamental issues of the present H.MMS.1 (Mobility for H.323) draft. The note also includes the proposed solutions for all those issues. Please note that we discussed all those issues in the last November'00 SG16 meeting. We do not want that the same should be repeated in the upcoming SG16 May-June'01 meeting. In this regard, I also draw the special attention of editors of H.MMS.1 and H.225.0 Annex G, Rapporteurs of Q5/16 and Q2/16, and Mr. Tosco as well. Issues and Solutions of H.MMS.1 (Mobility for H.323): 1. Problem A: The document (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a]) still shows that HLF, VLF, and AuF, as if, are another sets of H.323 functional entities (like GKs, BEs, MCUs and terminals) that are entitled to use H.323/H.225.0 (RAS, Q.931/932)/H.225.0 Annex G protocols. However, like many other services such as directory, billing, and others, HLF, VLF, and AuF are the backend services and the protocols used by those entities must NOT be called a part of the H.323/H.225.0 protocol because these backend services protocols can be used by other application protocols (e.g., H.234, H.310) as well. Problem B: If the mobility management protocol is called H.225.0 Annex G, it cannot be used or extended for the global mobility management purpose (e.g., H.MMS.2). Problem C: More functionalities like Authentication, Charging/Billing, Directory, Policy, and other entities are needed for mobile (and even for non-mobile) functions. We cannot use make them as a part of H.323 protocol. Problem D: We cannot make one HLF/VLF/AuF protocol for H.323, another HLF/VLF/AuF protocol for H.324, and another for H.310, and another for IMT-2000. The same protocols MUST be allowed to be used by any applications whenever needed without providing any restrictions. Solution for problems A, B, C, and D: No functional entity like HLF, VLF, AuF, Charging/Billing, Policy, Directory or others will be defined as the H.323 functional entity. Rather, each of this entity will be a backend functional entity and the protocol among these entities must be independent of the H.323/H.225.0 Annex G protocol. The protocol used among HLF, VLF, and AuF entities may have all capabilities, functionalities and features as described in the document, but MUST be called a different protocol (e.g., M.management) so that all application protocols including H.323 will be at liberty to use it. So, the said protocol MUST NOT be called H.225.0 Annex G or its extension. In other words, we are changing the name only (not the capabilities, functions, or features). Similar will be the case for Charging/Billing, Policy, Directory or others. 2. Problem: Mobility management procedures (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a (Figure 11a)]) still indicate that there is only one HLF that communicates directly with the VLFs located in two separate administrative domains. This breaks the fundamental concept of the administrative domains as standardized in H.323 because an administrative domain is autonomous and can communicate only through the BEs (with one HLF, this principle is violated and breaks the basic foundation of H.225.0 Annex G). Solution: Similar to inter-zone (e.g., Figure 13 of AVD-2053a), the communications between the two administrative domains MUS be made via the BEs no matter whether there is one or multiple HLFs. Communications scenarios with at least one HLF in each administrative domain needs to be shown. Best regards, Radhika R. Roy AT&T Technology Consultant Room 3D-2C09 200 S. Laurel Avenue Middletown, NJ 07748 +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0