June 2007 - sg16-avd - lists.packetizer.com

[itu-sg16] C-277: H.248.1 Compatibility
by Schwarz Albrecht 26 Jun '07

26 Jun '07

Hello Christian, all, like the proposal concerning forward & backward compatibility rules. Did add some text with regards to the compatibilty mechanism(s), which are specific to H.248 (and thus worth to be mentioned). Best regards, Albrecht <<T05-SG16-C-0277r1 H.248 Compatibility.doc>> #### Hello Albrecht, Keith, Thanks for the reference to Q.1400. I think it was these fundamentals of compatibility for ISUP and DSS that lead to the original definition of the version negotiation and protocol enhancement rules in H.248.1. At the time of writing H.248.1v1 there was involvement from a number of people involved in the work of SG11. I think the general principles of Q.1400 are in-line with what is being used in H.248.1 so at this level it can be used. I agree some of the specific examples aren't relevant for H.248.1. I'll try to propose some clarifying text for the Q.3/16 meeting. I don't intend to write a thesis on the matter, I intend to stick making simple rules applicable for protocol, packages and profiles. Regards, Christian Albrecht Schwarz wrote: > [Like to open a separate thread on compatibility rules for H.248, think > this is a more general topic in comparison to the Ia specific IP realm > indication mechanism.] > > Keith, thanks for the pointer to Q.1400, believe that the clause about > compatibility rules is a good baseline for correspondent definitions for > H.248. > I think additional explicit text about compatibility rules in H.248.1, e.g. > in clause 12, would be beneficial. > > We may not directly reuse Q.1400 for H.248 (in my understanding) because > a) Q.1400 is for ASN.1 defined protocols (and H.248 has also ANBF defined > grammar for text encoding mode), > b) Q.1400 focus is SS7 and DSS1, or > c) H.248 integrated version/profile mechanisms. > > Christian, think that your proposal is a good baseline. Could you submit it > as input to next Q.3/16 meeting? > > Albrecht > > > > > "Drage, Keith > $Keith$" To: "Schwarz, Albrecht $Albrecht$" <albrecht.schwarz(a)alcatel-lucent.de>, > <drage@alcatel-l <TISPAN_WG3(a)LIST.ETSI.ORG> > ucent.com> cc: > Subject: RE: H.248 Ia Profile Version 2 > 24.04.2007 12:07 > > > > > > The compatibility definitions in ITU-T are all in Q.1400. > > Regards > > Keith > > >> -----Original Message----- >> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE] >> Sent: Tuesday, April 24, 2007 1:08 AM >> To: TISPAN_WG3(a)LIST.ETSI.ORG >> Subject: Re: H.248 Ia Profile Version 2 >> >> Bruno >> >> >>> My understanding is that backward compatibility in the work item >>> >> description was intended to refer to the ability >> >>> for version n+1 to understand version n without requiring version >>> >> negotiation to occur before. This is usually what >> >>> is meant in other ITU-T and ETSI standards dealing with signalling. >>> >> Couldn't find any appropriate definition for "backward >> compatibility" in ITU-T & ETSI (like the one for codecs from H.262). >> >> There are signalling protocols with and without a version >> negotiation mechanism. The understanding of "backward >> compatibility" might be slightly different for both >> categories. Guess the protocols without a version negotiation >> method are the majority like the capability set based ITU-T >> protocols like e.g. INAP, BICC or Q.2630.x. >> H.248 belongs to the category with an >> a) integral mechanism for protocol version negotiation and in >> addition a >> b) mechanism for profile negotiation >> and also >> c) a multi profile mode capability (H.248.18). >> >> The used protocol capabilities are related to the lifetime of >> the H.248 Control Association (CA), starting the negotiation >> at CA establishment. >> Capability upgrade procedures may lead to a re-new or >> re-establishment of the CA. >> >> A definition for "backward compatibility" for H.248 CAs might >> therefore different to other protocols without such mechanisms. >> >> We got four WIs for H.248 Profiles, - a MG registration with >> the correspondent ProfileID is part of a profile specification. >> Saying that, the meaning of backward compatibility in the WI >> description means that the MG registers with Ia/2 in my opinion. >> In case of a fallback requirement to Ia/1, then current draft >> my be extended for H.248.18 support (but this requires a >> contribution). >> >> Albrecht >> >> >> >> >> >> >> >> Christian Groves >> >> >> <Christian.Groves@NT To: >> TISPAN_WG3(a)LIST.ETSI.ORG >> >> ECZONE.COM> cc: >> >> >> Subject: >> Re: H.248 Ia Profile Version 2 >> >> 23.04.2007 09:55 >> >> >> Please respond to >> >> >> Christian Groves >> >> >> >> >> >> >> >> >> >> Hello Bruno, >> >> What does "ability for version n+1 to understand version n" >> mean? Even in the scenario we are talking about a MG with a >> version n+1 control association will understand the version n >> message because the encoding has not changed (thus backwards >> compatible by the definition below) but it will reject it >> because of new required functionality. Likewise it seems that >> "before version negotiation" has been prompted by the email >> discussion. For some, such mechanisms are integral for >> compatibility mechanisms. >> >> Do you have a reference to a general description of "backwards >> compatibility"? The term is used alot but I don't know any >> description >> other than that in H.248.1. For example H.248.1 section 11.3 >> Negotiation of Protocol Version offers rules for new versions. ie. >> >> /When extending the protocol with new versions, the >> following rules >> should be followed:/ >> /1) Existing protocol elements, i.e., procedures, parameters, >> descriptor, property, values, should/ >> /not be changed unless a protocol error needs to be >> corrected or it >> becomes necessary to/ >> /change the operation of the service that is being >> supported by the >> protocol./ >> /2) The semantics of a command, a parameter, a descriptor, a >> property, or a value should not be/ >> /changed./ >> /3) Established rules for formatting and encoding messages and >> parameters should not be/ >> /modified./ >> /4) When information elements are found to be obsolete they can be >> marked as not used./ >> /However, the identifier for that information element >> will be marked >> as reserved. In that way/ >> /it cannot be used in future versions./ >> >> These rules were adopted to ensure backwards compatibility. I >> think these rules are equally applicable to the case of >> profiles. When the MGC and MG agree on the use of a control >> association they agree on the >> H.248.1 version and the profile (including version). >> >> Regards, Christian >> >> CHATRAS Bruno RD-CORE-ISS wrote: >> >>> Hello Chirstian, >>> >>> My understanding is that backward compatibility in the work item >>> >> description was intended to refer to the ability for version >> n+1 to understand version n without requiring version >> negotiation to occur before. >> This is usually what is meant in other ITU-T and ETSI >> standards dealing with signalling. >> >>> Best Regards, >>> Bruno >>> >>> -----Message d'origine----- >>> De : Christian Groves [mailto:Christian.Groves@NTECZONE.COM] >>> Envoyé : lundi 23 avril 2007 02:58 >>> À : TISPAN_WG3(a)LIST.ETSI.ORG >>> Objet : Re: H.248 Ia Profile Version 2 >>> >>> Hello Bruno, >>> >>> What was the definition of "backward compatibility" that >>> >> the work item >> description assumed? It seems that people have different >> interpretations. >> >>> Regards, Christian >>> >>> CHATRAS Bruno RD-CORE-ISS wrote: >>> >>> >>>> This is version negotiation, not backward compatibility.... Both >>>> >> approaches are valid protocol design approaches and have >> their pros and cons. However, the Work Item description >> assumed "backward compatibility between version 1 and 2... >> >>>> -----Message d'origine----- >>>> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM] Envoyé : vendredi 20 >>>> avril 2007 04:09 À : TISPAN_WG3(a)LIST.ETSI.ORG Objet : Re: H.248 Ia >>>> Profile Version 2 >>>> >>>> Agree Albrecht's state. >>>> When a BGF registers with a ProfileID "ETSI_BGF/1" 0r >>>> "ETSI_BGF/2", >>>> >> corresponding ia profile(ia/2 or ia/1) should be applied. >> >>>> I think the Profile-based backward compatibility >>>> >> between ia/2 and >> ia/1 is based on their functions. Ia/2 can realize all the >> functions of Ia/1, but new better methods can be used, even >> it is mandatory. >> >>>> BR >>>> Neal >>>> >>>> -----Original Message----- >>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE] >>>> Sent: Thursday, April 19, 2007 6:50 PM >>>> To: TISPAN_WG3(a)LIST.ETSI.ORG >>>> Subject: Re: H.248 Ia Profile Version 2 >>>> >>>> [Sorry for using your initials as abbreviation BC for backward >>>> compatibility :-)] >>>> >>>> I do agree to your statement. >>>> >>>> Important here is the "scope of the protocol" in my understanding. >>>> There would be a compatibility issue when the SPDF & BGF would >>>> operate >>>> >> Ia interface in the "NoProfile" mode, i.e. the BGF would not >> include the ServiceChangeProfile parameter for registration. >> >>>> But the protocol scope is limited when registering with a >>>> >> ProfileID >> >>>> (as >>>> >> in case of ES 283 018). There are then only "ETSI_BGF/1" or >> "ETSI_BGF/2" >> >>>> H.248 Messages between a single SPDF-BGF tandem. >>>> >>>> I think that this is the crucial point concerning "protcol >>>> >> scope" for >> >>>> H.248 >>>> interface: "Profile-less" vs "Profile-based" operated H.248 Control >>>> >> Associations. >> >>>> Albrecht >>>> >>>> >>>> >>>> >>>> >>>> "CHATRAS Bruno >>>> >>>> RD-CORE-ISS" To: >>>> >> "Neal >> >>>> ZhuNing" <zhuning(a)huawei.com>, <Albrecht.Schwarz(a)ALCATEL-LUCENT.DE> >>>> <bruno.chatras@orange-f cc: >>>> <TISPAN_WG3(a)LIST.ETSI.ORG> >>>> >>>> tgroup.com> >>>> >> Subject: RE: H.248 >> Ia >> >>>> Profile Version 2 >>>> >>>> >>>> 19.04.2007 12:28 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Adding a mandatory parameter to version n+1 of a protocol >>>> >> means that >> >>>> a >>>> >> message conforming to the version n of this protocol is not a >> valid message for an implementation conforming to version n+1 >> of this protocol. Is not this a compatobility issue? >> >>>> BC >>>> >>>> -----Message d'origine----- >>>> De : Neal ZhuNing [mailto:zhuning@huawei.com] Envoyé : >>>> >> jeudi 19 avril >> >>>> 2007 11:55 À : Albrecht.Schwarz(a)ALCATEL-LUCENT.DE; CHATRAS Bruno >>>> RD-CORE-ISS Cc : TISPAN_WG3(a)LIST.ETSI.ORG Objet : RE: H.248 Ia >>>> Profile Version 2 >>>> >>>> Hi Albrecht, Bruno, >>>> In Ia/1, the hierarchical termination name does not specifically >>>> >> mention that it is used to identify the IP domain that a >> termination is connected to, nor does it give an example of >> the syntax associated with the "interface". So maybe there is >> no backward compatibility on this issue. >> >>>> In Ia/2, the hierarchical termination name may still be used to >>>> >> specify which physical or logical interface a termination >> should be associated with in the MG. >> >>>> So, the hierarchical termination name mechanism is same in Ia/1 and >>>> >> Ia/2, there is no backward compatibility problem. >> >>>> BR >>>> Neal >>>> >>>> -----Original Message----- >>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE] >>>> Sent: Thursday, April 19, 2007 5:21 PM >>>> To: TISPAN_WG3(a)LIST.ETSI.ORG >>>> Subject: Re: H.248 Ia Profile Version 2 >>>> >>>> Bruno, >>>> when we discussed this, we couldn't see a violation of the backward >>>> >> compatibility (BC) principle. >> >>>> The MG is registering either with Ia/1 or Ia/2, but not with both >>>> >> profile versions (like in a multiple profile mode), the used >> IP realm/domain indication mechanism is unambiguous. >> >>>> The profile principle is thus supporting BC targets. >>>> A single H.248 Control Association is either operated with >>>> >> Ia/1 or Ia/2. >> >>>> Do I overlook sth? >>>> >>>> Albrecht >>>> >>>> PS >>>> Above principle is/may also used for other "capability upgrades", >>>> like H.248.10 replacement by H.248.11 in a next profile >>>> >> version, etc >> >>>> etc >>>> >>>> >>>> >>>> >>>> >>>> CHATRAS Bruno >>>> >>>> RD-CORE-ISS To: >>>> TISPAN_WG3(a)LIST.ETSI.ORG >>>> >>>> <bruno.chatras@ORANGE-F cc: >>>> >>>> TGROUP.COM> >>>> >> Subject: H.248 Ia >> >>>> Profile Version 2 >>>> >>>> >>>> 19.04.2007 11:12 >>>> >>>> Please respond to >>>> >>>> CHATRAS Bruno >>>> >>>> RD-CORE-ISS >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ray, Wayne, >>>> >>>> I just had a look to the Latest Draft of WI03098 (Ia >>>> >> profile Release >> >>>> 2) >>>> >> and saw that support of the new IPDC package is mandatory >> rather than optional. >> >>>> This contradicts the Work Item description which says >>>> >> explictly that >> "The Ia profile version 2 shall maintain backwards >> compatibility with version 1." The meeting reports says that >> adding the IPDC package was indeed agreed but does not say >> whether it should be mandatory or optional. >> I believe that we should either make this package optional or >> made an attempt to modify the Work Item description. I assume >> we can't approve a deliverable which explicitly contradicts a >> Work Item description. >> >>>> BTW, what is the procedure for TB approval of this modification. >>>> There >>>> >> does not seem to be any CR corresponding to this modification >> (just a contribution). >> >>>> Best regards >>>> Bruno >>>> >>>> #### Christian Groves <Christian.Groves(a)nteczone.com> 08.05.2007 08:31 To: CHATRAS Bruno RD-CORE-ISS <bruno.chatras(a)orange-ftgroup.com> cc: "Wayne Cutler (CV/ETL)" <wayne.cutler(a)ericsson.com>, Neal ZhuNing <zhuning(a)huawei.com>, "Jerker Zetterlund (TN/EAB)" <jerker.zetterlund(a)ericsson.com>, seppo.kauntola(a)nsn.com, Albrecht.Schwarz(a)alcatel-lucent.de, CWaitzmann(a)alcatel-lucent.de, smaoui(a)nortel.com, Lin Yangbo <linyangbo(a)huawei.com>, Tommy Young <tommy(a)huawei.com> Subject: Re: H.248 Ia Profile Version 2 Hello Bruno, all, With regards to linking Tispan releases to profile versions I see that adding optional elements to the profiles is the same as adding then to packages, the version number is stepped. At least you then know the capabilities have changed and the new optional features are available to be used. On the IPDC issues based on your response I've attached some proposed marked up changes to ES283 018 (13bTD108r3). For me at least the distinction is where the MGC knows the actual IPdomain its uses the IP realm identifier, where it doesn't its uses the terminationId and lets the MG decide. Other suggestions welcome. Regards, Christian CHATRAS Bruno RD-CORE-ISS wrote: > Yes I want to contrinue using implicit IP domain signalling. I want to be able to use new optional features brought by TISPAN Release 2 while continuing to use the existing mechanism for IP domain signalling. Actually I'm wondering wheter it was not a mistake to assume from the beginning TISPAN Release x maps to Profile Version x. It would certarinly be more efficient to have several releases mapping to the same Profile version with additional optional capabilties added over the releases... > > To answer your question, I think that the MGC does not need to know the IP Domain nor the IP address pool. It just needs to tell the MG on which "side" of the box the termination should be created. It is then up to the MG to derive the IP Domain and associated address pool to us. > > Having said that, I still think that adding a mandatory element to version N+1 of a protocol/profile means that versnion N+1 is not backward compatible with version N. > > Best Regards > Bruno > > > -----Message d'origine----- > De : Christian Groves [mailto:Christian.Groves@nteczone.com] > Envoyé : lundi 30 avril 2007 07:33 > À : Wayne Cutler (CV/ETL); CHATRAS Bruno RD-CORE-ISS > Cc : Neal ZhuNing; Jerker Zetterlund (TN/EAB); seppo.kauntola(a)nsn.com; Albrecht.Schwarz(a)alcatel-lucent.de; CWaitzmann(a)alcatel-lucent.de; smaoui(a)nortel.com; Lin Yangbo; Tommy Young > Objet : Re: H.248 Ia Profile Version 2 > > Hello all, > > I don't agree with the assertion that there is no need for compatibility between version of profiles. I guess I'm old fashioned, to me a version change is applied to a protocol whenever there is a change (as Wayne suggests). As I've posted before H.248.1 sect 11.3 outlines rules for up versioning the H.248 protocol. These rules have been/are applied to up-versioning of packages and I don't see why they are not applicable to > H.248 profile specifications. If you want to make changes that aren't compatible then you can use a new profile name. As Albrecht has suggested I will contribute to the next Q.3/16 meeting on this. I also agree with Wayne's email I don't see this change is a break of compatibility. > > I do think this backwards compatibility issue is distracting from the real issue however. > > It seems to me Bruno's real issue is that he wants to continue to use "implicit IP domain signalling" e.g. via the interface field in V2 without having to use H.248.41. Is this correct Bruno? If so then before I make a proposal along those lines I have a question about your comment: > > /2/ If the IP realm identifier is received by the BGF, it shall take > precedence over any IP realm that may be derived from (or associated > to) the interface identifier./ > > In the case of Ia v1 where do you see this association between the interfaceID and IP realm being set? Does the MGC know which FQDN IP realm the termination will be connected to when it requests an interface ID?, or is the IP realm only known by the MG and may be assigned as a consequence of a request for a particular interface? > > Regards, Christian > > PS: Just to be clear when I talk about IP realm I mean a FQDN. > > Wayne Cutler (CV/ETL) wrote: > >> Hi Bruno et al, >> >> I think that the fact that we are stepping the version of Ia from 1 to >> 2 means that something has changed - else we would not step the >> version. More specifically, I think that it means that some additional >> mandatory fucntions have been added >> - and this translates in H248 as the addition of extra mandatory >> packages. >> >> When a version is stepped, the key point IMO is that no functionality >> is lost (i.e the upissued box can't be less capable than its old >> version). It is OK to add new functionality and also be able to >> realise previous functionality in a different way. As long as this >> difference is clearly described and understood, then this is not a >> problem. In this particular case, Ia v2 has added the new ipdc package >> but also maintained the termination naming scheme from Ia v1. So, I >> don't think there's a practical problem. >> >> Finally, given the way in which H248 allows a profile negotiation as >> part of its SC procedures, I don't think there is a scenario where Ia >> v2 needs to "interwork" with Ia v1. >> >> Regards, Wayne >> >> ---------------------------------------------------------------------- >> -- >> *From:* CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com] >> *Sent:* 25 April 2007 09:52 >> *To:* Neal ZhuNing; Jerker Zetterlund (TN/EAB) >> *Cc:* seppo.kauntola(a)nsn.com; Wayne Cutler (CV/ETL); >> Albrecht.Schwarz(a)alcatel-lucent.de; CWaitzmann(a)alcatel-lucent.de; >> smaoui(a)nortel.com; Christian Groves; Lin Yangbo; Tommy Young >> *Subject:* RE: H.248 Ia Profile Version 2 >> >> Interesting... It's the first time I read an explicit statement from >> an ETSI member that interoperability between versions of ETSI >> standards is unreasonable!!! >> >> ---------------------------------------------------------------------- >> -- *De :* Neal ZhuNing [mailto:zhuning@huawei.com] *Envoyé :* mercredi >> 25 avril 2007 10:47 *À :* 'Jerker Zetterlund (TN/EAB)'; CHATRAS Bruno >> RD-CORE-ISS *Cc :* seppo.kauntola(a)nsn.com; 'Wayne Cutler (CV/ETL)'; >> Albrecht.Schwarz(a)alcatel-lucent.de; CWaitzmann(a)alcatel-lucent.de; >> smaoui(a)nortel.com; 'Christian Groves'; 'Lin Yangbo'; 'Tommy Young' >> *Objet :* RE: H.248 Ia Profile Version 2 >> >> Hello Jerker and all, >> >> I do agree with your viewpoint. Profile version negotiation can >> avoid backwards compatibility issue. Interoperability between Ia /1 >> and Ia/2 is unreasonable. >> >> >> >> >> >> BR >> >> Neal >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Jerker Zetterlund (TN/EAB) >> [mailto:jerker.zetterlund@ericsson.com] >> *Sent:* Wednesday, April 25, 2007 4:25 PM >> *To:* Neal ZhuNing; CHATRAS Bruno RD-CORE-ISS >> *Cc:* seppo.kauntola(a)nsn.com; Wayne Cutler (CV/ETL); >> Albrecht.Schwarz(a)alcatel-lucent.de; CWaitzmann(a)alcatel-lucent.de; >> smaoui(a)nortel.com; Christian Groves; Lin Yangbo; Tommy Young >> *Subject:* RE: H.248 Ia Profile Version 2 >> >> >> >> Hello all, >> >> >> >> I think this discussion is based on different understandings of the >> meaning of profile version. In the drafting session of the March >> TISPAN meeting I think we assumed that there is no need for direct >> compatibility between v1 and v2 of the profie. If both SPDF and MG >> support Ia v2 then this should not be a problem. >> >> >> >> As I just wrote in the other email, my personal view is that there is >> no clear need for interoperability between Ia v1 and Ia v2. As >> profiles are intended to limit the functionality to be used on an >> H.248 control association, then it seems reasonable for the MG & MGC >> to be able to be as precise as possible in which set of functionality >> to be used. >> >> >> >> BR >> >> >> >> Jerker >> >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Neal ZhuNing [mailto:zhuning@huawei.com] >> *Sent:* den 25 april 2007 09:21 >> *To:* 'CHATRAS Bruno RD-CORE-ISS' >> *Cc:* seppo.kauntola(a)nsn.com; Wayne Cutler (CV/ETL); >> Albrecht.Schwarz(a)alcatel-lucent.de; CWaitzmann(a)alcatel-lucent.de; >> Jerker Zetterlund (TN/EAB); smaoui(a)nortel.com; 'Christian Groves'; >> 'Lin Yangbo'; 'Tommy Young' >> *Subject:* RE: H.248 Ia Profile Version 2 >> >> Hi Bruno and all, >> >> Could we discuss it to reach an agreement before meeting? (Not in >> WG3 group) >> >> Your second principle is hard to be followed. when new ip >> termination is crreated, If the IP realm identifier indicates >> "IPDomain1",but the terminationID in add request indicates an >> "interface" belongs to "IPDomain2" ,such as "ip/9/9/$", How MG can do? >> Can MG change another interface identifier(such as "ip/8/8/8" which >> belongs to ip domain "IPDomain1")in reply message ? i think it is not >> allowed by H.248 protocol. so if there is conflict brtween IP realm >> identifier and interface identifier, MG should reply error . Is it >> correct? >> >> I agree that SPDF can choose interface identifier according to IP >> domain and send it to BGF. But , in most case ,It is enough for SPDF >> to only send the IP realm identifier when the SPDF wishes to indicate >> the IP domain/realm of the H.248 IP terminationin to BGF,such as in >> ADD request . do you agree this? >> >> so I provide a principles list below: >> >> 1)The IP realm identifier shall preferentially be used if the SPDF >> wishes to indicate the IP domain/realm of the H.248 IP termination. >> >> 2)If SPDF wishs to specify which physical or logical interface a >> termination should be associated with in the MG, SPDF may set >> "interface" field. "interface" field may be associated to IP realm. >> >> 3)If there is conflict between IP realm identifier and the ip domain >> the "interface" field associated to ,error code should be replied. >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@ORANGE-FTGROUP.COM] >> >> Sent: Tuesday, April 24, 2007 8:42 PM >> >> To: TISPAN_WG3(a)LIST.ETSI.ORG >> >> Subject: Re: H.248 Ia Profile Version 2 >> >> >> >> OK then I disagree with 5.1.4.2.15.1 and will submit a CR against it. >> Let's talk about his at the meeting. Note that a "version 1" BGF is >> able to derive the IP domain (and tehrefore the address ppol from >> which the termination address shall be taken) from the "interface" >> field. Release 2 shall not disallow this behavior. Therefore I think >> that we should draft a text along the following principles: >> >> >> >> 1/ The IP realm identifier shall be sent to the BGF when the SPDF >> wishes to indicate explictly the IP domain/realm of the H.248 IP >> termination. >> >> >> >> 2/ If the IP realm identifier is received by the BGF, it shall take >> precedence over any IP realm that may be derived from (or associated >> to) the interface identifier. >> >> >> >> BC >> >> >> >> >> >> This behavior >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com] >> >> Envoyé : mardi 24 avril 2007 12:59 >> >> À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3(a)LIST.ETSI.ORG >> >> Objet : RE: H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> In the latest draft, Session 5.14.2.15.1: >> >> "The ephemeral termination string layout >> ("ip/<group>/<interface>/<id>") may still be used to specify which >> physical or logical interface a termination should be associated with >> in the MG. but the "interface" field shall not be used for IP >> realm/domain indication ." >> >> >> >> The "interface" field shall not be used for IP realm/domain >> indication, so if SPDF wishes to indicate the IP domain/realm of the >> H.248 IP termination, only ipdc property can be used in ia/2. >> >> >> >> BR >> >> Neal >> >> >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com] >> >> Sent: Tuesday, April 24, 2007 6:48 PM >> >> To: Neal ZhuNing; TISPAN_WG3(a)LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> Based on operator's policy and BGF capabilities (e.g. if the IP domain >> can't be derived from the interface id by the BGF). >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com] Envoyé : mardi 24 avril >> 2007 12:44 À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3(a)LIST.ETSI.ORG >> Objet : RE: H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> In which condition the SPDF wishes to indicate explictly the IP >> domain/realm of the H.248 IP termination?? >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com] >> >> Sent: Tuesday, April 24, 2007 6:40 PM >> >> To: Neal ZhuNing; TISPAN_WG3(a)LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> I would prefer >> >> >> >> "The IP realm identifier shall be sent to the BGF when the SPDF >> wishes to indicate explictly the IP domain/realm of the H.248 IP >> termination." >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM] Envoyé : mardi 24 avril >> 2007 >> >> 12:37 À : TISPAN_WG3(a)LIST.ETSI.ORG Objet : Re: H.248 Ia Profile >> Version 2 >> >> >> >> Hi Bruno, >> >> >> >> What about: "The IP realm identifier shall be sent to the BGF in order >> to indicate the IP domain/realm of the H.248 IP termination." >> >> >> >> Your state "if explicit signalling of the IP domain/realm of the H.248 >> IP termination is required." is unclear. In which condition this >> explicit signaling is required? I think this condition is that SPDF >> wants to indicate the IP domain/realm of the H.248 IP termination. >> >> >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com] >> >> Sent: Tuesday, April 24, 2007 6:28 PM >> >> To: Neal ZhuNing; TISPAN_WG3(a)LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> Use of "MUST" in ETSI documents is not recommended by the ETSI >> Drafting Rules anyway... (See Clause 23 of the ETSI Drafting Rules). >> >> >> >> What about: "The IP realm identifier shall be sent to the BGF if >> explicit signalling of the IP domain/realm of the H.248 IP termination >> is required." >> >> >> >> >> >> Bruno >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com] Envoyé : mardi 24 avril >> 2007 >> >> 12:04 À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3(a)LIST.ETSI.ORG Objet : RE: >> >> H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> It should be "MUST", not "MAY". >> >> When SPDF wants to indicate the IP domain/realm of the H.248 IP >> termination, the ipdc property MUST be sent to the BGF. >> >> If there is no ipdc property in the message, it is still a valid >> message, but it can not indicate the IP domain/realm. BGF creates IP >> terminations on the special "interface "according to the (ALL or >> partial) wildcard terminationID. >> >> >> >> BR >> >> Neal >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@orange-ftgroup.com] >> >> Sent: Tuesday, April 24, 2007 5:49 PM >> >> To: Neal ZhuNing; TISPAN_WG3(a)LIST.ETSI.ORG >> >> Subject: RE: H.248 Ia Profile Version 2 >> >> >> >> Yes I was referring to this text >> >> >> >> "The IP realm identifier must be sent to the BGF in order to indicate >> the IP domain/realm of the H.248 IP termination." >> >> >> >> Would you agree to replace "MUST" with "MAY"? >> >> >> >> Best Regards >> >> Bruno >> >> >> >> -----Message d'origine----- >> >> De : Neal ZhuNing [mailto:zhuning@huawei.com] Envoyé : mardi 24 avril >> 2007 >> >> 11:27 À : CHATRAS Bruno RD-CORE-ISS; TISPAN_WG3(a)LIST.ETSI.ORG Objet : RE: >> >> H.248 Ia Profile Version 2 >> >> >> >> Hi Bruno, >> >> >>> I have seen that somewhere in the text of the Latest Draft it is >>> >>> stated >>> >> that >the MGC SHALL set the H.248.41 property. Unless there is an >> error in the text, >this seems to assume interpretation "b". >> >> >> >> I can not find your this state in the text of the latest draft, maybe >> what you refer to is Ia/2 session 5.14.2.15.1 ?? >> >> >> >> Best Regards, >> >> Neal >> >> >> >> >> >> -----Original Message----- >> >> From: CHATRAS Bruno RD-CORE-ISS >> [mailto:bruno.chatras@ORANGE-FTGROUP.COM] >> >> Sent: Tuesday, April 24, 2007 3:27 PM >> >> To: TISPAN_WG3(a)LIST.ETSI.ORG >> >> Subject: Re: H.248 Ia Profile Version 2 >> >> >> >> Carsten, >> >> >> >> I agree that there would not be any compatibility issue with >> interpretation "a". However, I have seen that somewhere in the text of >> the Latest Draft it is stated that the MGC SHALL set the H.248.41 >> property. Unless there is an error in the text, this seems to assume >> interpretation "b". >> >> >> >> Best Regards >> >> Bruno >> >> >> >> -----Message d'origine----- >> >> De : Carsten Waitzmann [mailto:cwaitzmann@ALCATEL-LUCENT.DE] >> >> Envoyé : mardi 24 avril 2007 09:21 >> >> À : TISPAN_WG3(a)LIST.ETSI.ORG >> >> Objet : Re: H.248 Ia Profile Version 2 >> >> >> >> Hello Bruno, >> >> >> >> Related to your understanding of backward compatibility: >> >> > My understanding is that backward compatibility in the work item > >> description was intended to refer to the ability for version n+1 to > >> understand version n without requiring version negotiation to occur > >> before. >> >> >> >> I'd like to ask the following question: >> >> What does "mandatory package" within a H.248 profile mean: >> >> a) it just means that a MG/MGC announcing compliance to this profile >> can expected to have implemented all these packages (and therefore all >> received >> >> H.248 messages using any property, signal, etc. of these packages is >> properly understood and processed). However it doesn't imply that the >> packages have to be always used whenever possible. >> >> b) same as a) but mandatory packages have to be always used whenever >> possible. >> >> >> >> If it is a), then I don't think that there is a backward compatibility >> issue. In the specific case of H.248.41, for example an MGC may still >> run v1 w/o .41 and the MG although running v2, may perfectly receive >> and process the message. v2 remains backward compatible, as the v1 >> capability to indicate a physical/logical interface within the IP >> termination string is still available. It wouldn't be backward >> compatible if the v2 profile would have changed the semantic of >> "interface" within the IP termination string. >> >> >> >> best regards >> >> Carsten >> >> >> >> Albrecht Schwarz wrote: >> >> >>> Bruno >>> >>>> My understanding is that backward compatibility in the work item >>>> >>> description was intended to refer to the ability >>> >>>> for version n+1 to understand version n without requiring version >>>> >>> negotiation to occur before. This is usually what >>> >>>> is meant in other ITU-T and ETSI standards dealing with signalling. >>>> >>> Couldn't find any appropriate definition for "backward compatibility" >>> >>> in ITU-T & ETSI (like the one for codecs from H.262). >>> >>> There are signalling protocols with and without a version >>> negotiation >>> >>> mechanism. The understanding of "backward compatibility" might be >>> >>> slightly different for both categories. Guess the protocols without >>> a >>> >>> version negotiation method are the majority like the capability set >>> >>> based ITU-T protocols like e.g. INAP, BICC or Q.2630.x. >>> >>> H.248 belongs to the category with an >>> >>> a) integral mechanism for protocol version negotiation and in >>> addition >>> >>> a >>> >>> b) mechanism for profile negotiation >>> >>> and also >>> >>> c) a multi profile mode capability (H.248.18). >>> >>> The used protocol capabilities are related to the lifetime of the >>> >>> H.248 Control Association (CA), starting the negotiation at CA >>> >> establishment. >> >> >>> Capability upgrade procedures may lead to a re-new or >>> re-establishment >>> >>> of the CA. >>> >>> A definition for "backward compatibility" for H.248 CAs might >>> >>> therefore different to other protocols without such mechanisms. >>> >>> We got four WIs for H.248 Profiles, - a MG registration with the >>> >>> correspondent ProfileID is part of a profile specification. >>> >>> Saying that, the meaning of backward compatibility in the WI >>> >>> description means that the MG registers with Ia/2 in my opinion. >>> >>> In case of a fallback requirement to Ia/1, then current draft my be >>> >>> extended for H.248.18 support (but this requires a contribution). >>> >>> Albrecht >>> >> >> >> >>> Christian Groves >>> >> >> >> >>> <Christian.Groves@NT To: >>> >> TISPAN_WG3(a)LIST.ETSI.ORG >> >> >> >> >>> ECZONE.COM> cc: >>> >> >> >> >>> Subject: Re: >>> H.248 >>> >>> Ia >>> >> Profile Version 2 >> >> >>> 23.04.2007 09:55 >>> >> >> >> >>> Please respond to >>> >> >> >> >>> Christian Groves >>> >> >> >> >> >> >> >>> Hello Bruno, >>> >>> What does "ability for version n+1 to understand version n" mean? >>> Even >>> >>> in the scenario we are talking about a MG with a version n+1 control >>> >>> association will understand the version n message because the >>> encoding >>> >>> has not changed (thus backwards compatible by the definition below) >>> >>> but it will reject it because of new required functionality. >>> Likewise >>> >>> it seems that "before version negotiation" has been prompted by the >>> >>> email discussion. For some, such mechanisms are integral for >>> >>> compatibility mechanisms. >>> >>> Do you have a reference to a general description of "backwards >>> >>> compatibility"? The term is used alot but I don't know any description >>> >>> other than that in H.248.1. For example H.248.1 section 11.3 >>> >>> Negotiation of Protocol Version offers rules for new versions. ie. >>> >>> /When extending the protocol with new versions, the following >>> rules >>> >>> should be followed:/ >>> >>> /1) Existing protocol elements, i.e., procedures, parameters, >>> >>> descriptor, property, values, should/ >>> >>> /not be changed unless a protocol error needs to be corrected or >>> it >>> >>> becomes necessary to/ >>> >>> /change the operation of the service that is being supported by >>> the >>> >>> protocol./ >>> >>> /2) The semantics of a command, a parameter, a descriptor, a >>> >>> property, or a value should not be/ >>> >>> /changed./ >>> >>> /3) Established rules for formatting and encoding messages and >>> >>> parameters should not be/ >>> >>> /modified./ >>> >>> /4) When information elements are found to be obsolete they can >>> be >>> >>> marked as not used./ >>> >>> /However, the identifier for that information element will be >>> marked >>> >>> as reserved. In that way/ >>> >>> /it cannot be used in future versions./ >>> >>> These rules were adopted to ensure backwards compatibility. I think >>> >>> these rules are equally applicable to the case of profiles. When the >>> >>> MGC and MG agree on the use of a control association they agree on >>> the >>> >>> H.248.1 version and the profile (including version). >>> >>> Regards, Christian >>> >>> CHATRAS Bruno RD-CORE-ISS wrote: >>> >>>> Hello Chirstian, >>>> >>>> My understanding is that backward compatibility in the work item >>>> >>> description was intended to refer to the ability for version n+1 to >>> >>> understand version n without requiring version negotiation to occur >>> >> before. >> >> >>> This is usually what is meant in other ITU-T and ETSI standards >>> >>> dealing with signalling. >>> >>>> Best Regards, >>>> >>>> Bruno >>>> >>>> -----Message d'origine----- >>>> >>>> De : Christian Groves [mailto:Christian.Groves@NTECZONE.COM] >>>> >>>> Envoyé : lundi 23 avril 2007 02:58 >>>> >>>> À : TISPAN_WG3(a)LIST.ETSI.ORG >>>> >>>> Objet : Re: H.248 Ia Profile Version 2 >>>> >>>> Hello Bruno, >>>> >>>> What was the definition of "backward compatibility" that the work >>>> >>>> item >>>> >>> description assumed? It seems that people have different interpretations. >>> >>>> Regards, Christian >>>> >>>> CHATRAS Bruno RD-CORE-ISS wrote: >>>> >>>>> This is version negotiation, not backward compatibility.... Both >>>>> >>> approaches are valid protocol design approaches and have their pros >>> >>> and cons. However, the Work Item description assumed "backward >>> >>> compatibility between version 1 and 2... >>> >>>>> -----Message d'origine----- >>>>> >>>>> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM] Envoyé : vendredi 20 >>>>> >>>>> avril 2007 04:09 À : TISPAN_WG3(a)LIST.ETSI.ORG Objet : Re: H.248 Ia >>>>> >>>>> Profile Version 2 >>>>> >>>>> Agree Albrecht's state. >>>>> >>>>> When a BGF registers with a ProfileID "ETSI_BGF/1" 0r >>>>> >>>>> "ETSI_BGF/2", >>>>> >>> corresponding ia profile(ia/2 or ia/1) should be applied. >>> >>>>> I think the Profile-based backward compatibility between ia/2 >>>>> and >>>>> >>> ia/1 is based on their functions. Ia/2 can realize all the functions >>> >>> of Ia/1, but new better methods can be used, even it is mandatory. >>> >>>>> BR >>>>> >>>>> Neal >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE] >>>>> >>>>> Sent: Thursday, April 19, 2007 6:50 PM >>>>> >>>>> To: TISPAN_WG3(a)LIST.ETSI.ORG >>>>> >>>>> Subject: Re: H.248 Ia Profile Version 2 >>>>> >>>>> [Sorry for using your initials as abbreviation BC for backward >>>>> >>>>> compatibility :-)] >>>>> >>>>> I do agree to your statement. >>>>> >>>>> Important here is the "scope of the protocol" in my understanding. >>>>> >>>>> There would be a compatibility issue when the SPDF & BGF would >>>>> >>>>> operate >>>>> >>> Ia interface in the "NoProfile" mode, i.e. the BGF would not include >>> >>> the ServiceChangeProfile parameter for registration. >>> >>>>> But the protocol scope is limited when registering with a >>>>> ProfileID >>>>> >>>>> (as >>>>> >>> in case of ES 283 018). There are then only "ETSI_BGF/1" or "ETSI_BGF/2" >>> >>>>> H.248 Messages between a single SPDF-BGF tandem. >>>>> >>>>> I think that this is the crucial point concerning "protcol scope" >>>>> >>>>> for >>>>> >>>>> H.248 >>>>> >>>>> interface: "Profile-less" vs "Profile-based" operated H.248 >>>>> Control >>>>> >>> Associations. >>> >>>>> Albrecht >>>>> >>>>> "CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS" To: "Neal >>>>> >>>>> ZhuNing" <zhuning(a)huawei.com>, >>>>> <Albrecht.Schwarz(a)ALCATEL-LUCENT.DE> >>>>> >>>>> <bruno.chatras@orange-f cc: >>>>> >>>>> <TISPAN_WG3(a)LIST.ETSI.ORG> >>>>> >>>>> tgroup.com> Subject: RE: >>>>> >> H.248 >> >> >>> Ia >>> >>>>> Profile Version 2 >>>>> >>>>> 19.04.2007 12:28 >>>>> >>>>> Adding a mandatory parameter to version n+1 of a protocol means >>>>> that >>>>> >>>>> a >>>>> >>> message conforming to the version n of this protocol is not a valid >>> >>> message for an implementation conforming to version n+1 of this >>> >>> protocol. Is not this a compatobility issue? >>> >>>>> BC >>>>> >>>>> -----Message d'origine----- >>>>> >>>>> De : Neal ZhuNing [mailto:zhuning@huawei.com] Envoyé : jeudi 19 >>>>> >>>>> avril >>>>> >>>>> 2007 11:55 À : Albrecht.Schwarz(a)ALCATEL-LUCENT.DE; CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS Cc : TISPAN_WG3(a)LIST.ETSI.ORG Objet : RE: H.248 Ia >>>>> >>>>> Profile Version 2 >>>>> >>>>> Hi Albrecht, Bruno, >>>>> >>>>> In Ia/1, the hierarchical termination name does not >>>>> specifically >>>>> >>> mention that it is used to identify the IP domain that a termination >>> >>> is connected to, nor does it give an example of the syntax >>> associated >>> >>> with the "interface". So maybe there is no backward compatibility on >>> >>> this >>> >> issue. >> >> >>>>> In Ia/2, the hierarchical termination name may still be used to >>>>> >>> specify which physical or logical interface a termination should be >>> >>> associated with in the MG. >>> >>>>> So, the hierarchical termination name mechanism is same in Ia/1 >>>>> and >>>>> >>> Ia/2, there is no backward compatibility problem. >>> >>>>> BR >>>>> >>>>> Neal >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE] >>>>> >>>>> Sent: Thursday, April 19, 2007 5:21 PM >>>>> >>>>> To: TISPAN_WG3(a)LIST.ETSI.ORG >>>>> >>>>> Subject: Re: H.248 Ia Profile Version 2 >>>>> >>>>> Bruno, >>>>> >>>>> when we discussed this, we couldn't see a violation of the >>>>> backward >>>>> >>> compatibility (BC) principle. >>> >>>>> The MG is registering either with Ia/1 or Ia/2, but not with both >>>>> >>> profile versions (like in a multiple profile mode), the used IP >>> >>> realm/domain indication mechanism is unambiguous. >>> >>>>> The profile principle is thus supporting BC targets. >>>>> >>>>> A single H.248 Control Association is either operated with Ia/1 or >>>>> >> Ia/2. >> >> >>>>> Do I overlook sth? >>>>> >>>>> Albrecht >>>>> >>>>> PS >>>>> >>>>> Above principle is/may also used for other "capability upgrades", >>>>> >>>>> like H.248.10 replacement by H.248.11 in a next profile version, >>>>> etc >>>>> >>>>> etc >>>>> >>>>> CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS To: >>>>> >>>>> TISPAN_WG3(a)LIST.ETSI.ORG >>>>> >>>>> <bruno.chatras@ORANGE-F cc: >>>>> >>>>> TGROUP.COM> Subject: H.248 Ia >>>>> >>>>> Profile Version 2 >>>>> >>>>> 19.04.2007 11:12 >>>>> >>>>> Please respond to >>>>> >>>>> CHATRAS Bruno >>>>> >>>>> RD-CORE-ISS >>>>> >>>>> Ray, Wayne, >>>>> >>>>> I just had a look to the Latest Draft of WI03098 (Ia profile >>>>> Release >>>>> >>>>> 2) >>>>> >>> and saw that support of the new IPDC package is mandatory rather >>> than >>> >>> optional. >>> >>>>> This contradicts the Work Item description which says explictly >>>>> that >>>>> >>> "The Ia profile version 2 shall maintain backwards compatibility >>> with >>> >>> version 1." The meeting reports says that adding the IPDC package >>> was >>> >>> indeed agreed but does not say whether it should be mandatory or >>> >> optional. >> >> >>> I believe that we should either make this package optional or made >>> an >>> >>> attempt to modify the Work Item description. I assume we can't >>> approve >>> >>> a deliverable which explicitly contradicts a Work Item description. >>> >>>>> BTW, what is the procedure for TB approval of this modification. >>>>> >>>>> There >>>>> >>> does not seem to be any CR corresponding to this modification (just >>> a >>> >>> contribution). >>> >>>>> Best regards >>>>> >>>>> Bruno >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>>> >>>>> http://list.etsi.org/TISPAN_WG3.html >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> >>>> ------------------------------------------------------------------- >>>> >>>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>>> >>>> http://list.etsi.org/TISPAN_WG3.html >>>> >>>> ------------------------------------------------------------------- >>>> >>> ------------------------------------------------------------------- >>> >>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>> >>> http://list.etsi.org/TISPAN_WG3.html >>> >>> ------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------- >>> >>> Mail archive for TISPAN_WG3 can be browsed at the following url : >>> >>> http://list.etsi.org/TISPAN_WG3.html >>> >>> ------------------------------------------------------------------- >>> >> >> >> >> >> -- >> >> Alcatel-Lucent Deutschland AG >> >> Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 >> Vorsitzender des Aufsichtsrats: Michael Oppenhoff >> >> Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen >> Poesinger, Alf Henryk Wulf >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------------- >> >> Mail archive for TISPAN_WG3 can be browsed at the following url : >> >> http://list.etsi.org/TISPAN_WG3.html >> >> ------------------------------------------------------------------- >> >> > > > [attachment "iprealm_update.doc" deleted by Albrecht SCHWARZ/DE/ALCATEL]

3 5

[itu-sg16] Input documents
by OKUBO Sakae 20 Jun '07

20 Jun '07

Dear WP2/16 experts, The following input documents have been placed at the avc-site for assisting your advance review, whose list and links are given at: http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html At 10:35 +0800 07/06/15, Xiaolin jiang wrote: >Would you please consider uploading the contributions as attached to >the website for the coming SG16 meeting? - Proposal a New Question to Study the Service/User Identification and Control - Proposal on Extending the Study Scope of Question 5 in Next Study Period - Proposal for the Overview of Draft New H.Proxy At 13:00 +1000 07/06/15, Christian Groves wrote: >Please find attached the following 4 TDs for upload to the advance >review directory: > >R_TD-WP2-xxx_H248_47amm1.zip "Draft new H.248.47 Amendment 1 >"Statistic Conditional Reporting Package: Explicit timestamp >notification enhancement" > >R_TD-WP2-xxx_H248_49.zip "Draft new Recommendation H.248.49 >“/Session Description Protocol RFC and Capabilities Packages/” > >R_TD-WP2-xxx_H248_living_list.zip "H.248.1v4 Living List" > >R_TD-WP2-xxx-HSupp2_Packages_Guide.zip "Draft revised H Series >Supplement 2, “H.248.x sub-series packages guide ミ Release 10” > >Could you please place then in the appropriate directory? -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 6

[itu-sg16] Input documents for the SG16 meeting
by OKUBO Sakae 14 Jun '07

14 Jun '07

Dear WP2/16 experts, The following input documents have been placed at the avc-site for assisting your advance review, whose list and links are given at: http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html At 16:43 +0200 07/06/14, Arturo Martin De Nicolas (AC/EDD) wrote: >Please consider attached Temporary Document from Editor for upcoming >SG16 meeting 26th June - 6th July. ==> H.248.8 At 17:26 +0100 07/06/14, <geoff.hunt(a)bt.com> wrote: >I have just submitted the following document via the SG16 document >submission system, which gave it the filename >T16_S_20070614181842_1.doc. ==> H.248.48 > >I'm also sending it to you in this mail, as requested in your email of 30-May. > >This document is identical to the output document TD-61 from the >Shenzhen meeting, which Christian produced on my behalf. > >I intend to submit some contributions during tomorrow. At 10:17 -0700 07/06/14, Brody Kenrick wrote: >Please add this contribution to the advance review repository. (It >has been made available as C.142 through TIES also.) ==> "H.325" >discussion At 09:20 +0800 07/06/15, Simon Horne wrote: >The 5 documents are as follows: > >Question 2 >AVD-2905.zip Proposed new H.460.x "Text Messaging within H.323 >systems" (resubmitted no changes) > >Question 5 (both updated from rapporteurs meeting submission) >h460nat1.zip Proposed new H.460.x "Network Address Translator and >Firewall device determination in H.323 Systems" >h460nat2.zip Proposed new H.460.y "Point to Point Media through >Network Address Translators and Firewalls in H.323 Systems" > >Question 21 >h325nat.zip NAT Traversal Considerations for an Advanced >Multimedia System (AMS) >h325sec.zip Security Considerations for an Advanced Multimedia >System (AMS) -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: [itu-sg16] ITU-T SG 16 WP2 Q21 two Contributions Submission
by OKUBO Sakae 14 Jun '07

14 Jun '07

Dear Mr Kang, At 22:08 +0900 07/06/14, ーュナツアヤ wrote: >I would like to submit my two contributions with attched files. They have been placed at the avc-site for the experts' advance review. http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html 1_tgkang_Itu_2007_6.zip ETRI Terminal related Signalling Issues for H.325 2_tgkang_Itu_2007_6.zip ETRI Visible Light Communication Signalling Issues for H.325 -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

[itu-sg16] Contributions to the SG16 meeting
by OKUBO Sakae 13 Jun '07

13 Jun '07

Dear WP2/16 experts, At 10:43 -0400 07/06/11, Christian Schlatter wrote: >I've attached the documents to this email. Simao told me that >they'll be uploaded soon. At 17:04 +0200 07/06/13, Arturo Martin De Nicolas (AC/EDD) wrote: >Please consider attached contribution from Ericsson for upcoming >SG16 meeting 26th June - 6th July. They have been or will soon be made formally available at the ITU-T meeting documents site <http://www.itu.int/ITU-T/meetingdocs/index.asp>. To assist your advance reviewing, they are placed at the avc-site: http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

[itu-sg16] Fwd:Initial WP2/16 time schedule during 26 June - 6 July
by OKUBO Sakae 12 Jun '07

12 Jun '07

*** Apologies for this duplicated posting to the 2 lists *** Dear WP2/16 experts, I have placed an *initial* time schedule for various Questions at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/WP2_plan_070612.pdf You can reach this from the index page as well: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html Please note that this plan is *subject to change* depending on the number of input documents and other factors. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Initial WP2/16 time schedule during 26 June - 6 July
by OKUBO Sakae 12 Jun '07

12 Jun '07

Dear WP2/16 experts, I have placed an *initial* time schedule for various Questions at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/WP2_plan_070612.pdf You can reach this from the index page as well: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html Please note that this plan is *subject to change* depending on the number of input documents and other factors. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Initial WP2/16 time schedule during 26 June - 6 July
by OKUBO Sakae 12 Jun '07

12 Jun '07

Dear WP2/16 experts, I have placed an *initial* time schedule for various Questions at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/WP2_plan_070612.pdf You can reach this from the index page as well: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/0706_Gen.html Please note that this plan is *subject to change* depending on the number of input documents and other factors. -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

RE: Question about report of Q.22/16 from last SG16 meeting (November 2006))
by 이준섭 08 Jun '07

08 Jun '07

Dear all member of Q.22/16 Is anybody can answer to my questions below? Thanks in advance. Best regards, Jun Seob Lee ______________________________________________________________ Jun Seob Lee Senior Engineer Next Generation Internet Standardization (NGIS) Team Protocol Engineering Center (PEC) Electronics and Telecommunications Research Institute (ETRI) 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Office Tel: +82-42-860-3859 Office Fax: +82-42-861-5404 E-mail: juns(a)etri.re.kr <mailto:juns@etri.re.kr> MSN Messenger: jun(a)korea.com <mailto:jun@korea.com> Homepage: www.joojun.com <http://www.joojun.com/> ________________________________ From: 이준섭 Sent: Thursday, June 07, 2007 12:39 PM To: 'noah(a)huawei.com' Subject: Question about report of Q.22/16 from last SG16 meeting (November 2006)) Dear Rapporteur of Q.22/16, I'm Jun Seob Lee from ETRI, Korea. I'm very interested in NID activities in your rapporteur group. (I'm the rapporteur of ASTAP NID Expert Group) In your rapporteur group meeting report (TD413 R1), your group had a plan to consent 4 new recommendation on NID by July 2007 and April 2008. But, in your report, your group did not assign any editor for those new recommendations. Can I know the current status about NID related new recommendations? And, in the meeting report of WP2/16, your group will have meeting before SG16 meeting in June 2007. Did you have a meeting? If you had a meeting, can I get a meeting report? I'll prepare some contribution on NID in SG16 meeting. See you in Geneva. Best regards, Jun Seob Lee ______________________________________________________________ Jun Seob Lee Senior Engineer Next Generation Internet Standardization (NGIS) Team Protocol Engineering Center (PEC) Electronics and Telecommunications Research Institute (ETRI) 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Office Tel: +82-42-860-3859 Office Fax: +82-42-861-5404 E-mail: juns(a)etri.re.kr <mailto:juns@etri.re.kr> MSN Messenger: jun(a)korea.com <mailto:jun@korea.com> Homepage: www.joojun.com <http://www.joojun.com/>

3 6

FW: Possible error in ITU-T H.224 (Figure 3)
by Patrick Luthi 04 Jun '07

04 Jun '07

Dear experts, I have been made aware of a possible error in H.224 when supporting more than one client. Most of the implementations I know about only support 1 client (H.281 FECC), but there some implementations that also support T.140 and non-standards clients. After consulting with the H.224 editor, we concluded that a typographical error was likely introduced in figure 3 in the first version of H.224. In the earliest complete draft of H.224 that we could find (dated 9 September 1993 see attached), Figure 3 is already present, and clearly the "number of clients" field is NOT supposed to be repeated. In order to correct this, I would like to receive feedback from manufacturers that have implemented more than one (1) H.224 client to understand if implementations follow: 1) the more logical method of the attached MS-HDLL document (bracket does NOT include the "number of clients" field) or, 2) the published Figure 3/H.224 method (bracket includes the "number of clients" field). Once I understand the backward compatibility impacts of a possible correction, I will submit a proposed corrigendum document to the upcoming meeting of SG16 (26 June-6 July). Thank you and best regards, Patrick Luthi Rapporteur for Q.1/16 > This mail has been sent from the ITU web site to itumail : > >Subject > >ITU Website feedback > > >UserLanguage > >English > >MessageType > >Problem > >Name > >Daniele Paccaloni > >Subject > >Possible error in ITU-T H.224 (Figure 3). > >Comments > >Hello, > >We would like to report a possible error in H.224 which could cause >severe incompatibilities between terminals supporting more than one Client. > >The possible error is in Figure 3/H.224 (all revision up to the latest): >We think that the \"number of clients\" byte should NOT be repeated >\"For each client\". >Since the \"number of clients\" byte indicates how many entries are >in the following client list, we believe it should not be repeated >for each client entry in the list. > >Note that this problem may have remained undetected for years since >most terminals only support 1 client (H.281 FECC). > >Please let us know if you plan to correct this, or not (for backward >compatibility reasons). > >Thank you, > >.daniele _____________________________ Patrick Luthi Manager, Technical Standards Rapporteur (chairman) for the ITU-T multimedia systems, terminals and data-conferencing Experts group (Question 1/16) TANDBERG N-1366 Lysaker, Norway Phone: + 47 67 125 125 Direct: +41 21 801 8420 e-mail: patrick.luthi(a)tandberg.com <http://www.tandberg.com/> http://www.tandberg.com

1 0