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

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 2 Feb 2006 13:27:48 -0500

Per H.248, when an MG comes inservice all terminations are assumed
inservice unless the MG signals otherwise.  This generally done by
sending SC Forceds for the OOS terminations.  This can be done in
conjunction with the SCIncomplete flag in v3.

I don't know that the MGC needs to audit, necessarily.  It depends upon
the situation.

In reference to the "Nokia/Nortel opinion": Take care about stating what
the opinions of other companies may be.  I'm pretty sure that those not
employed by the company in question are in no position to make
statements about that companies' position.

Kevin

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

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: "Kevin Boyle" <[email-masked]>
Date: Fri, 3 Feb 2006 10:56:45 -0500

Actually, it makes perfect sense.  Just because it doesn't make sense
for one vendor's implementation, doesn't mean the protocol is defined
"wrong".  If you do not assume the terminations are inservice, how does
the MGC ever know when the MG is ready?  By assuming the terminations
are inservice, the onus is on the MG to provide the information about
its terminations service states to the MGC.

In fact, it is explicitly stated that this is the behavior under the
protocol.  Choosing a different behavior is overriding/violating the
core protocol, no matter how insignificant you feel the particular issue
may be.

There are plenty of implementations in the field, supporting millions
upon millions of terminations across many tens of thousands of MGs
worldwide, that implement the spec as written.  So, it must have been
implemented in a manner that was efficient enough for live deployment.

The protocol does not mandate the service state of the terminations.  It
mandates the *assumption* at the MGC in the absence of any further input
from the MG.  The MG is always free to send a subsequent ServiceChange
to indicate a particular termination or group of terminations is OOS.

Kevin

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

>The IETF email list "[email-masked]" is still the conjointly used 
>forum for H.248 topics (also by ITU-T SG16 members).
>
>Albrecht
>
>
>
>

>response from IETF when ITU-T SG16 is the body responsible for H.248.1
?

this.

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

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

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

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

>>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.
>>service. Other times Audit should not be used (as you said) to 
>>minimise unneccessary signalling.
>>Cheers,
>>Phil
>>

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

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