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

From: "Philip Hodges \(BR/EPA\)" <[email-masked]>
Date: Fri, 3 Feb 2006 15:42:15 +1100

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: "Annie Benitez Pelaez" <[email-masked]>
Date: Fri, 3 Feb 2006 09:48:09 -0500

Hi!

ServiceChange method/reason and the resulting ServiceState of the
Terminations has been discussed in previous ITU-T SG16 meetings - H.248
clearly states that a Restart ServiceChange implies that all terminations
are in-service. Additionally, if you look at the reason codes themselves,
e.g. 901 in H.248.8 says that the TerminationID specified is "InService".
Like Kevin mentioned, you can use the ServiceChangeIncompleteFlag to
indicate that there are additional ServiceChanges coming (indicating Forced)
for those terminations that are OOS.

I also agree with Christian that "overriding" this is not a good idea as
it's part of the core functionality of H.248 and it'll lead to
interoperability issues.

Regards,
Annie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Hodges (BR/EPA)
Sent: Thursday, February 02, 2006 11:42 PM
To: Christian Groves; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] Re: Discussion Paper and CRs on TDM Termination
StateHandling

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];

Hello,

Regards, Christian

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

---

From: [email-masked]
Date: Fri, 3 Feb 2006 17:07:11 +0200

Hi,

Comes to mind 2 more questions.
When the H.248 protocol was developped, you had to decide what is the
default state for the terminations.
Was there any special reason why it was decided to use in-service?

Then H.248.8 defines for service change reason 901 cold boot:
"This indicates that the entity indicated by the TerminationID is in
ServiceState "In Service", and that it has gone through a start, or
recovery action and all associated contexts, except the null context,
have been cleared."

So can the MGC assume when a MGW reports a restart with cold boot 
that there exist no more ephemeral terminations in the MGW?

br manfred

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Philip Hodges (BR/EPA)
>Sent: 03 February, 2006 06:42
>Subject: RE: [Megaco] Re: Discussion Paper and CRs on TDM 
>Termination StateHandling
>
>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
>
>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. 
>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.
>
>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
>
>>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,
>>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 ?
>>
>>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 ?
>>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) ?
>>
>>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.
>>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
>>
>>
>>  
>>
>>>[mailto:[email-masked]] On Behalf Of ext 
>Philip Hodges 
>>>(BR/EPA)
>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.
>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.
>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.
>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.
>>>
>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.
>>>

---

From: Christian Groves <[email-masked]>
Date: Tue, 07 Feb 2006 10:04:38 +1100

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

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

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.

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

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.

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
>