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

Re: EndSessionCommand?
by Paul Long 12 Apr '01

12 Apr '01

Manoj, I'm sure that was an oversight when the tunneling stuff was added. There are plenty of examples of that sort of thing in H.323. Let's see, how shall we rationalize this... :-) Okay, how about this? When talking about tunneling, H.323 always uses the term, "separate H.245 connection" or "separate H.245 channel." The important qualifier here is "separate," so when H.323 simply talks about the H.245 Control Channel, for example, it is referring to the logical channel irrespective of the transport mechanism, i..e., separate or tunneled. Therefore an EP is required to transmit endSessionCommand regardless of whether the channel is separate or tunneled. How does that sound? Paul Long ipDialog, Inc. ---------- Original Message ---------------------------------- From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> Reply-To: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> Date: Thu, 12 Apr 2001 19:07:02 -0700 >Hi, > > Does an endpoint using Tunnelling to exchange H.245 messages with peer, >need >to send EndSessionCommand message during call termination? > There are two different texts relating to this: > >H.245 Specification(V7), Section B.13.4: > "This command indicates the end of the h245 session. After tx >EndSessionCommand, >the terminal shallnot send any more of the messages defined in this >Recommendation". > >H.323 Specification (V4), Section 8.5: Phase E-Call Termination >"..It shall transmit H.245 endSessionCommand message in the H.245 Control >Channel..." > >First statement seems to indicate that notwithstanding how H.245 messages >are >exchanged, an EndSessionCOmmand should be sent to stop any further exchange. >Second statement seems to mean that EndSessionCommand is sent only when >H.245 >Control Channel exists (tunnelling not used). > >Could someone clarify? >thanks >Manoj Paul. >Trillium Digital Systems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Question on presence
by OKUBO Sakae 12 Apr '01

12 Apr '01

Dear Mr. Manoj Paul, I am trying to understand the concept of H.323 presence. In AVD-2087, communication states to be exchanged are listed as: 1) status of the user, 2) its reachable address, 3) user's means of communication, including the preferred mode. The ASN.1 syntax CommunicationState in AVD-2087 includes newAliasAddress (corresponding to 2) above, I understand) and availableForCall, busy (both corresponding to 1) above). I wonder how 3) is handled. Is it going to be added in the course of work? Or as H.323 has the H.245 capability exchange procedure, H.323 presence needs only 1) and 2) above? Or still we would like to indicate e.g. being ready to communicate with fixed H.323 terminal at office, mobile phone like H.323 or H.323 on PDA on the road before the actual communication? 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 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: H.450.2
by Horvath Ernst 12 Apr '01

12 Apr '01

Francois, I think you are right; thanks for pointing this out. It will be corrected. Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet am: Dienstag, 10. April 2001 02:12 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: H.450.2 Guys, In Figure 7/H.450.2 in section 11.2, shouldn't the boxes A1 and A2 under "After service" say "Idle" instead of "Transferring"? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

H.450.2
by Francois Audet 09 Apr '01

09 Apr '01

Guys, In Figure 7/H.450.2 in section 11.2, shouldn't the boxes A1 and A2 under "After service" say "Idle" instead of "Transferring"? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

Information for traveling to the SG16 meeting in Brazil
by Patrick Luthi 06 Apr '01

06 Apr '01

Dear experts, I have been asked by many people if I could host a directory on the standard.pictel.com FTP site that would provide information and tips for traveling to the upcoming SG16 meeting in Porto Seguro, Brazil. I am happy to announce that I created a new directory called 0106_SG16meeting_Info (ftp://standard.pictel.com/0106_SG16meeting_Info/) and I have already posted a few documents that were sent to me along with a FAQ. Please feel free to upload useful documents that you want to share to the (0106_SG16meeting_Info) dropbox and e-mail me any answers to a question that should be posted in the FAQ! See you in Porto Seguro! Best regards Patrick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Issues and Solutions: H.MMS.1 (Mobility for H.323)
by BOUGANT Fran�ois FTRD/DAC/ISS 06 Apr '01

06 Apr '01

Dear experts, Further to Mr. Roy message, I would like to make some comments : 1- Considering that any H.323 mobile user IS CONSIDERED ALSO AS A MOBILE USER by his network access provider and all his other service providers, there are two ways to design the H.323 functional architecture to support mobility : way A : define specific functional entities for mobility management in H.323 systems (HLF, VLF and AuF) without regarding mobility issues in external systems. Physically, each FE represents the database (containing ONLY data related to H.323 user and services) and the associated processes (access, updating...). Relevant interfaces between theses FEs and other FEs like GK, BE and IWF are defined. A specific protocol is defined also only for H.323 MM purpose. way B : Consider the mobility management as a service to make PER USER, and NOT PER USER AND PER SYSTEM. define the database containing data related to H.323 user and services. This database may be considered as a subset of the global database related to the H.323 mobile user (this global database contains also data related to the network access providing, billing, and other services). This global database and its associated processes (access, updating...) are common to different systems (related to the different access and service providers) and are seen as common FEs (AuF, HLF, VLF). Define also relevant interfaces between H.323 FEs and HLF,VLF,AuF-like FEs that doesn't belong only to H.323 functional architecture. A common protocol (or a protocol primarly designed for H.323 systems but containing extensions to be supported on interfaces between FEs from different systems, e.g. protocol compatible with different protocol stacks, different address formats, etc...). Regarding that any actual user subscribes more and more services that are more and more complex to implement, adopting the way A implies to solve serious problems of Mobility Management performance, because the HLF, if supposed to contain only data related to H.323 user mobility, need to access and update data in external databases, implying message and parameter conversion, interface multiplication, etc..., for different purposes (e.g. service interaction). Currently, the way A is chosen in H.MMS.1. I agree with Mr. Roy arguments by preferring the way B. 2- Because some interfaces are used both for MM in H.323 systems and between H.323 and mobile systems, the same protocol should be used for simplification. The protocol defined defined in H.MMS.1 (H.225.0 annex G), because H.323-oriented by nature, can't be optimized for a using in H.MMS.2. I also agree with Mr. Roy arguments and propose to keep all definitions and protocol design in H.MMS.1, but change only the name of the protocol, so it would be possible to make right extensions to this protocol for H.MMS.2. Best regards, Francois bougant ITU-T SG16 WP2 Q.5 participant H.MMS.2 recommandation editor France Telecom R&D -----Message d'origine----- De : Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Envoyé : lundi 2 avril 2001 00:36 À : ITU-SG16(a)MAILBAG.INTEL.COM Objet : Issues and Solutions: H.MMS.1 (Mobility for H.323) 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

05 Apr '01

Paul, H.323v4 is indeed where I got the text from, but that still leaves me clueless about what these procedures could be. You say that the sending of the TCS can force the remote EP into sending a TCS itself. I didn't think it is also the case that upon reception of a TCS, the receiving EP also has to send a TCS. It is only in this first occasion (or after an "empty TCS"), that this situation arises. What is your interpretation of "capability exchange" (I.e. the sending of the capability set only or the mutual exchange of capabilities)? Regards, Frank plong@IPDIALOG.COM@SMTP@MAILBAG.INTEL.COM on 03/04/2001 19:18:54 Please respond to plong@IPDIALOG.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: What does 'exchange' mean and which H.245 message gets to be sent first? Classification: Frank, 1. I have no idea what those failing procedures would be. Maybe it's a v4 thing. 2. Yes, that is correct. Because the TCS must be the first message, if an EP receives a TCS, it must sends its own TCS (if it has not already) before it responds to the TCS with, typically, TCSAck. This is how an EP can force the remote EP into performing cap exchange. Paul Long ipDialog, Inc. -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Frank Derks Sent: Tuesday, April 03, 2001 10:33 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: What does 'exchange' mean and which H.245 message gets to be sent first? 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Sending the "empty capability set" in the first TCS
by Frank Derks 04 Apr '01

04 Apr '01

Suppose that, after having established a call with a remote party, I want the remote party to send its capability set, but do not yet want to send my own capability set. If I am the one that established the H.245 Control Channel, I can imagine that the establishment itself does not necessarily trigger the remote party to send its capability set (although it could), but that the reception of a TCS message does. If I now send a TCS message with an empty capability set, am I doing something that I shouldn't do, or is this perfectly alright and does this trigger the remote party to send its capability set? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Some questions about H.450.4
by Frank Derks 04 Apr '01

04 Apr '01

5/H.450.4 states that it is an implementation/application matter which of the two hold scenarios (near or far end) is invoked. It does, however, not state whether it is mandatory to implement both, any of the two or one particular scenario. Which is the case? The fact that 10.2/H,450.4 mandates that a Gatekeeper/Proxy passes near end call hold messages on to the held endpoint would seem to mandate that at least the near end scenario has to be supported. 5.1/H.450.4 states that the holding endpoint "has to" stop receiving and sending user packets. There is, however, no "shall" in the sentence. Should this then be treated as mandatory? Furthermore, what does it actually mean? To stop receiving can, e.g., mean that received packets are not passed on to the user. The section then continues with a number of MOH options, the last of which is "other indications". This is extremely vague when considering that 7.1.1/H.450.4 mandates that MOH be provided. Does "other indications" include doing nothing? 7.1.1/H.450.1 mandates that MOH be provided to the held user. Why is MOH a mandatory requirement? 7.2.1/H.450.4 states that if the response to a holdNotific.inv or a retrieveNotific.inv, while in the state Hold_NE_Held, is a reject APDU, this shall be _ignored_. The first means that the originating endpoint (or rather its user) simply (and falsely) assumes that the remote party is on hold. Ignoring the second, means that originating party does not restore its state to Hold_Idle! The section then state that user B knows about the hold condition because of the MOH. How can it be guaranteed that the MOH is such that it is recognised as such? 10.1/H.450.4 is about remote-end call hold. Nevertheless, it states: "The proxy in this case shall act as a held endpoint for remote-end call hold and may act as a served endpoint for _near-end hold_". Should the part about near-end hold be interpreted as applying to the role it plays towards the held endpoint? 10.2/H.450.4 states that the near-end call hold messages _shall_ be passed on to the held endpoint. Why isn't it allowed to use remote end call hold on the held side? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Try it for free! 3840
by stacy__l＠DORADO.UNER.EDU.AR 04 Apr '01

04 Apr '01

1 0

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 01 Apr '01

01 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