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

From: "Philip Hodges \(BR/EPA\)" <[email-masked]>
Date: Tue, 7 Feb 2006 10:55:36 +1100

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 ?

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.

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).

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.

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..

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 !

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: Christian Groves <[email-masked]>
Date: Wed, 08 Feb 2006 12:08:27 +1100

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

>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…
[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?

>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 perfor…
[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.

>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…
[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 ha…
[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…
[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.

---

From: [email-masked]
Date: Wed, 8 Feb 2006 16:09:15 +0200

Hi,

I think it is a good idea to clarify this also in the H.248
implementators guide.
There could be additional some text handling not only the cold boot
case, 
but also the warm boot and service restored case.

The discussion of TDM Termination state started in 3GPP CT4 for the Mc
interface, 
but I think the same is valid at least also for the 3GPP CT4 Mn
interface and the TISPAN Trunking Media Gateway profile.
All these profiles treat TDM terminations and I see no reason why these
should be handled differently.

Christian asked for a link to the CT4 3GPP contributions. They can be
found under
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_30_Denver/
TDocs/
Contributions from C4-060020 to C4-060030 concern TDM Termination state
handling. 
 
br manfred 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Christian Groves
>Sent: 08 February, 2006 03:08
>To: [email-masked]
>Cc: Philip Hodges (BR/EPA); [email-masked]; 
>Subject: Re: [Megaco] Re: Discussion Paper and CRs on TDM 
>Termination StateHandling
>
>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
>
>>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 ?
>>  
>>
>[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?
>
>>7.2.8.1.11 ServiceChange Command and Response ...
>>has determined that the MG is in state "InService" but individual 
>>terminations may be in state "OutOfService". This is to prevent 
>>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.
>>  
>>
>[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.
>
>>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).
>>  
>>
>[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.
>
>[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. 
>>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..
>>
>>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.
>
>>Christian
>>
>>>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
>>>
>>>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.
>>>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.
>>>
>>>>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:      
>>>>                    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,
>>>>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 
>>>>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).
>>>>
>>>>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
>>>>
>>>>
>>>>
>>>>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).
>>>>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 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).
>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>   
>>>>
>>>>      
>>>>
>>>>>thanks for the informative response. I agree that we should make 
>>>>>some principles. This is what we aimed to do with our 
>contribution, 
>>>>>basically:
>>>>>
>tells the 
>>>>>Server - this is the case for MGW registration, MGW 
>restart, device 
>>>>>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
>>>>>
>>>>>clear need to narrow down the options for these scenarios and then 
>>>>>we should perhaps state some general principles which we can agree 
>>>>>on.
>>>>>
>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).
>>>>>
>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.
>>>>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>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.
>>>>>