Subject: RE: [Megaco] Re: Discussion Paper and CRs on TDM Termination State Handling

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 7 Feb 2006 12:07:44 -0500

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Philip Hodges (BR/EPA) [mailto:[email-masked]] 
Sent: Monday, February 06, 2006 6:56 PM
To: Christian Groves
Cc: [email-masked]; [email-masked];
[email-masked]; Boyle, Kevin [NCRTP:3Z40:EXCH]
Subject: RE: [Megaco] Re: Discussion Paper and CRs on TDM Termination
State Handling

Hi Christian,

Comments below. 
Cheers,
Phil

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, 7 February 2006 10:05 AM
To: Philip Hodges (BR/EPA)
Cc: [email-masked]; [email-masked];
[email-masked]; Kevin Boyle
Subject: Re: [Megaco] Re: Discussion Paper and CRs on TDM Termination
State Handling

G'Day,

Quote: "is not clarified to a satisfactory degree in H.248.1 to be
implemented in the most efficient manner."

I'm not sure what is not clear about:
7.2.8.1.1 ServiceChangeMethod

"3) Restart: indicates that service will be restored on the specified
terminations after expiration of the ServiceChangeDelay. The
ServiceState should be set to "inService" upon expiry of
ServiceChangeDelay."

PHIL> the problem is that the first service change is on ROOT
termination, so why is it clear that all physical terminations
associated to the MGW (but not included in  the Service Change) are also
in Service ?

[KJBII] Because the spec says it to be so.  If you don't like it, bring
a contribution to the SG16 meeting in April.  This is the way it has
been in H.248 for more than *six years*.  Funny how this is now a
problem.

7.2.8.1.11 ServiceChange Command and Response ...
"At registration the MG may send the ServiceChangeIncompleteFlag if it
has determined that the MG is in state "InService" but individual
terminations may be in state "OutOfService". This is to prevent
attempted seizure of out-of-service terminations. Subsequent
ServiceChange commands are used to report the "OutOfService"
terminations. "

PHIL> from this the above assumption that all physical terminations are
infact inservice is clearly not agreed ! Also subsequent text that you
chose not to quote states that the MGW shall not perform any commands to
individual terminations until the flag has been reset (which Kevin in a
previous email misunderstood) so from this the MGC must wait until the
MGW says it is ready.

[KJBII] Upon review, yes, I had forgotten that the requirement was
"shall" strength.  However, this still does not get back to the main
point: 3GPP is specifying the use of H.248 in such a way that it
violates the requirements of the protocol as set forth in H.248.1.
Whether you have a seizure problem or not, by having some
implementations willingly violate the protocol, you introduce
incompatibility issues between vendors -- far more so than any
"vendor-specific" solutions that you mention below.

There's no distinction between Ephemeral and Physical terminations, it
just "terminations". Physical terminations (TDM) are not unique to
3GPP's network. Other groups have not found it necessary to re-define
the service states of terminations. Q.1950 the base of the 3gpp work
does not make this assumption. I fail to see the special mobile
requirement that justifies this change.

PHIL> I fail to see how other networks can achieve an efficient
interoperability between different vendor equipment with the assumptions
you make, given the permutations of implementation options to overcome
this (one of which you suggest below).

[KJBII] Speaking from my personal experience, it is very easy.  There
are many interoperable live deployments between various vendors'
equipment.  I believe that both Christian and I have pointed this out.
Whether your inability to see how this is possible is by choice or by
ignorance, I do not know.  Your failure to believe or understand doesn't
make it any less true.

As for interoperability I don't see how changing the ServiceState from
the default state of In-service to Out-of-Service is going to help this.

PHIL> read the 3GPP contributions.

[KJBII] You mean the ones written by the H.248 "experts"?  The ones that
specify violating the protocol?  How many of these were reviewed by
Q3/16 prior to now?

There are already many live network implementations (that implement TDM 
terminations) who work with the assumption of In-service. These MG/MGCs 
would have to change adding complexity and possible problems. I would 
have also thought that changing the default state would cause backwards 
interoperability problems.

PHIL> so I am told, but common logic tells me that circuits will either
be seized when they are not inservice and then calls will fail, or messy
implementation such as timers, flag settings, auditing, duplicate
signalling due MGW reporting OoS first, then InService afterwards..

[KJBII] "Common logic"? How about this: MGs don't come into service
until they are ready to service calls!  This is not a "messy" solution,
and it seems perfectly within the bounds of "common logic".  Oh, and
since we are talking technically here, please define "messy" for me in a
technical sense.  I generally find that to be a non-technical assessment
of a solution that is found to be a problem for one particular
implementation.  

Backwards compatibility is does ofcourse depend on the implementation of
the equipment in the network where of concern and whether the equipment
is already complying to current standards. Still I have not been pointed
to a clear statement in H.248.1 that addresses this concern. It seems
people are simply reading into it what they want to, what I am trying to
do is assess the problems with either assumption and it seems clear to
me that one assumption is far less efficient than the other.

As for v2 support I believe that if you want to avoid seizure problem 
then the MGC can implement a supervision timer at the receipt of 
Servicechange method= restart. During this supervision period the MGC 
should audit the state of any TDM termination it wants to use (whose 
state hasn't been already reported). By the end of the period the MGC 
should know all the out-of-service TDM terminations.

PHIL> so you now admit there is a problem and suggest one of a miriad of
possible vendor specific implementations that might alleviate the
problem - but in itself create more problems in the form of additional
signalling !

[KJBII] Here is a non-vendor-specific solution that I believe I am
mentioning for the third time: Don't come into service until the MG is
prepared to handle calls! There is *no* additional signalling!  There
are *no* interoperability ramifications!

Christian

Philip Hodges (BR/EPA) wrote:

>Hi,
>thankyou for you input, I am aware of the formal process. Noone has
answered the specific problems associated with treating physical
terminations with the same 'default' state behaviour as for ephemeral
terminations. It makes sense to assume ephemeral terminations are by
default in-service, it does not make sense to assume the same for
physical ones. In 3GPP we already have standards defining the MGW and
MSC Server application of the H.248.1 protocol and we will continue to
do so where it is agreed by the WG. It is through these specifications
that we ensure interoperability not through the entire implementation of
the GCP protocol. Ofcourse we should not blatantly disregard or violate
the core protocol but I do not see this particular issue as overriding
the core protocol as the interaction between MGW Register on ROOT and
the service state of physical terminations in a MGW is not clarified to
a satisfactory degree in H.248.1 to be implemented in the most efficient
manner. 
>There is no reason at all that an application cannot define in its own
specifications the default state of its own specific defined physical
terminations, it would be absurd of a Core Protocol such H.248.1 to
mandate the state of a specific type of termination that represents real
hardward that is part of an specific application.
>Regards,
>Phil
>
>-----Original Message-----
>From: Christian Groves [mailto:[email-masked]]
>Sent: Friday, 3 February 2006 3:22 PM
>To: [email-masked]
>Cc: Philip Hodges (BR/EPA); [email-masked];
>[email-masked]
>Subject: Re: [Megaco] Re: Discussion Paper and CRs on TDM Termination
>State Handling
>
>
>Hello,
>
>I would 2nd Albrecht on this. The replies from Kevin that Manfred
refers 
>to are valid. Kevin has been the editor of H.248.1 for some time now
and 
>is actively involved in both IETF Megaco and ITUSG16 so I would
consider 
>him to be one of the best H.248 experts around. However like all on the

>list he doesn't officially represent the "IETF view" nor the SG16 view.

>If you want  formal response I suggest that you liaise with ITU SG16. 
>But I must say I expect the same response as what has been given by the

>list.
>
>I am dubious of any organisation "overriding" the H.248 core 
>specification on this issue. Particularly in the area of ServiceChange.

>I don't see any "mobile" related pecularities on the ServiceChange part

>of the H.248 protocol.
>
>I would also agree with Kevins comments in that when a ServiceChange 
>indicating Cold Boot is given whether the terminations are TDM or 
>Ephemeral they are considered to be in-service. The only exception to 
>this is by using the servicechangeincomplete flag. Any other 
>implementation does not comply to the H.248.1 specification and would 
>cause unecessary interop complications.
>
>Regards, Christian
>
>[email-masked] wrote:
>
>  
>
>>Like to clarify the first point:
>> 
>>
>>    
>>
>>>Firstly I dont understand why we should take notice of an email
response
>>>   
>>>
>>>      
>>>
>>from IETF when ITU-T SG16 is the body >responsible for H.248.1 ?
>  
>
>>The IETF email list "[email-masked]" is still the conjointly used
forum
>>for H.248 topics (also by ITU-T SG16 members).
>>
>>Albrecht
>>
>>
>>
>>

>>                     "Philip Hodges

>>                     (BR/EPA)"                    To:
[email-masked]

>>                     <philip.hodges@ERICS         cc:

>>                     SON.COM>                     Subject: Re:
Discussion Paper and CRs on TDM Termination State Handling             
>>                     Sent by:

>>                     3GPP_TSG_CT_WG4 -

>>                     Core Network and

>>                     Terminals WG 4

>>                     <3GPP_TSG_CT_WG4@LIS

>>                     T.ETSI.ORG>

>>                     30.01.2006 02:33

>>                     Please respond to

>>                     "Philip Hodges

>>                     (BR/EPA)"

>>
>>
>>
>>
>>Hi Manfred, all,
>>Firstly I dont understand why we should take notice of an email
response
>>    
>>
>>from IETF when ITU-T SG16 is the body responsible for H.248.1 ?
>  
>
>>Secondly we have 3GPP specifications that already define behaviour
that
>>overrules the core protocol in certain aspects or more often makes it
more
>>specific to 3GPP applications. This is neccessary to define a real
working
>>application such as a mobile network. 3GPP has the remit to do this.
>>
>>Thirdly it is clear to me that some of the assumptions and suggestions
made
>>in this reply email are flawed. H.248.1 makes a rather general
statement on
>>handling terminations - nothing specific about physical terminations
which
>>are fundamentally different to ephemeral ones. There is no reason why
all
>>emphemeral terminations are not inservice, but there are reasons why
>>physical terminations have not come into service yet. If the rule is
that
>>the MGW shall not report itself as re-booted until all terminations
are
>>inservice then what does it do when some terminations are not
inservice ?
>>Consider itself still completely out-of-service ? No - that would be
>>stupid. So it waits until some/most (what rule ?) are inservice. While
>>waiting for physical terminations to come into service the ephemeral
ones
>>cannot be used either. Then, how does the MGC know which ones are in
>>service ? It doesnt, so in Nokia/Nortel's oppinion it audits. Then it
must
>>audit all = wasteful signlling/processing. BUT only the MGW knows
which are
>>inservice (and which are not) so the MGW should inform of this. BUT
then
>>when does the MGW know that it has been informed that all are reported
?
>>(well in v3 it uses the incomplete flag..so in version 3 the MGW
doesnt do
>>any audits). So why audit in early versions when it would have to
audit all
>>? Why assume terminations are inservice when you still have to wait
until
>>told by the MGW that it has finished telling the server about all of
the
>>out-of-service terminations (in  v3) ?
>>
>>Consider the backward compatibility with a MGW that implements service
>>change incomplete flag and a server that doesnt: According to the
Nokia CR
>>the MSC server 'may' audit the terminations before using them
(otherwise it
>>just goes ahead and if seizes a blocked trunk the call will fail).
Thus if
>>the server performs an audit and gets blocked it will also get a
service
>>change notification from the MGW that it is blocked. If the trunk is
not
>>blocked then it performs an unneccessary audit but atleast knows the
state
>>before trying to seize the termination. If it doesnt perform an audit
then
>>it may get told the termination is blocked before it tries to seize it
(if
>>it is lucky).
>>
>>The Ericsson approach is much more accurate (no hit and miss or
duplicate
>>signalling) and is independant of v3 protocol solution.
>>
>>I hope we can hear from other companies on this matter as it seems
clear
>>the difference of opinion between Nokia and Ericsson :-)
>>Cheers,
>>Phil
>>
>>
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: Friday, 27 January 2006 9:37 PM
>>To: Philip Hodges (BR/EPA); [email-masked]
>>Subject: RE: Discussion Paper and CRs on TDM Termination State
Handling
>>
>>
>>Hi Nigel and Phil,
>>
>>We also think that we should make some principles. And we think they
>>should not violate H.248 base protocol.
>>That's why I asked advice from the MEGACO maillist for the cases for
>>which we have different views.
>>These are MGW registration (Service Change Method=restart, Service
>>Change reason = Cold Boot),
>>MGW warm boot (Service Change Method=restart, Service Change reason =
>>Warm Boot),
>>MGW restoration (Service Change Method=restart, Service Change reason
=
>>Service Restored) and
>>MGW Communication up (Service Change Method=Disconnected, Service
Change
>>reason = Service Restored).
>>Attached the answers I received from Kevin Boyle (the mails are also
>>included under reference 8 and 9 in our contribution).
>>I used these answers when I wrote our contribution, so I think our
>>contribution is in line with these
>>principles.
>>
>>We think the assumption that the MSC Server should assume that all
>>physical terminations are out-of-service
>>when the MGW registers with cold boot clearly violates H.248. H.248
says
>>clearly and Kevin Boyle confirms this
>>in the attached mail exchange, that all physical terminations are
>>assumed to be in service by MGC after MGW cold boot.
>>That means if a MGW powers its physical terminations up before it
sends
>>registration with cold boot,
>>it needs to send after the accepted cold boot registration,
termination
>>out of service messages for these physical
>>terminations it has still out of service (if any).
>>If a MGW powers all its physical terminations up after it sends
>>registration with cold boot, then the MGW needs to send
>>for all physical terminations termination out of service messages and
>>later when it has powered them up it needs to
>>send termination restoration messages.
>>These are the 2 different extreme MGW implementation options,
everything
>>between is of course also possible.
>>
>>br manfred
>>
>>
>> 
>>
>>    
>>
>>>-----Original Message-----
>>>From: 3GPP_TSG_CT_WG4 - Core Network and Terminals WG 4
>>>[mailto:[email-masked]] On Behalf Of ext Philip
>>>Hodges (BR/EPA)
>>>Sent: 27 January, 2006 01:38
>>>To: [email-masked]
>>>Subject: Re: Discussion Paper and CRs on TDM Termination State
Handling
>>>
>>>Hi Nigel,
>>>thanks for the informative response. I agree that we should
>>>make some principles. This is what we aimed to do with our
>>>contribution, basically:
>>>
>>>1. If and when the MGW knows the state/change of state it
>>>tells the Server - this is the case for MGW registration, MGW
>>>restart, device recovery, device connection.
>>>2. If the Server is unsure of the state (MSC restart, MSC
>>>Ordered MGW Re-registration, device connection) then it
>>>audits, but only when it will not get informed from the MGW.
>>>
>>>As for existing implementations we should consider the current
>>>specs which make it mandatory to support and use the
>>>Termination Restoration procedures whereas the Audit procedure
>>>must be supported by the MGW but is not specified how and when
>>>the server must use it. So any MGW that does not report the
>>>termination state using these procedures is non-compliant.
>>>Because of this it should only be used when the MGW will not
>>>send the latest state using Termination restoration or
>>>Termination Out Of service. Other times Audit should not be
>>>used (as you said) to minimise unneccessary signalling.
>>>Cheers,
>>>Phil
>>>
>>>-----Original Message-----
>>>From: 3GPP_TSG_CT_WG4 - Core Network and Terminals WG 4
>>>[mailto:[email-masked]]On Behalf Of Berry, Nigel
Howard
>>>(Nigel)
>>>Sent: Thursday, 26 January 2006 10:20 PM
>>>To: [email-masked]
>>>Subject: Re: Discussion Paper and CRs on TDM Termination State
Handling
>>>
>>>
>>>Hi Phil and Manfred,
>>>
>>>          This clearly an implementation issue but if there is a
>>>clear need to narrow down the options for these scenarios and
>>>then we should perhaps state some general principles which we
>>>can agree on.
>>>
>>>Historically, with ISUP, channels/trunk groups would most
>>>typically be brought up out-of-service to allow the two ends
>>>to coordinate and avoid lots of UCIC and other maintenance
>>>messages.  When both ends were ready, one would send a GRS
>>>(Circuit Group Reset) and expect a GRA response.
>>>This procedure also supports sending BLO or CGB to block any
>>>individual CICs that were not available for traffic.  (Of
>>>course, ISUP as a good committee product also allows the
>>>option of bringing channels up in-service and skipping the GRS/GRA).
>>>
>>>If new equipment is being brought into service, bringing it up
>>>out-of-service and then putting it into service and then
>>>auditing it is probably the best approach.  If existing
>>>equipment is being returned to service, bringing it up
>>>in-service and following normal periodic auditing routines is
>>>best. It is best to avoid an immediate audit if the equipment
>>>had been audited previously before the service outage to avoid
>>>the signalling overhead.
>>>
>>>For channels/trunk groups, disagreements between the MGC and
>>>the MGW should only mean the MGC thinks a channel is busy when
>>>the MGW has idled it during an outage; there should not be any
>>>cases where MGC tries to seize a channel that is already busy.
>>>
>>>For channels that have been blocked, seizing a blocked channel
>>>should just result in receiving a BLO and trying to complete
>>>the call on a different channel.  Because nothing terribly bad
>>>can happen, it is worth avoiding extra audits, which do put a
>>>heavy load on H.248 resources.
>>>
>>>I expect people will try to defend their implementations but
>>>at least by agreeing some general principles we can see what
>>>options and flexibility there is in the general approaches and
>>>these can be narrowed and perhaps reflected in the standards.
>>>
>>>                      Kind Regards,
>>>                                                          Nigel and
Rich
>>>
>>>
>>>
>>>----Original Message-----
>>>From: 3GPP_TSG_CT_WG4 - Core Network and Terminals WG 4
>>>[mailto:[email-masked]]On Behalf Of Philip Hodges
>>>(BR/EPA)
>>>Sent: 26 January 2006 10:03
>>>To: [email-masked]
>>>Subject: Re: Discussion Paper and CRs on TDM Termination State
Handling
>>>
>>>
>>>Hi,
>>>attached are our comments to the Nokia discussion paper. We do
>>>not agree with the logic in this approach and encourage other
>>>companies to consider the two proposals and make some comment
>>>on the reflector.
>>>Cheers,
>>>Phil
>>>
>>>
>>>-----Original Message-----
>>>From: 3GPP_TSG_CT_WG4 - Core Network and Terminals WG 4
>>>[mailto:[email-masked]]On Behalf Of Manfred Volz
>>>Sent: Friday, 20 January 2006 1:47 AM
>>>To: [email-masked]
>>>Subject: Discussion Paper and CRs on TDM Termination State Handling
>>>
>>>
>>>Hi,
>>>
>>>As agreed in the last CT4 meeting attached are the discussion
>>>paper and CRs for 23.205 which represent Nokia's view on TDM
>>>termination State handling in connection to different non-call
>>>related procedures concerning the whole MGW and MSC Server.
>>>
>>><<C4-060020.zip>>  <<C4-060021.zip>>  <<C4-060022.zip>>
>>><<C4-060023.zip>>
>>>
>>>Any early comments are welcome.
>>>
>>>best regards
>>>
>>>Manfred Volz
>>>
>>>   
>>>
>>>      
>>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>
>  
>

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

---

From: "Philip Hodges \(BR/EPA\)" <[email-masked]>
Date: Wed, 8 Feb 2006 10:14:03 +1100

Hi,

I dont believe we are violating core protocol, this seems to be your opinion and I think it is an over-reaction to a proposed application of the protocol. You personally may have some problems with 3GPP as a standards body, I am sorry about that, but it is a significant organisation. It is far too egotistical to believe that only people attending SG16/Q3 have any expertise in this area, however as I have previously stated if CT4 agrees that any proposal does clearly violate the protocol or cannot agree on an issue then we shall (and have done in the past) consult ITU-T SG16/Q3.

Such comments against 3GPP can only be assumed to be personal and not a formal view from ITU-T.

The protocol does not state what you are saying it states. In the section regarding Service Change on ROOT there is NOTHING stating what the other termination states shall be assumed to be, it merely indicates that on ROOT, the MGW is telling the MGC that it exists. I have never disputed that sending a ServiceChange on specific termination(s) should not result in those terminations going into service.

The default value of ServiceState is merely mentioned when describing what values the service state can have, because obviously this parameter cannot be empty so in line with the rest of the protocol it needs a default value and InService is the most logical. However this is hardly a mandate for what all applications of H.248.1 should set physical terminations to after cold boot considering physical terminations have latency in coming into service. The protocol also states that default values can be overriden by provisioning for example. Normally the default values of properties are defined such that when a termination is added it initially has a some default values, this should not be interpreted as how to handle physical terminations which by virtue of their physical characteristics may override this default value.

Thus I conclude that you have one interpretation of the protocol that permits your proposed implementation. I have another. No violation of protocol rules. However neither is intuitive in the H.248.1 protocol alone so either solution needs further description. Further H.248.1 already alludes to a deficiency in your assumption by inclusion of the service change incomplete flag. In order to expediate the solution in 3GPP we choose to define this in 3GPP sepcifications. It is not deemed something that needs to be mandated by the core protocol as it is specific handling between MGWs and MGCs for a specific application.

The use of the H.248.1 between specific nodes is further defined by a profile, I see no violation of core protocol for a profile to define the default service state of specific terminations for use with that profile.

If we applied your proposal (and it seems clear/agreed that not all terminations can actually be Inservice) then the MSC Server is assuming as state of devices that is incorrect. Why should a protocol mandate that ? It doesnt say" the MGC shall assume the default service state of all terminations after cold boot is Inservice, unless told otherwise". 

Your suggested solution "MGWs dont come into service until they are ready to service calls" is not a complete solution:

1. define ready ? All terminations ? Then what happens if some do not come into service ? The MGW never comes into service ? How long should this take ? What percentage of terminations in service classes the MGW as ready ? Why should a MGW with 20 % physical terminations wait until they are all inservice before reporting that 100% of its ephemeral terminations are inservice ?

2. This is not what Service Change on ROOT states in H.248.1:

 "7.2.8.1.11	ServiceChange Command and Response
A ServiceChange Command specifying the "Root" for the TerminationID and ServiceChangeMethod equal to Restart is a registration command by which a Media Gateway announces its existence to the Media Gateway Controller "

I have already laid out so many questions on your assumption and they still remain unanswered...
Cheers,
Phil

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, 8 February 2006 4:08 AM
To: Philip Hodges (BR/EPA); Christian Groves
Cc: [email-masked]; [email-masked];
[email-masked]; Nicky Helm
Subject: RE: [Megaco] Re: Discussion Paper and CRs on TDM Termination
State Handling

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Philip Hodges (BR/EPA) [mailto:[email-masked]] 
Sent: Monday, February 06, 2006 6:56 PM
To: Christian Groves
Cc: [email-masked]; [email-masked];

Hi Christian,

Comments below. 
Cheers,
Phil

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, 7 February 2006 10:05 AM
To: Philip Hodges (BR/EPA)
Cc: [email-masked]; [email-masked];

G'Day,

Christian

refers 
and 
consider 

response
forum

response
that
more
working
made
statement on
which
all
that
are
inservice ?
ones
must
which are
then
?
doesnt do
audit all
until
the
Nokia CR
(otherwise it
Thus if
service
not
state
then
(if
duplicate
clear
Handling
=
Change
says
sends
termination
everything
Handling
Howard
Handling
Rich
Handling

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 8 Feb 2006 15:52:41 -0500

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Philip Hodges (BR/EPA) [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 6:14 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Christian Groves
Cc: [email-masked]; [email-masked];
[email-masked]; Helm, Nicky [RICH1:2H18:EXCH]
Subject: RE: [Megaco] Re: Discussion Paper and CRs on TDM Termination
State Handling

Hi,

I dont believe we are violating core protocol, this seems to be your
opinion and I think it is an over-reaction to a 

[KJBII] When the protocol specifies a default, and that is overridden,
that is a violation of the protocol. This is not a matter of opinion.
This is looking at the text in the protocol, and comparing that to the
text in your spec.  H.248.1 is pretty clear: Terminations are InService
by default.

proposed application of the protocol. You personally may have some
problems with 3GPP as a standards body, I am sorry about that, but it is
a significant organisation. It is far too egotistical to believe that
only people attending SG16/Q3 have any expertise in this area, however
as I have previously stated if CT4 agrees that any proposal does clearly
violate the protocol or cannot agree on an issue then we shall (and have
done in the past) consult ITU-T SG16/Q3.

[KJBII] I never said anything about 3GPP as a standards body.  You are
attempting to muddy the technical debate by invoking emotional (and
irrelevant) elements that are not present in my arguments.  This is not
constructive.  My point was, and this is true of any group, that
so-called experts that think it is OK to violate the referenced protocol
are dubious in their expertise.  If the specification being written
specifically calls out something in direct opposition to written
statements in the referenced spec, it is best to contact the *known*
experts -- in this case the experts of Q3/16.  I believe that 3GPP wants
specifications that are interoperable.  I am sure that the 3GPP
membership wants to be able to have one protocol implementation as much
as possible, in order to reduce cost.  By writing specifications that
contradict the H.248 spec, 3GPP is heading toward fragmenting the
implementation space for H.248 -- which decreases interoperability and
increases costs.

Such comments against 3GPP can only be assumed to be personal and not a
formal view from ITU-T.

[KJBII] I didn't make any statements against 3GPP.  Let's stick to the
issue.

The protocol does not state what you are saying it states. In the
section regarding Service Change on ROOT there is NOTHING stating what
the other termination states shall be assumed to be, it merely indicates
that on ROOT, the MGW is telling the MGC that it exists. I have never
disputed that sending a ServiceChange on specific termination(s) should
not result in those terminations going into service.

[KJBII] To quote from section 7.1.5, TerminationState Descriptor: "The
ServiceStates Property describes the overall state of the termination
(not stream specific). A termination can be in one of the following
states: "Test", "OutOfService", or "InService". The "Test" state
indicates that the termination is being tested. The state "OutOfService"
indicates that the termination cannot be used for traffic. The state
"InService" indicates that a termination can be used or is being used
for normal traffic. "InService" is the default state."  To further quote
from section 7.1.5.1.1, ServiceStates Property: "Default: InService".
So, in fact, the spec says EXACTLY what is being asserted by both
Christian and me.

The default value of ServiceState is merely mentioned when describing
what values the service state can have, because obviously this parameter
cannot be empty so in line with the rest of the protocol it needs a
default value and InService is the most logical. However this is hardly
a mandate for what all applications of H.248.1 should set physical
terminations to after cold boot considering physical terminations have
latency in coming into service. The protocol also states that default
values can be overriden by provisioning for example. Normally the
default values of properties are defined such that when a termination is
added it initially has a some default values, this should not be
interpreted as how to handle physical terminations which by virtue of
their physical characteristics may override this default value.

[KJBII] I disagree with this assertion.  Not all MGs have latency in
bringing physical terminations into service.  This is an implementation
detail, and is a fault of the implementation, not the protocol.  I have
seen MG implementations where the physical termination hardware up and
ready prior to the protocol subsystem.  As you know, from your professed
expertise in H.248, ServiceStates is a special property.  To quote
H.248.1 Annex F.6, "To change the state from "InService" to
"OutOfService" or vice versa, the ServiceChange Command must be used."
Therefore, it is not allowable to use provisioning to change the
ServiceStates property without ALSO sending a ServiceChange to the MGC.
Since the default is "inservice", provisioning to the contrary is a
change, and must be signaled to the MGC using a ServiceChange command.

Thus I conclude that you have one interpretation of the protocol that
permits your proposed implementation. I have another. No violation of
protocol rules. However neither is intuitive in the H.248.1 protocol
alone so either solution needs further description. Further H.248.1
already alludes to a deficiency in your assumption by inclusion of the
service change incomplete flag. In order to expediate the solution in
3GPP we choose to define this in 3GPP sepcifications. It is not deemed
something that needs to be mandated by the core protocol as it is
specific handling between MGWs and MGCs for a specific application.

[KJBII] My interpretation is founded on 6 years of continuous experience
with the H.248 protocol and 4 years holding the editorship of H.248.1
and the Implementors' Guides.  It is also founded on years of actual
coding experience with the protocol, as well as participation in many
interoperability events.  In this email chain, others have indicated
that my interpretations are well-aligned with the H.248 specification as
it was designed and as is written. My proposed implementation to you
does not necessarily match the implementation I maintain on a daily
basis, nor those implementations I have encountered in my years of
working with H.248.  It was a suggestion that solved the "problem" that
you have brought up, since you seem to think the methodologies in the
spec are inadequate.

[KJBII] As an aside, the SCIncomplete flag doesn't allude to anything.
There are no allusions in the specification of which I am aware.  Any
hidden meanings in the spec would be the product of a biased reading.
Generally speaking, my experience has shown that the number of
terminations that are out of service after a cold boot is a relatively
small number, and it is generally due to some failure or maintenance
action.  A similar problem exists when a failure occurs shortly before a
seizure occurs.  There is a short, but non-zero, time between the
termination failing, and the MG reporting the outage to the MGC.  In
this instance, the MG would be expected to fail the command.  I see no
difference here -- how do you propose to defeat this case where the MGC
attempts to seize a termination that is OOS?

The use of the H.248.1 between specific nodes is further defined by a
profile, I see no violation of core protocol for a profile to define the
default service state of specific terminations for use with that
profile.

[KJBII] See the above comment about using ServiceChange to alter the
value of the ServiceStates property.

If we applied your proposal (and it seems clear/agreed that not all
terminations can actually be Inservice) then the MSC Server is assuming
as state of devices that is incorrect. Why should a protocol mandate
that ? It doesnt say" the MGC shall assume the default service state of
all terminations after cold boot is Inservice, unless told otherwise".

[KJBII] I don't see any agreement that not all terminations can be
inservice.  I can think of plenty of scenarios where all terminations
are inservice.  The protocol is free to mandate whatever it wants within
its scope.  I believe the ServiceStates property is well within the
scope of the protocol.  The protocol says that the default ServiceStates
value is "inservice".  It also says that you cannot alter the
ServiceStates property without sending a command.  Historically, the
accepted definition of a cold boot was that the MG had restarted, and is
its initial default state -- no contexts, no ephemerals, physical
terminations are inservice and ready to be controlled by the MGC.

Your suggested solution "MGWs dont come into service until they are
ready to service calls" is not a complete solution:

1. define ready ?
[KJBII] Inservice, and prepared to accept commands from the MGC.

 All terminations ?
[KJBII] All terminations except those for which a ServiceChange Forced
has been received.

 Then what happens if some do not come into service ?
[KJBII] The MGC will have received a ServiceChange Forced from the MG.

 The MGW never comes into service ?
[KJBII] This is an implementation detail.  Certainly this could be the
case.

 How long should this take ?
[KJBII] Again, an implementation detail, though I would hope as quickly
as possible.

 What percentage of terminations in service classes the MGW as ready ?
[KJBII] Again, an implementation detail.

 Why should a MGW with 20 % physical terminations wait until they are
all inservice before reporting that 100% of its ephemeral terminations
are inservice ?
[KJBII] 100% of 0 is no accomplishment.  Remember that ephemeral
terminations DO NOT EXIST until added using an Add Command.  This is
spelled out explicitly in paragraph 3 of section 6.2. I assume you mean
that the RESOURCES used by ephemeral terminations are inservice.  That
seems an awfully big assumption to me... who says that those resources
come inservice any faster than the resources for physical terminations?

 "7.2.8.1.11	ServiceChange Command and Response
A ServiceChange Command specifying the "Root" for the TerminationID and
ServiceChangeMethod equal to Restart is a registration command by which
a Media Gateway announces its existence to the Media Gateway Controller
"

I have already laid out so many questions on your assumption and they
still remain unanswered...

[KJBII] No, you are choosing to ignore the answers you have been given,
because they do not fit your view of the way things ought to be.  There
is a big difference between the two.  Further, my "assumption" is
founded in explicit text in the H.248.1 spec and in many, many years of
experience -- hardly an assumption.

Cheers,
Phil

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, 8 February 2006 4:08 AM
To: Philip Hodges (BR/EPA); Christian Groves
Cc: [email-masked]; [email-masked];

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Philip Hodges (BR/EPA) [mailto:[email-masked]]
Sent: Monday, February 06, 2006 6:56 PM
To: Christian Groves
Cc: [email-masked]; [email-masked];

Hi Christian,

Comments below. 
Cheers,
Phil

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, 7 February 2006 10:05 AM
To: Philip Hodges (BR/EPA)
Cc: [email-masked]; [email-masked];

G'Day,

Christian

refers 
and 
consider 

response
forum

response
that
more
working
made
statement on
which
all
that
are
inservice ?

ones
must
which are
then
?
doesnt do
audit all
until
the

Nokia CR
(otherwise it
Thus if
service
not
state
then
(if
duplicate
clear
>>the difference of opinion between Nokia and Ericsson :-) Cheers, Phil
>>
>>
>>
Handling
>>Change reason = Cold Boot), MGW warm boot (Service Change 
>>Method=restart, Service Change reason = Warm Boot), MGW restoration 
>>(Service Change Method=restart, Service Change reason
=
Change
>>contribution is in line with these principles.
>>
>>physical terminations are out-of-service when the MGW registers with 
>>cold boot clearly violates H.248. H.248
says
sends
termination
>>out of service messages for these physical terminations it has still 
>>out of service (if any).
>>registration with cold boot, then the MGW needs to send for all 
>>physical terminations termination out of service messages and later 
>>when it has powered them up it needs to send termination restoration 
>>messages.
everything
>>>[mailto:[email-masked]] On Behalf Of ext Philip Hodges

Handling
>>>
>>>Hi Nigel,
>>>thanks for the informative response. I agree that we should make some

>>>principles. This is what we aimed to do with our contribution, 
>>>basically:
>>>
>>>1. If and when the MGW knows the state/change of state it tells the 
>>>Server - this is the case for MGW registration, MGW restart, device 
>>>recovery, device connection.
>>>2. If the Server is unsure of the state (MSC restart, MSC Ordered MGW

>>>Re-registration, device connection) then it audits, but only when it 
>>>will not get informed from the MGW.
>>>
>>>As for existing implementations we should consider the current specs 
>>>which make it mandatory to support and use the Termination 
>>>Restoration procedures whereas the Audit procedure must be supported 
>>>by the MGW but is not specified how and when the server must use it. 
>>>So any MGW that does not report the termination state using these 
>>>procedures is non-compliant.
>>>Because of this it should only be used when the MGW will not send the

>>>latest state using Termination restoration or Termination Out Of 
>>>service. Other times Audit should not be used (as you said) to 
>>>minimise unneccessary signalling.
>>>Cheers,
>>>Phil
>>>
Howard
Handling
>>>clear need to narrow down the options for these scenarios and then we

>>>should perhaps state some general principles which we can agree on.
>>>
>>>Historically, with ISUP, channels/trunk groups would most typically 
>>>be brought up out-of-service to allow the two ends to coordinate and 
>>>avoid lots of UCIC and other maintenance messages.  When both ends 
>>>were ready, one would send a GRS (Circuit Group Reset) and expect a 
>>>GRA response.
>>>individual CICs that were not available for traffic.  (Of course, 
>>>ISUP as a good committee product also allows the option of bringing 
>>>channels up in-service and skipping the GRS/GRA).
>>>
>>>out-of-service and then putting it into service and then auditing it 
>>>is probably the best approach.  If existing equipment is being 
>>>returned to service, bringing it up in-service and following normal 
>>>periodic auditing routines is best. It is best to avoid an immediate 
>>>audit if the equipment had been audited previously before the service

>>>outage to avoid the signalling overhead.
>>>
>>>For channels/trunk groups, disagreements between the MGC and the MGW 
>>>should only mean the MGC thinks a channel is busy when the MGW has 
>>>idled it during an outage; there should not be any cases where MGC 
>>>tries to seize a channel that is already busy.
>>>
>>>For channels that have been blocked, seizing a blocked channel should

>>>just result in receiving a BLO and trying to complete the call on a 
>>>different channel.  Because nothing terribly bad can happen, it is 
>>>worth avoiding extra audits, which do put a heavy load on H.248 
>>>resources.
>>>
>>>I expect people will try to defend their implementations but at least

>>>by agreeing some general principles we can see what options and 
>>>flexibility there is in the general approaches and these can be 
>>>narrowed and perhaps reflected in the standards.
>>>
>>>                      Kind Regards,
>>>                                                          Nigel and
Rich
Handling
>>>
>>>
>>>Hi,
>>>attached are our comments to the Nokia discussion paper. We do not 
>>>agree with the logic in this approach and encourage other companies 
>>>to consider the two proposals and make some comment on the reflector.
>>>Cheers,
>>>Phil
>>>
>>>
>>>As agreed in the last CT4 meeting attached are the discussion paper 
>>>and CRs for 23.205 which represent Nokia's view on TDM termination 
>>>State handling in connection to different non-call related procedures

>>>concerning the whole MGW and MSC Server.
>>>

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 8 Feb 2006 15:55:51 -0500

As with all IG proposals, I am happy to incorporate items into the IG
that are agreed by Q3/16.  I look forward to your contribution.

I plan on bringing a contribution to also point the implementors of V1
and V2 toward Annex F in V3 for ServiceChange methodologies that would
apply to the earlier versions.

Kevin 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 8:08 PM
To: [email-masked]
Cc: Philip Hodges (BR/EPA); [email-masked];

Hello,

This email thread was started on the Megaco list to clarify if the
Megaco list was relevant to take a discussion on H.248 matters. I think
it has been established that it is. Furthermore it was sought to clarify
the behaviour that on receipt of ServiceChange on Root "restart" that
all terminations are in-service (including ephemeral and physical) I
think this has also been clarified by the list (notwithstanding Phil's
opinion).

Even though I don't think its necessary given that this is the case I
would propose that we add clarifying text to the IG to make 110% certain
for people that we add text to the effect:
"On receipt of ServiceChange on Root with Restart all terminations are
assumed to be "In-Service". This includes  both ephemeral and physical
terminations. Those terminations which are not in service shall be
reported by subsequent ServiceChange commmands."

This text is simply clarifying the behaviour of H.248.1 since it was
first approved.

As for the potential seizure issue. How to avoid a potential seizure
issue is already solved in H.248.1v3. For v1 and v2 if people feel that
this is a significant issue then I would encourage them to solve the
issue for all networks not just for/in a single network such a 3GPP.

See comments below.

Christian

[CHG] H.248.1 talks about "terminations" with regards to this issue. You
seem to say(agree)  that ephemerals are in-service on service change on
root. Yet there is no H.248.1 text stating a deviation for physical
terminations in this case. There seems to be a problem with your
logic.... Why is it not clear?

terminations. "
[CHG] Thanks for the clarification of the ServiceChangeIncomplete flag
it shows that this works fine with the initial assumption all
terminations are in-service unless don't otherwise.

[CHG] Which particular assumption are you referring to? There are
operational networks that contain H.248 out there today that work with
the current behaviour.

>PHIL> read the 3GPP contributions.
[CHG] Please send a link to the appropriate 3GPP contributions to the
Megaco List so that all people on the list can have an understanding. 
Not everyone on the Megaco list is part of 3GPP.

>
>Backwards compatibility is does ofcourse depend on the implementation
of the equipment in the network where of concern and whether the
equipment is already complying to current standards. Still I have not
been pointed to a clear statement in H.248.1 that addresses this
concern. It seems people are simply reading into it what they want to,
what I am trying to do is assess the problems with either assumption and
it seems clear to me that one assumption is far less efficient than the
other.
[CHG] I think you have been pointed to solutions to the problem without
trying rewrite existing protocol behaviour. Auditing is something that
is used in H.248.1v2 and in h.248.1v3 you can use the
ServiceChangeIncomplete mechanism.

>PHIL> so you now admit there is a problem and suggest one of a miriad
of possible vendor specific implementations that might alleviate the
problem - but in itself create more problems in the form of additional
signalling !
[CHG] Did I ever say there wasn't a potential seizure problem? The list
has proposed solutions which are 100% compliant with already existing
H.248 mechanisms instead of creating a deviation from the core H.248
standard.

>>refers to are valid. Kevin has been the editor of H.248.1 for some 
>>time now and is actively involved in both IETF Megaco and ITUSG16 so I

>>would consider him to be one of the best H.248 experts around. However

>>like all on the list he doesn't officially represent the "IETF view"
nor the SG16 view.
>>But I must say I expect the same response as what has been given by 
>>the list.
>>
>>I don't see any "mobile" related pecularities on the ServiceChange 
>>part of the H.248 protocol.
>>
>>>forum for H.248 topics (also by ITU-T SG16 members).
>>>
>>>Albrecht
>>>
>>>
>>>
>>>

>>>that overrules the core protocol in certain aspects or more often 
>>>makes it more specific to 3GPP applications. This is neccessary to 
>>>define a real working application such as a mobile network. 3GPP has
the remit to do this.
>>>
>>>Thirdly it is clear to me that some of the assumptions and 
>>>suggestions made in this reply email are flawed. H.248.1 makes a 
>>>rather general statement on handling terminations - nothing specific 
>>>about physical terminations which are fundamentally different to 
>>>ephemeral ones. There is no reason why all emphemeral terminations 
>>>are not inservice, but there are reasons why physical terminations 
>>>have not come into service yet. If the rule is that the MGW shall not

>>>report itself as re-booted until all terminations are inservice then
what does it do when some terminations are not inservice ?
>>>stupid. So it waits until some/most (what rule ?) are inservice. 
>>>While waiting for physical terminations to come into service the 
>>>ephemeral ones cannot be used either. Then, how does the MGC know 
>>>which ones are in service ? It doesnt, so in Nokia/Nortel's oppinion 
>>>it audits. Then it must audit all = wasteful signlling/processing. 
>>>BUT only the MGW knows which are inservice (and which are not) so the

>>>MGW should inform of this. BUT then when does the MGW know that it
has been informed that all are reported ?
>>>doesnt do any audits). So why audit in early versions when it would 
>>>have to audit all ? Why assume terminations are inservice when you 
>>>still have to wait until told by the MGW that it has finished telling

>>>the server about all of the out-of-service terminations (in  v3) ?
>>>
>>>Consider the backward compatibility with a MGW that implements 
>>>service change incomplete flag and a server that doesnt: According to

>>>the Nokia CR the MSC server 'may' audit the terminations before using

>>>them (otherwise it just goes ahead and if seizes a blocked trunk the 
>>>call will fail). Thus if the server performs an audit and gets 
>>>blocked it will also get a service change notification from the MGW 
>>>that it is blocked. If the trunk is not blocked then it performs an 
>>>unneccessary audit but atleast knows the state before trying to seize

>>>the termination. If it doesnt perform an audit then it may get told 
>>>the termination is blocked before it tries to seize it (if it is
lucky).
>>>clear the difference of opinion between Nokia and Ericsson :-) 
>>>Cheers, Phil
>>>
>>>
>>>
>>>(Service Change Method=restart, Service Change reason = Service 
>>>Restored) and MGW Communication up (Service Change 
>>>Method=Disconnected, Service Change reason = Service Restored).
>>>cold boot clearly violates H.248. H.248 says clearly and Kevin Boyle 
>>>confirms this in the attached mail exchange, that all physical 
>>>terminations are assumed to be in service by MGC after MGW cold boot.
>>>sends registration with cold boot, it needs to send after the 
>>>accepted cold boot registration, termination out of service messages 
>>>for these physical terminations it has still out of service (if any).
>>>everything between is of course also possible.
>>>
>>>br manfred
>>>
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>thanks for the informative response. I agree that we should make 
>>>>some principles. This is what we aimed to do with our contribution, 
>>>>basically:
>>>>
>>>>2. If the Server is unsure of the state (MSC restart, MSC Ordered 
>>>>MGW Re-registration, device connection) then it audits, but only 
>>>>when it will not get informed from the MGW.
>>>>

>>>>Because of this it should only be used when the MGW will not send 
>>>>the latest state using Termination restoration or Termination Out Of

>>>>clear need to narrow down the options for these scenarios and then 
>>>>we should perhaps state some general principles which we can agree 
>>>>on.
>>>>

>>>>audit if the equipment had been audited previously before the 
>>>>service outage to avoid the signalling overhead.
>>>>

>>>>should just result in receiving a BLO and trying to complete the 
>>>>call on a different channel.  Because nothing terribly bad can 
>>>>happen, it is worth avoiding extra audits, which do put a heavy load

>>>>on H.248 resources.
>>>>
>>>>I expect people will try to defend their implementations but at 
>>>>least by agreeing some general principles we can see what options 
>>>>and flexibility there is in the general approaches and these can be 
>>>>State handling in connection to different non-call related 
>>>>procedures concerning the whole MGW and MSC Server.
>>>>