headers
Albrecht.Schwarz | 2 Feb 2006 10:14
Picon
Picon

Re: Discussion Paper and CRs on TDM Termination State Handling


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 "megaco <at> ietf.org" is still the conjointly used forum
for H.248 topics (also by ITU-T SG16 members).

Albrecht

                                                                                                                                       
                      "Philip Hodges                                                                                                   
                      (BR/EPA)"                    To:      3GPP_TSG_CT_WG4 <at> LIST.ETSI.ORG                                              
                      <philip.hodges <at> 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 <at> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
peter.tury | 2 Feb 2006 12:28
Picon

2.5 coinciding types: SigParameter, EventParameter, PropertyParm

Hi,

I see in H.248 Version 2:05/2002 that the 3 types mentioned above are
practically the same (the only difference is that name in PropertyParm
is of size 4 and that the value's type is not denoted as Value in one
case...).

What is the reason behind this? Are there only "historical reasons"? Why
don't we have one type (e.g. GenericParam) for all of these? According
to my current view this approach (using 3 coinciding types) is rather
confusing and makes all implementation for the protocol less
straightforward. What do you think? If there are no "real" reasons
behind the separation: would it be possible somehow in the (long) future
to merge these types into one?

Are there other similarly coinciding types?

Thanks in advance,
Peter Tury
Permalink | Reply | 0 comments |
headers
Kevin Boyle | 2 Feb 2006 19:06
Favicon

RE: 2.5 coinciding types: SigParameter, EventParameter, PropertyParm

Parameters for events and parameters for signals are independent of each
other and the property space.  You cannot define a parameter such that
it applies to signals, events and is a property.

The fact that they are coincidental in syntax does NOT make them
coincidental in actual definition.  Further, there are special parms
that are defined in the base protocol that fall into some of the
categories.  These special items (Embedded Events/Signals Descriptor,
Duration, etc.) are specific to the construct they are defined in
(Embedded descriptors are specific to events, duration is specific to
signals, etc.).  Therefore, there no a way to merge these constructs
into a single construct.

Kevin

-----Original Message-----
From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf
Of peter.tury <at> nokia.com
Sent: Thursday, February 02, 2006 6:29 AM
To: megaco <at> ietf.org
Subject: [Megaco] 2.5 coinciding types: SigParameter,
EventParameter,PropertyParm

Hi,

I see in H.248 Version 2:05/2002 that the 3 types mentioned above are
practically the same (the only difference is that name in PropertyParm
is of size 4 and that the value's type is not denoted as Value in one
case...).
(Continue reading)

Permalink | Reply | 501 comments |
headers
Kevin Boyle | 2 Feb 2006 19:27
Favicon

RE: Re: Discussion Paper and CRs on TDM Termination StateHandling

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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf
Of Albrecht.Schwarz <at> alcatel.de
Sent: Thursday, February 02, 2006 4:15 AM
To: Philip Hodges (BR/EPA)
Cc: megaco <at> ietf.org; 3GPP_TSG_CT_WG4 <at> LIST.ETSI.ORG
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 "megaco <at> ietf.org" is still the conjointly used forum
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shimshon.Lapushner | 2 Feb 2006 19:55

Shimshon Lapushner/ECI Telecom is out of the office.

I will be out of the office starting  02/02/2006 and will not return until
05/02/2006.

I could be reached by Mobile: +972 54 578-8113
Permalink | Reply | 0 comments |
headers
Christian Groves | 3 Feb 2006 05:21

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

Albrecht.Schwarz <at> alcatel.de wrote:

>Like to clarify the first point:
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
peter.tury | 3 Feb 2006 10:46
Picon

RE: 2.5 coinciding types: SigParameter, EventParameter, PropertyParm

Hi,

thanks for the answer!

In fact I still think this coincidence should be represented via the
usage of the same types. Let me  clarify my reasons.

>Parameters for events and parameters for signals are 
>independent of each
>other and the property space.  You cannot define a parameter such that
>it applies to signals, events and is a property.

Of course I don't want to: this would mean that the
semantic/interpretation of the actual values would be the same, and this
is obviously not the case.

In my opinion this is a syntax issue and has nothing to do with semantic
problems. Here (in the ASN.1/ABNF part of the standard) we practically
define types. Types determines the "format" of the data they can be used
for. If the format of these data are the same and this is intentional
then the same types should be used.

In fact, they really have to be handled (but not interpreted!) in the
same way. This can be articulated in an unambiguous way if we use the
same types.

E.g. let's think about human names: they have the same format (thus same
type should be used for them in a standard) even if we have male and
female names, and they are independent of each other and we cannot
"define" a name such that is applies equally to males and females (...);
(Continue reading)

Permalink | Reply | 501 comments |
headers
Philip Hodges (BR/EPA | 3 Feb 2006 05:42
Picon
Favicon

RE: Re: Discussion Paper and CRs on TDM Termination State Handling

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:Christian.Groves <at> nteczone.com]
Sent: Friday, 3 February 2006 3:22 PM
To: Albrecht.Schwarz <at> alcatel.de
Cc: Philip Hodges (BR/EPA); megaco <at> ietf.org;
3GPP_TSG_CT_WG4 <at> LIST.ETSI.ORG
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
(Continue reading)

Permalink | Reply | 3 comments |
headers
manfred.volz | 3 Feb 2006 16:07
Picon

RE: Re: Discussion Paper and CRs on TDM Termination StateHandling

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

>-----Original Message-----
>From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] 
>On Behalf Of ext Philip Hodges (BR/EPA)
>Sent: 03 February, 2006 06:42
>To: Christian Groves; Albrecht.Schwarz <at> alcatel.de
>Cc: megaco <at> ietf.org; 3GPP_TSG_CT_WG4 <at> LIST.ETSI.ORG
>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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Annie Benitez Pelaez | 3 Feb 2006 15:48
Favicon

RE: Re: Discussion Paper and CRs on TDM Termination StateHandling

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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Philip Hodges (BR/EPA)
Sent: Thursday, February 02, 2006 11:42 PM
To: Christian Groves; Albrecht.Schwarz <at> alcatel.de
Cc: megaco <at> ietf.org; 3GPP_TSG_CT_WG4 <at> LIST.ETSI.ORG
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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane