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

From: [email-masked]
Date: Thu, 2 Feb 2006 10:14:38 +0100

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 03 Feb 2006 15:21:45 +1100

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