Subject: [Megaco] Q.1400 compatibility rules; RE: H.248 Ia Profile Version 2

From: [email-masked]
Date: Tue, 24 Apr 2007 17:06:29 +0200

[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\)" <[email-masked]>,          
                      <drage@alcatel-l         <[email-masked]>                                                               
                      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:[email-masked]]
> Sent: Tuesday, April 24, 2007 1:08 AM
> To: [email-masked]
> 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:
> [email-masked]
>
>                       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:[email-masked]]
> > Envoyé : lundi 23 avril 2007 02:58
> > À : [email-masked]
> > 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:[email-masked]] Envoyé : vendredi 20
> >> avril 2007 04:09 À : [email-masked] 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:[email-masked]]
> >> Sent: Thursday, April 19, 2007 6:50 PM
> >> To: [email-masked]
> >> 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" <[email-masked]>, <[email-masked]>
> >>                       <bruno.chatras@orange-f         cc:
> >> <[email-masked]>
> >>
> >>                       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:[email-masked]] Envoyé :
> jeudi 19 avril
> >> 2007 11:55 À : [email-masked]; CHATRAS Bruno
> >> RD-CORE-ISS Cc : [email-masked] 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:[email-masked]]
> >> Sent: Thursday, April 19, 2007 5:21 PM
> >> To: [email-masked]
> >> 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:
> >> [email-masked]
> >>
> >>                       <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
> -------------------------------------------------------------------
>

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Jerker Zetterlund \(TN/EAB\)" <[email-masked]>
Date: Wed, 25 Apr 2007 10:06:47 +0200

Hello,

I agree the question of compatibility between profile versions needs to be clarified. H.248.1 is not very clear on the meaning of different versions of a profile. Annex F does not say how profile version negotiation should work and 11.3 talks about protocol version negotation but does not say anything about profile version negotiation. If the intention of H.248.1 is that profile version negotiation should work the same way as protocol version negotiation then I think this needs to be made more clear in H.248.1.

My understanding of profile versions is that backwards compatibility is required for the purpose of in-service upgrade. But I don't see a need for general backwards compatibility. Backwards compatibility for upgrade means that e.g. termination name structure cannot be changed between two versions of a profile, but mandatory packages can be added. (I think this is why we added the new ipdc/realm property to Ia v2 but did not remove the <interface> field from the termination ID.)

The whole idea with using profiles is that both ends use the same set of optional parts of the protocol so that interoperability is ensured. The more precise a profile is, the better the interoperability can be expected to work. So I think it is reasonable to say that if a profile shall be used, both ends must support the same version. This approach keeps down the flexibility of the profiles and should make interoperability easier once a common profile with common version has been agreed. And this is why a profile is used in the first place.

As Albrecht pointed out earlier, H.248.18 can be used if multiple different profiles are supported and negotiation is needed. H.248.18 also includes version of each profile so it can be used for profile version negotaition.

BR

Jerker

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 24 april 2007 17:06
To: Drage, Keith (Keith)
Cc: [email-masked]; [email-masked]; Christian Groves
Subject: [Megaco] Q.1400 compatibility rules; RE: H.248 Ia Profile Version 2

[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                                                                                                     

Regards

Keith

> 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.
> a) integral mechanism for protocol version negotiation and in addition 
> a
> 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.
>
> We got four WIs for H.248 Profiles, - a MG registration with the 
> correspondent ProfileID is part of a profile specification.
> 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:
> [email-masked]
>
>                       ECZONE.COM>                  cc:
>
>
>                                                    Subject:
> 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.
>
>     /When extending the protocol with new versions, the following 
> rules
>     should be followed:/
>     /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./
>     /However, the identifier for that information element will be 
> marked
> 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
> This is usually what is meant in other ITU-T and ETSI standards 
> dealing with signalling.
> >
> > Best Regards,
> > Bruno
> >
> 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...
> >>
> 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
> >>
> Ia interface in the "NoProfile" mode, i.e. the BGF would not include 
> the ServiceChangeProfile parameter for registration.
> 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
> >>
> 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.
> specify which physical or logical interface a termination should be 
> associated with in the MG.
> profile versions (like in a multiple profile mode), the used IP 
> realm/domain indication mechanism is unambiguous.
> and saw that support of the new IPDC package is mandatory rather than 
> optional.
> "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.
> >>
> does not seem to be any CR corresponding to this modification (just a 
> contribution).
> >>
> >> Best regards
> >> Bruno
> >>
> >>
> >>
> >>
> >>
> >>

---

From: [email-masked]
Date: Wed, 25 Apr 2007 22:01:40 +0200

>My understanding of profile versions is that backwards compatibility is
required for the purpose of in-service >upgrade. But I don't see a need for
general backwards compatibility. Backwards compatibility for upgrade means
that

Jerker, I do agree that "in-service" upgrade will be one of the key aspects
concerning backward/forward compatibility.

Like to share some initial thoughts on this subject:

Q1    Is this related to the ServiceState of the ROOT Termination only
(i.e., ROOT remains in ServiceState = IS during upgrade), or do we've to
consider non-ROOT Terminations in addition?

Q2    Is it all related to ServiceState of Terminations, or just to the
Control Association (CA)?

Q3    If CA: there isn't so far any state model for the CA, i.e. what does
"in-service" means from CA perspective?

Q4    Assuming ROOT and non-ROOT terminations to be considered, there might
be a difference between ephemeral-only MGs and MGs with a NULL Context.

Q5    "In-service upgrades" for non-ROOT terminations: this is firstly an
implementation issue, if an implementation has problems, one mitigation
possibility might be to use periods with
a) a minimum of ephemeral terminations in-service,
b) a maximum of physical terminations in the Null Context or/and
c) putting the Null Context terminations in OoS state during an "upgrade
procedure",
i.e., using a period with a minimum of active calls or bearer connections
respectively.

Q6    Capability upgrade: there might be differences between a "major
upgrade" and a "minor upgrade" (leaving firstly definitions for major and
minor aside)?
Note: a definition could be based on "H.248 Context processing", i.e.
"minor" allows a continuation of operations for existing and/or new
Contexts, whereas "major" does suppose that not new Context could be
created, or even that existing Contexts must be released before an upgrade
procedure.

Q7    Is there a requirement for "stable Context preservation" during
"in-service upgrades"? ... which translates to "stable call preservation"
and "stable bearer preservation" on MGC and MG level respectively.

Q7    Let's consider following scenario: there are N active Contexts at the
point of time of upgrade, and there is a requirement for stable context
preservation, when the Context was established with a version k
protocol/profile, and must be again successfully relased with version k+1
elements.

   => the more I think about the "Q7 scenario" (taking into account
   significant data structure changes like TerminationIDs), the more I
   think it's technically feasible, thus "just" an implementation issue.
   => I fail to see how we could argue from protocol point of view against
   "implementation issues"? Might be a too theoretical view ...

Q8    Finally: difference between "Q.1400 entities" and "H.248 entities"
      => my understanding: Q.1400 is supposing that a version k node may
continue to operate with a version k+1 node after capability upgrades
      => whereas in case of H.248: there is an explicit mutual agreement
between both nodes to continue with version k+1 after a successfull upgrade
("the mutual agreement relates to the successfully processed ServiceChange
procedures concerning "service change")

Just some initial thoughts. (I'm still optimistic that we could find useful
text for compatibility rules for H.248 :-).

Albrecht

                      "Jerker Zetterlund                                                                                                     
                      \(TN/EAB\)"                   To:      <[email-masked]>, "Drage, Keith \(Keith\)"                  
                      <jerker.zetterlund@er         <[email-masked]>                                                               
                      icsson.com>                   cc:      [email-masked], [email-masked], Christian Groves                     
                                                    <[email-masked]>                                                          
                      25.04.2007 10:06              Subject: RE: [Megaco] Q.1400 compatibility rules;  RE: H.248 Ia Profile Version 2        

 Hello,

I agree the question of compatibility between profile versions needs to be
clarified. H.248.1 is not very clear on the meaning of different versions
of a profile. Annex F does not say how profile version negotiation should
work and 11.3 talks about protocol version negotation but does not say
anything about profile version negotiation. If the intention of H.248.1 is
that profile version negotiation should work the same way as protocol
version negotiation then I think this needs to be made more clear in
H.248.1.

My understanding of profile versions is that backwards compatibility is
required for the purpose of in-service upgrade. But I don't see a need for
general backwards compatibility. Backwards compatibility for upgrade means
that e.g. termination name structure cannot be changed between two versions
of a profile, but mandatory packages can be added. (I think this is why we
added the new ipdc/realm property to Ia v2 but did not remove the
<interface> field from the termination ID.)

The whole idea with using profiles is that both ends use the same set of
optional parts of the protocol so that interoperability is ensured. The
more precise a profile is, the better the interoperability can be expected
to work. So I think it is reasonable to say that if a profile shall be
used, both ends must support the same version. This approach keeps down the
flexibility of the profiles and should make interoperability easier once a
common profile with common version has been agreed. And this is why a
profile is used in the first place.

As Albrecht pointed out earlier, H.248.18 can be used if multiple different
profiles are supported and negotiation is needed. H.248.18 also includes
version of each profile so it can be used for profile version negotaition.

BR

Jerker

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: den 24 april 2007 17:06
To: Drage, Keith (Keith)
Cc: [email-masked]; [email-masked]; Christian Groves
Subject: [Megaco] Q.1400 compatibility rules; RE: H.248 Ia Profile Version
2

Albrecht

                      "Drage, Keith

                      \(Keith\)"               To:      "Schwarz, Albrecht
\(Albrecht\)" <[email-masked]>,
                      <drage@alcatel-l         <[email-masked]>

                      ucent.com>               cc:

                                               Subject: RE: H.248 Ia
Profile Version 2
                      24.04.2007 12:07

Regards

Keith

---

From: "Jerker Zetterlund \(TN/EAB\)" <[email-masked]>
Date: Fri, 27 Apr 2007 10:12:27 +0200

Hello Albrecht,

"In-service" upgrade probably can have various meanings in various situations. I had a scenario in mind where MGC and MG are independently upgraded with new functionality (and therefore must step up the profile version used) while beeing in-service or just experiencing a brief stop in processing SIP and/or H.248. Once the MG upgrade is completed, the MG would issue a Root ServiceChange with a new profile version to indicate the new capabilities. If the MGC has already been upgraded and supports the new higher profile version, the control association will make use of the higher profile version.

Based on this scenario I'll give you my views on your thoughts below.

Jerker

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 25 april 2007 22:02
To: Jerker Zetterlund (TN/EAB)
Cc: [email-masked]
Subject: RE: [Megaco] Q.1400 compatibility rules; RE: H.248 Ia Profile Version 2

>My understanding of profile versions is that backwards compatibility is
required for the purpose of in-service >upgrade. But I don't see a need for general backwards compatibility. Backwards compatibility for upgrade means that

Jerker, I do agree that "in-service" upgrade will be one of the key aspects concerning backward/forward compatibility.

Q1    Is this related to the ServiceState of the ROOT Termination only
(i.e., ROOT remains in ServiceState = IS during upgrade), or do we've to consider non-ROOT Terminations in addition?
[JZ]	The non-ROOT terminations should keep their ServiceStates, and maybe the ROOT should do that as well.

Q2    Is it all related to ServiceState of Terminations, or just to the
Control Association (CA)?
[JZ]	I think it could either be mapped to ServiceStates of ROOT or alternatively to service state of CA. I guess there are pros and cons of both approaches.

Q3    If CA: there isn't so far any state model for the CA, i.e. what does
"in-service" means from CA perspective?
[JZ]	Good question. It could be connected to the behaviour of the transport layer or of H.248 layer.

Q4    Assuming ROOT and non-ROOT terminations to be considered, there might
be a difference between ephemeral-only MGs and MGs with a NULL Context.
[JZ]	I don't think non-ROOT terminations should be considered.

Q5    "In-service upgrades" for non-ROOT terminations: this is firstly an
implementation issue, if an implementation has problems, one mitigation possibility might be to use periods with
a) a minimum of ephemeral terminations in-service,
b) a maximum of physical terminations in the Null Context or/and
c) putting the Null Context terminations in OoS state during an "upgrade procedure", i.e., using a period with a minimum of active calls or bearer connections respectively.

Q6    Capability upgrade: there might be differences between a "major
upgrade" and a "minor upgrade" (leaving firstly definitions for major and minor aside)?
Note: a definition could be based on "H.248 Context processing", i.e.
"minor" allows a continuation of operations for existing and/or new Contexts, whereas "major" does suppose that not new Context could be created, or even that existing Contexts must be released before an upgrade procedure.
[JZ]	If existing contexts need to be released before the updgrade procedure, then the upgrade does not fit into the meaning of in-service upgrade as I mentioned at top. 

[JZ]	Yes, I think so.

Q7    Let's consider following scenario: there are N active Contexts at the
point of time of upgrade, and there is a requirement for stable context preservation, when the Context was established with a version k protocol/profile, and must be again successfully relased with version k+1 elements.

[JZ]	I agree this type of upgrade may be complicated from an implementation point of view. And as you say, it is crucial that data structures are kept.

Q8    Finally: difference between "Q.1400 entities" and "H.248 entities"
      => my understanding: Q.1400 is supposing that a version k node may continue to operate with a version k+1 node after capability upgrades
      => whereas in case of H.248: there is an explicit mutual agreement between both nodes to continue with version k+1 after a successfull upgrade ("the mutual agreement relates to the successfully processed ServiceChange procedures concerning "service change")
[JZ]	For H.248 profiles, I think this was our interpretation in the drafting session in TISPAN in March. But I think this is what we would need to get clarified.

Just some initial thoughts. (I'm still optimistic that we could find useful text for compatibility rules for H.248 :-).
[JZ]	Yes, there are many aspects on this... I think it would be really good if we could get a set of rules for this!

Albrecht

                      "Jerker Zetterlund                                                                                                     

 Hello,

BR

Jerker

-----Original Message-----

Albrecht

                      "Drage, Keith

                      ucent.com>               cc:

Regards

Keith

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Apr 2007 16:13:36 +1000

Hello Jerker,

Please see my responses below.

Regards, Christian

> I agree the question of compatibility between profile versions needs to be clarified. H.248.1 is not very clear on the meaning of different versions of a profile. Annex F does not say how profile v…
[CNG] I'll be happy to propose some IG text on this. I believe the text 
in H.248.1 sect 11.3 around additions to the protocol are valid for the 
protocol itself, as well as packages and profiles. We used these rules 
when doing up versioning of packages.
> My understanding of profile versions is that backwards compatibility is required for the purpose of in-service upgrade. But I don't see a need for general backwards compatibility. Backwards compati…
[CNG] Not sure about the distinction here about general backwards 
compatibility because I think BC still means different things to 
different people. My understanding of why <interface> is still included 
because I can also specify a physical interface on a MG in terms of that 
MGs naming schemes. The ipdc/realm property is used purely to explicitly 
specify the IP domain. The <interface> isn't able to do this.
> The whole idea with using profiles is that both ends use the same set of optional parts of the protocol so that interoperability is ensured. The more precise a profile is, the better the interoperability can be expected to work. 
[CNG] I agree.
> So I think it is reasonable to say that if a profile shall be used, both ends must support the same version. This approach keeps down the flexibility of the profiles and should make interoperability easier once a common profile with common version has been agreed. And this is why a profile is used in the first place.
>   
[CNG] I agree. H.248.1 sect 11.3 has some text regarding message 
handling and version that again I believe can be applied to profiles.