Sudhanshu Garg | 5 Jun 14:26 2006

V3 related clarifications required


Hi,

While going through the H.248.1 V3 I had following queries.
Could someone please answer them. Protocol enhancements are also suggested for some of them. Please also comment on them if they are correct and feasible or not.

Queries related to context attribute descriptor and context Audit
Query 1:
The context Id list has been introduced in H.248.1 in context attribute descriptor.
The usage has also been explained for the auditing purpose in section 7.2.5. Can the context Id list be used for other command requests as well?

For example if IMGC needs to tear down some calls selectively, can following Megaco transaction be used?
MEGACO/3 [x.x.x.x]:x Transaction=10001{Context=*{ContextAttr{ContextList={1,2}},Subtract=*{Audit{}}}}

If yes then, what will be the corresponding reply:
a) MEGACO/3 [y.y.y.y]:y Reply=10001{Context=*{ContextAttr{ContextList={1,2}},Subtract=*}}
or
b) MEGACO/3 [y.y.y.y]:y Reply=10001{Context=1{Subtract=t1, Subtract=t2}, Context=2{Subtract=t3, Subtract=t4}}
or
c) anything else.

And also, it should be mandatory to have wildcarded context ID (context=*), if context attribute descriptor has context ID list.



Query 2:
The termination ID list has been introduced in H.248.1 where a hierarchical TerminationID structure is not possible.
When service change command request is sent then whether the termination ID ROOT can be present with other terminations simultaneously in the termination ID list or not.
e.g. MEGACO/3 [y.y.y.y]:y Transaction=2000{Context=-{ServiceChange=[ROOT, T1]{Services{Method=Forced, Reason="907 Transmission failure",20060602T04044100}}}
It means that termination T1 and MG as a whole are taken out of service (where T1 also belongs to same MG) and here taking T1 out of service is redundant.



Query 3:
ASN syntax supports sequence of IndAudPropertyParm in ContextAttrAuditRequest. Does it mean
a) auditing of multiple packages is allowed
or
b) auditing of only a single package with a selection criteria of multiple property parameters is allowed.

If answer is "a" then to audit package P1 and P2 with the selection criteria being properties p3, p4 and p5, single action request is sufficient and sequence of IndAudPropertyParm in ContextAttrAuditRequest should be provided as follows:
Action request 1:
IndAudPropertyParm 1:
        name P1
        propertyParms p3
IndAudPropertyParm 2:
        name P1
        propertyParms p4
IndAudPropertyParm 3:
        name P1
        propertyParms p5
IndAudPropertyParm 4:
        name P2
        propertyParms p3
IndAudPropertyParm 5:
        name P2
        propertyParms p4
IndAudPropertyParm 6:
        name P2
        propertyParms p5

If answer is "b" then to audit package P1 and P2 with the selection criteria being properties p3, p4 and p5, two action requests are necessary and sequence of IndAudPropertyParm in ContextAttrAuditRequest should be provided as follows:
Action request 1:
IndAudPropertyParm 1:
        name P1
        propertyParms p3
IndAudPropertyParm 2:
        name P1
        propertyParms p4
IndAudPropertyParm 3:
        name P1
        propertyParms p5
Action request 2:
IndAudPropertyParm 1:
        name P2
        propertyParms p3
IndAudPropertyParm 2:
        name P2
        propertyParms p4
IndAudPropertyParm 3:
        name P2
        propertyParms p5

On the same hand, the ABNF encoding does not allow me to provide the flexibility to audit multiple packages simultaneously.
Snip from ABNF syntax is also attached.
    ; at-most-once except contextAuditSelector
    contextAuditProperties        = (TopologyToken / EmergencyToken /
                                        PriorityToken /IEPSToken/ pkgdName /
                                        contextAuditSelector)



Query 4:
In ABNF syntax, the usage of indAudcontextAttrDescriptor in contextAudit is not very clear as the individual audit also maps on to contextAuditProperties only.
Snip from ABNF syntax is also attached.
    contextAudit                = ContextAuditToken LBRKT (contextAuditProperties
                          *(COMMA contextAuditProperties)) /
                            indAudcontextAttrDescriptor         RBRKT

    indAudcontextAttrDescriptor
                                = ContextAttrToken LBRKT contextAuditProperties
                                        *(COMMA contextAuditProperties) RBRKT



Query 5:
The usage of context Id list inside the contextAuditSelector (using contextAttrDescriptor) is not very clear. The ASN syntax does not have context Id list in ContextAttrAuditRequest.
IF context ID list is not required in the contextAuditSelector, then the corresponding ABNF should be updated to have list of propertyParm instead of contextAttrDescriptor.

Suggested ABNF:
    ; at-most-once
    contextAuditSelector         = priority / emergencyValue / iepsValue /
                                        contextAttrSelector / auditSelectLogic
    contextAttrSelector        = ContextAttrToken LBRKT (propertyParm *(COMMA propertyParm)) RBRKT


Snip from existing ABNF syntax and ASN syntax  is also attached.
ABNF Syntax:
    contextAudit                = ContextAuditToken LBRKT (contextAuditProperties
                          *(COMMA contextAuditProperties)) /
                            indAudcontextAttrDescriptor         RBRKT

    ; at-most-once except contextAuditSelector
    contextAuditProperties        = (TopologyToken / EmergencyToken /
                                        PriorityToken /IEPSToken/ pkgdName /
                                        contextAuditSelector)

    ; at-most-once
    contextAuditSelector         = priority / emergencyValue / iepsValue /
                                        contextAttrDescriptor / auditSelectLogic

    contextAttrDescriptor        = ContextAttrToken LBRKT (contextIdList /
                                        propertyParm *(COMMA propertyParm)) RBRKT

ASN Syntax:
    ContextAttrAuditRequest        ::= SEQUENCE
    {
        topology                                NULL OPTIONAL,
        emergency                                NULL OPTIONAL,
        priority                                NULL OPTIONAL,
        …,
        iepscallind                                NULL OPTIONAL,
        contextPropAud                        SEQUENCE OF IndAudPropertyParm OPTIONAL,
        selectpriority                        INTEGER(0..15) OPTIONAL,
           -- to select given priority
        selectemergency                        BOOLEAN OPTIONAL,
           -- to select if emergency set/not set (T/F)
        selectiepscallind                        BOOLEAN OPTIONAL,
           -- to select if IEPS set/not set (T/F)
        selectLogic                                SelectLogic OPTIONAL    -- default is AND
    }

    SelectLogic            ::= CHOICE
    {
        andAUDITSelect                        NULL,     -- all filter conditions satisfied
        orAUDITSelect                        NULL,     -- at least one filter condition satisfied
          …
    }


Regards,
Sudhanshu.
Technical Leader
Flextronics Software Systems
Phone:  +91-124-4176301 extn 5109
Fax: +91-124-4300247
web: www.flextronicssoftware.com

***********************  FSS-Private   ***********************
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Noel Keith | 6 Jun 23:19 2006
Picon

RFC3525 or RFC2885

Hello All:

I don´t know what RFC to use to request MGC element
with MEGACO protocol?

p.e. RFC3525 obsoletes RC3015 but to RFC2885
abosoletes RFC3015.

If anybody knows about of what is the correct RFC?

Cheers,

Noel

	
	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 
B Venkat S.R Swamy | 7 Jun 06:38 2006

Re: RFC3525 or RFC2885

Hi
You are referring to quite an old document of Megaco. Standardization of Megaco/H.248 is now being done by ITU-T.


RFC 2885 ---> RFC 3015 ---->RFC 3525 ----> H248.1 V1(March 2002) ----> H248.1 V2(May 2002) ----->H248.1 V3(Sep 2005)

if you do not have ITU-T access, the ITU-T drafts can be accessed from following site:

http://ftp3.itu.ch/av-arch/avc-site

regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
Noel Keith <noel_keith_nk <at> yahoo.com.ar>


          Noel Keith <noel_keith_nk <at> yahoo.com.ar>

          06/07/2006 02:49 AM


To

megaco <at> ietf.org

cc


Subject

[Megaco] RFC3525 or RFC2885

Hello All:

I don´t know what RFC to use to request MGC element
with MEGACO protocol?

p.e. RFC3525 obsoletes RC3015 but to RFC2885
abosoletes RFC3015.

If anybody knows about of what is the correct RFC?

Cheers,

Noel






___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar 


_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software
Systems Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Alon Tal | 7 Jun 11:50 2006

Error Descriptor Syntax

Is the following error descriptor valid?

!/1 [10.20.30.40]:2944
P = 75040 {
  C = 1046936 {
    MF = STM/15 {
      ER = 530 {}; Receipt of MF while deleting the endpoint
    }
  }
}

As I understand the ABNF, the trailing ";" and unquoted string are
illegal. However, this comes from a live and functioning network, so
there might be something I'm missing.

Thanks,
Alon Tal

Carson, Paul | 7 Jun 12:08 2006

RE: Error Descriptor Syntax

This is legal.

The trailing ";" and unquoted string is a comment.

A comment can follow a "}".

Looking at the ABNF,

    RBRKT = LWSP %x7B LWSP ; "}"

and 

    LWSP = *(WSP / COMMENT / EOL)

a COMMENT is a ";" followed by an unquoted string of characters terminated
by EOL

- PaulC

-----Original Message-----
From: Alon Tal [mailto:AlonT <at> radcom.com] 
Sent: 07 June 2006 10:50
To: megaco <at> ietf.org
Subject: [Megaco] Error Descriptor Syntax

Is the following error descriptor valid?

!/1 [10.20.30.40]:2944
P = 75040 {
  C = 1046936 {
    MF = STM/15 {
      ER = 530 {}; Receipt of MF while deleting the endpoint
    }
  }
}

As I understand the ABNF, the trailing ";" and unquoted string are illegal.
However, this comes from a live and functioning network, so there might be
something I'm missing.

Thanks,
Alon Tal

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Kevin Boyle | 8 Jun 22:33 2006

RE: RFC3525 or RFC2885

This timeline is completely wrong.

RFC 2885 is the "pre-release" specification for Megaco.  It was the
"first draft" and formed the basis for what eventually became RFC3015.
RFC 3015 and the original H.248 (11/2000) are common text.  In 2002, the
H.248 series was renumbered in the ITU and H.248.1 Version 1 (03/2002)
and Version 2 (05/2002) were published.  RFC 3525 is common text with
H.248.1 Version 1 (03/2002).  There is no RFC that is common text with
H.248.1 Version 2.  H.248.1 was revised to Version 3 in 09/2005.

Note also that there are Implementors' Guides that resolve technical
problems in the text.  For H.248.1 Version 1, the final IG was published
in 04/2006.  The current versions of the Version 2 IG and the subseries
IG (which covers Version 3 and the other subseries Recommendations) are
both being actively updated and their most current versions were
published in 04/2006.

I will note also that standardization of Megaco/H.248 has been a joint
venture of the ITU and IETF since 1999.  The work in the IETF has tailed
off over the years, though this is still an IETF mailing list.  The
Megaco WG in the IETF was concluded in March 2006 after years of no
activity in the IETF.  The ITU has always been involved in the
development of the standard, and was responsible for the caretaking of
the spec even way back at the beginning.

To that end, references to H.248 should be made to the ITU documents,
not to the RFCs.

Kevin

________________________________

From: B Venkat S.R Swamy [mailto:b.swamy <at> flextronicssoftware.com] 
Sent: Wednesday, June 07, 2006 12:39 AM
To: Noel Keith
Cc: megaco <at> ietf.org
Subject: Re: [Megaco] RFC3525 or RFC2885

Hi
You are referring to quite an old document of Megaco. Standardization of
Megaco/H.248 is now being done by ITU-T.

RFC 2885 ---> RFC 3015 ---->RFC 3525 ----> H248.1 V1(March 2002) ---->
H248.1 V2(May 2002) ----->H248.1 V3(Sep 2005)

if you do not have ITU-T access, the ITU-T drafts can be accessed from
following site:

http://ftp3.itu.ch/av-arch/avc-site

regards
B Venkat S.R Swamy 
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
 Noel Keith <noel_keith_nk <at> yahoo.com.ar>

				Noel Keith <noel_keith_nk <at> yahoo.com.ar> 

				06/07/2006 02:49 AM

To

megaco <at> ietf.org	

cc

	

Subject

[Megaco] RFC3525 or RFC2885	
	 	

Hello All:

I don´t know what RFC to use to request MGC element
with MEGACO protocol?

p.e. RFC3525 obsoletes RC3015 but to RFC2885
abosoletes RFC3015.

If anybody knows about of what is the correct RFC?

Cheers,

Noel

___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the 
individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."

begin 666 graycol.gif
M1TE&.#EA$ `0`/<``````+\```"_`+^_````O[\`OP"_O\# P("  <at> /\```#_
M`/__````__\`_P#______P"  <at>  ``````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"'Y! $```\`+ `````0`! `0  <at> M`!\('$BPH,$'
F!Q(>.(A0H4.'#"-*G/A0X<2+&#-J-% <at> 1XL&*%Q-N'$F28$ ``#L`
`
end

begin 666 ecblank.gif
M1TE&.#EA$ `!`/<``````+\```"_`+^_````O[\`OP"_O\# P("  <at> /\```#_
M`/__````__\`_P#______P"  <at>  ``````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"'Y! $```\`+ `````0``$`0  <at> *`!\('$BPX(. 
#```[
`
end
Kevin Boyle | 8 Jun 22:20 2006

RE: Error Descriptor Syntax

Note that a comment, while legal, is completely unparseable.  Because
literally *anything* can appear in a comment, there is no way for the
receiver to analyze the data contained in the comment.

The Error Descriptor is capable of carrying information in the Error
Text construct.  The values contained in the Error Text are defined in
H.248.8 or in the package where the error code is defined, so that
implementations will be able to glean information out of the error text
that could be used to rectify the problem.

I will note that the comment constructs was intended for use in
informational situations, such as sample call flows and the like.  I,
personally, think its use in live deployments is questionable at best.

Kevin 

-----Original Message-----
From: Carson, Paul [mailto:paul <at> artesyncp.com] 
Sent: Wednesday, June 07, 2006 6:08 AM
To: 'Alon Tal'; megaco <at> ietf.org
Subject: RE: [Megaco] Error Descriptor Syntax

This is legal.

The trailing ";" and unquoted string is a comment.

A comment can follow a "}".

Looking at the ABNF,

    RBRKT = LWSP %x7B LWSP ; "}"

and 

    LWSP = *(WSP / COMMENT / EOL)

a COMMENT is a ";" followed by an unquoted string of characters
terminated by EOL

- PaulC

-----Original Message-----
From: Alon Tal [mailto:AlonT <at> radcom.com]
Sent: 07 June 2006 10:50
To: megaco <at> ietf.org
Subject: [Megaco] Error Descriptor Syntax

Is the following error descriptor valid?

!/1 [10.20.30.40]:2944
P = 75040 {
  C = 1046936 {
    MF = STM/15 {
      ER = 530 {}; Receipt of MF while deleting the endpoint
    }
  }
}

As I understand the ABNF, the trailing ";" and unquoted string are
illegal.
However, this comes from a live and functioning network, so there might
be something I'm missing.

Thanks,
Alon Tal

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
xiaoshaoping 38157 | 15 Jun 07:01 2006

Profile negotiation and Control association

Hello,
    I've some problem when understanding the profile negotiation procedure in H248v3:

7.2.8.1.11	ServiceChange Command and Response
"If the MGC returned a profile in the reply other than the one that was provided in the request the MG shall:
a.	continue the control association by issuing a new ServiceChange Command with an agreed profile to
confirm to the MGC that the MG has agreed with the profile, or
b.	keep the control association active, so that the MGC will use the profile that it sent in the
ServiceChange Reply, or
……"

If the MG choose action "a", I think the control association is not established yet, because
ServiceChangeProfile is not agreed between the MGC and MG, so the Registration is not completed, based on
following words excerpted from $F.3.1/H248.1 V3:
"Registration starts when the initial ServiceChange Command is sent from the MG to the MGC and completes
when the command is replied by the MGC without an alternate address or an error and the
ServiceChangeProfile is agreed between the MGC and MG. The control association is established upon
completion of registration"
So, how to understand the words of "continue the control association"? 

If the MG choose action "b", does it implies that the MG will accept the profile in the ServiceChange Reply
silently, and not issused any new ServiceChange Command to claim which profile it chosed actually? 
If so, I think the words of "keep the control association active" is inaccurate because the new control
association is established just now, how to "keep"? 
and what is the definition of "active" state of control association, is the initiation or success of the
registration? As I know, the spec just defined initiation, establishment and termination point for the
control association as: 
F.2	Control Association Definition
"A control association is a communication relationship whereby an MGC is controlling an MG. A control
association is instantiated via registration. The control association is terminated by the MG going
OutOfService, being successfully handed off to an alternate MGC, or successfully failing over to an
alternate MGC. "

Can somebody give me a light on these problem?

thanks,
Bill Xiaoshaoping
Oikonomou, Ioannis | 16 Jun 12:53 2006
Picon

MG termination physically broken

Hello,

Is an MG supposed to check the physical connection towards its PSTN subscribers?
For instance, if a subscriber unplugs his telephone device from the wall jack (i.e. physical connection is
therefore broken), should the MG send a ServiceChange(Forced) for this termination indicating it as "Out-of-service"?
As "MG" I'm referring to Access Gateways (residential or not) that control subscribers; I'm not referring
to Trunking Gateways.

The H.248 standard says that:

The ServiceStates property describes the overall state of the termination (not stream-specific).  A
Termination can be in one of the following states: "test", "out of service", or "in service".  The "test"
state indicates that the termination is being tested. The state "out of service" indicates that the
termination cannot be used for traffic.  The state "in service" indicates that a termination can be used or
is being used for normal traffic.  "in service" is the default state. 

My opinion is that checking of the physical connection is indeed an MG task and therefore the MG should
report to the MGC when a telephone device gets unplugged, by sending a ServiceChange(Forced) message for
the respective physical termination.

Thank you in advance,
Ioannis Oikonomou

MG termination physically broken

________________________________

*	To: Pascal Lambers <pascal.lambers at pandora.be <mailto:pascal.lambers <at> DOMAIN.HIDDEN> >, megaco
at ietf.org <mailto:megaco <at> DOMAIN.HIDDEN>  
*	Subject: RE: [Megaco] MG termination physically broken 
*	From: "Kevin Boyle" <kboyle at nortelnetworks.com <mailto:kboyle <at> DOMAIN.HIDDEN> > 
*	Date: Fri, 20 Aug 2004 16:01:17 -0400 
*	List-help: <mailto:megaco-request <at> ietf.org?subject=help> 
*	List-id: Media Gateway Control <megaco.ietf.org> 
*	List-post: <mailto:megaco <at> ietf.org> 
*	List-subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
<mailto:megaco-request <at> ietf.org?subject=subscribe> 
*	List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
<mailto:megaco-request <at> ietf.org?subject=unsubscribe> 
*	Sender: megaco-bounces at ietf.org <mailto:megaco-bounces <at> DOMAIN.HIDDEN>  

________________________________

Just because a term is out of service doesn't mean the MG should act as if
it doesn't exist.  If the term starts having trouble, the MG would send a
ServiceChange to take it OOS.  The MG still has to respond to commands for
that term, either by performing the commands, or sending errors back.

Kevin

  _____  

From: Pascal Lambers [mailto:pascal.lambers at pandora.be] 
Sent: Friday, August 20, 2004 1:04 PM
To: megaco at ietf.org
Subject: [Megaco] MG termination physically broken

Hello,

If a Termination on a Mediagateway has a physical or other permanent
problem, can the MGC count on the MG answering to messages for that
termination as long as the MG itself and the network are OK ?

This is an important question because a MGC must have a way of finding out
whether only that termination is in trouble or whether the whole MG is in
trouble....

Kind regards,
Pascal

_______________________________________________
Megaco mailing list
Megaco at ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

________________________________
Dmitry Pavlenko | 16 Jun 13:29 2006
Picon

Re: MG termination physically broken

Hi

from the point of view of a line card: "unplugged" is the same as "plugged"
phone when its hook is on (i.e. the resistance is high in these both cases).

What you should obviously check - are hazardous voltages (for example: 220
AC/Volts from an outlet). In this case the MG should send a ServiceChange
with an explanation what happend to the termination.

Another point to check is: when a line(a termination) changes its state from
on-hook to off-hook very frequently (i.e. it means - something is wrong). A
ServiceChange also should be sent in this case.

When a subscriber unpluges his telephone - the MG will not be able to detect
this state. So, in my opinion: no ServiceChange is needed in this case.

Best Regards,
Dmitry Pavlenko

----- Original Message -----
From: "Oikonomou, Ioannis" <Ioannis.Oikonomou <at> siemens.com>
To: <megaco <at> ietf.org>
Sent: Friday, June 16, 2006 4:53 PM
Subject: [Megaco] MG termination physically broken

Hello,

Is an MG supposed to check the physical connection towards its PSTN
subscribers?
For instance, if a subscriber unplugs his telephone device from the wall
jack (i.e. physical connection is therefore broken), should the MG send a
ServiceChange(Forced) for this termination indicating it as
"Out-of-service"?
As "MG" I'm referring to Access Gateways (residential or not) that control
subscribers; I'm not referring to Trunking Gateways.

The H.248 standard says that:

The ServiceStates property describes the overall state of the termination
(not stream-specific).  A Termination can be in one of the following states:
"test", "out of service", or "in service".  The "test" state indicates that
the termination is being tested. The state "out of service" indicates that
the termination cannot be used for traffic.  The state "in service"
indicates that a termination can be used or is being used for normal
traffic.  "in service" is the default state.

My opinion is that checking of the physical connection is indeed an MG task
and therefore the MG should report to the MGC when a telephone device gets
unplugged, by sending a ServiceChange(Forced) message for the respective
physical termination.

Thank you in advance,
Ioannis Oikonomou

MG termination physically broken

________________________________

* To: Pascal Lambers <pascal.lambers at pandora.be
<mailto:pascal.lambers <at> DOMAIN.HIDDEN> >, megaco at ietf.org
<mailto:megaco <at> DOMAIN.HIDDEN>
* Subject: RE: [Megaco] MG termination physically broken
* From: "Kevin Boyle" <kboyle at nortelnetworks.com
<mailto:kboyle <at> DOMAIN.HIDDEN> >
* Date: Fri, 20 Aug 2004 16:01:17 -0400
* List-help: <mailto:megaco-request <at> ietf.org?subject=help>
* List-id: Media Gateway Control <megaco.ietf.org>
* List-post: <mailto:megaco <at> ietf.org>
* List-subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
<mailto:megaco-request <at> ietf.org?subject=subscribe>
* List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
<mailto:megaco-request <at> ietf.org?subject=unsubscribe>
* Sender: megaco-bounces at ietf.org <mailto:megaco-bounces <at> DOMAIN.HIDDEN>

________________________________

Just because a term is out of service doesn't mean the MG should act as if
it doesn't exist.  If the term starts having trouble, the MG would send a
ServiceChange to take it OOS.  The MG still has to respond to commands for
that term, either by performing the commands, or sending errors back.

Kevin

  _____

From: Pascal Lambers [mailto:pascal.lambers at pandora.be]
Sent: Friday, August 20, 2004 1:04 PM
To: megaco at ietf.org
Subject: [Megaco] MG termination physically broken

Hello,

If a Termination on a Mediagateway has a physical or other permanent
problem, can the MGC count on the MG answering to messages for that
termination as long as the MG itself and the network are OK ?

This is an important question because a MGC must have a way of finding out
whether only that termination is in trouble or whether the whole MG is in
trouble....

Kind regards,
Pascal

_______________________________________________
Megaco mailing list
Megaco at ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

________________________________

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

Gmane