Subject: [Megaco] Megaco Add

From: Ramesh Babu Kuppili <[email-masked]>
Date: Mon, 10 Dec 2007 10:22:35 +0530

Hello,
 
I have a question regarding Megaco "Add" request:
 
The following is the "Add" request i am receiving from MGC:
 
!/1 [10.129.32.20]:2944 T=369464064{C=${A=A6{M{O{MO=IN,RV=OFF,RG=OFF}},E=369102350{dd/std{tl=*},al/*},SG{}},
    A=${M{O{MO=RC,RV=OFF,RG=OFF,nt/jit=40,bcp/bncchar=IP/RTP},
        L{v=0 c=IN IP4 $
            m=audio $ RTP/AVP 8
            a=ptime:20}}}}
 
And i sent the following reply to the above "Add" request.
 
!/1 [172.150.5.5]:2944 P=369464064{C=3{a=A6 ,a=EA6/ep2{m{l{
v=0
o=- 1197223375 1197223375 IN IP4 172.150.5.5
s=-
c=IN IP4 172.150.5.5
m=audio 49156 RTP/AVP 8
a=ptime:20
}}}}
 
Please note that MGC has asked the MG to choose a context.  And MG has sent reply on context = 3.
 
However any further messages on the TERM (A6) is still coming on NULL context.  Is it correct for MGC to send messages on NULL context after MG has responded to a Add with a valid context.  Is there a issue with the Add reply sent to MGC.  I could not figure this out.  Thanks in advance .
 
- ramesh
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Rajesh Jain -X (rajesjai - Hughes Software at Cisco)" <[email-masked]>
Date: Sun, 9 Dec 2007 22:35:51 -0800

Hi Ramesh,
 
It is NOT correct for the MGC to send a message on NULL context after MG
has successfully responded with a valid (non-NULL) context.
You should check the state of the termination on MGC to see if it's
idle, busy ,etc. to see if there is some issue on MGC side.
 
As such, I dont see any obvious error in the Add reply sent from MG. The
only possibily (though very little) could be the MID part (i.e !/1
[172.150.5.5]:2944 ) in Add response, if it is different from the one
sent in earlier responses generated from MG, MGC would reject it.
 
Thanks
Rajesh

________________________________

From: Ramesh Babu Kuppili [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 10:23 AM
To: [email-masked]
Subject: [Megaco] Megaco Add

Hello,

 
!/1 [10.129.32.20]:2944
T=369464064{C=${A=A6{M{O{MO=IN,RV=OFF,RG=OFF}},E=369102350{dd/std{tl=*},
al/*},SG{}},
    A=${M{O{MO=RC,RV=OFF,RG=OFF,nt/jit=40,bcp/bncchar=IP/RTP},
        L{v=0 c=IN IP4 $
            m=audio $ RTP/AVP 8
            a=ptime:20}}}}

 
Please note that MGC has asked the MG to choose a context.  And MG has
sent reply on context = 3.
 
However any further messages on the TERM (A6) is still coming on NULL
context.  Is it correct for MGC to send messages on NULL context after
MG has responded to a Add with a valid context.  Is there a issue with
the Add reply sent to MGC.  I could not figure this out.  Thanks in
advance .
 
- ramesh

---

From: Ashish Singh <[email-masked]>
Date: Sun, 09 Dec 2007 23:11:33 -0800

Hi Ramesh,

The Event descriptor on termination A6 is over-specified (i.e. it 
contains * wildcard). It may be possible that MGC is expecting fully 
resolved Event descriptor in ADD response.

Thanks
Ashish

Rajesh Jain -X (rajesjai - Hughes Software at Cisco) wrote:
> Hi Ramesh,
>  
> It is NOT correct for the MGC to send a message on NULL context after 
> MG has successfully responded with a valid (non-NULL) context.
> As such, I dont see any obvious error in the Add reply sent from MG. 
> The only possibily (though very little) could be the MID part (i.e !/1 
> ------------------------------------------------------------------------
> *From:* Ramesh Babu Kuppili [mailto:[email-masked]]
> *Sent:* Monday, December 10, 2007 10:23 AM
> *To:* [email-masked]
> *Subject:* [Megaco] Megaco Add
>
> Hello,
>  
> T=369464064{C=${A=A6{M{O{MO=IN,RV=OFF,RG=OFF}},E=369102350{dd/std{tl=*},al/*},SG{}},
> ------------------------------------------------------------------------
>

---

From: "Raphael Tryster" <[email-masked]>
Date: Mon, 10 Dec 2007 09:15:15 +0200

I disagree.  There is nothing to resolve here.  The MGC wants to be
informed of all events indicated by the * wildcard.

Raphael Tryster

-----Original Message-----
From: Ashish Singh [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 9:12 AM
To: Rajesh Jain -X (rajesjai - Hughes Software at Cisco)
Cc: [email-masked]; Ramesh Babu Kuppili
Subject: Re: [Megaco] Megaco Add

Hi Ramesh,

Thanks
Ashish

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco
**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the 
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do 
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

---

From: "Yogesh" <[email-masked]>
Date: Mon, 10 Dec 2007 12:55:51 +0530

Hi,

I think even if fully resolved event descriptor is not sent, MGC should not
send next message to NULL context.

Cheers !!!
 
Yogesh

Sr. Engineer - Testing
A R I C E N T

-----Original Message-----
From: Ashish Singh [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 12:42 PM
To: Rajesh Jain -X (rajesjai - Hughes Software at Cisco)
Cc: [email-masked]; Ramesh Babu Kuppili
Subject: Re: [Megaco] Megaco Add

Hi Ramesh,

The Event descriptor on termination A6 is over-specified (i.e. it contains *
wildcard). It may be possible that MGC is expecting fully resolved Event
descriptor in ADD response.

Thanks
Ashish

> sent in earlier responses generated from MG, MGC would reject it.
T=369464064{C=${A=A6{M{O{MO=IN,RV=OFF,RG=OFF}},E=369102350{dd/std{tl=*},al/*
},SG{}},
> !/1 [172.150.5.5]:2944 P=369464064{C=3{a=A6 ,a=EA6/ep2{m{l{ v=0

---

From: Ramesh Babu Kuppili <[email-masked]>
Date: Mon, 10 Dec 2007 12:51:08 +0530

Ashish,

Over-specification in event descriptor is done by the MGC, not MG.  In fact my MG, is not sending any event descriptor in the Add response.  Not sure how this will cause the issue I am facing.

- ramesh 

> Cc: Ramesh Babu Kuppili; [email-masked]
> The Event descriptor on termination A6 is over-specified 
> (i.e. it contains * wildcard). It may be possible that MGC is 
> expecting fully resolved Event descriptor in ADD response.
> 
> Thanks
> Ashish
> 
>

---

From: Sudhanshu Garg <[email-masked]>
Date: Mon, 10 Dec 2007 13:00:55 +0530

Hi,

It seems that MGC is rejecting the incoming response message.
However protocol does not have any way to inform the peer entity that a 
response has been rejected (anything sort of NACK).

I agree that MGC should not send next message in NULL context.
MGC can audit to get the events information from MG.

At MG, the behavior should be to respond back with command level error for 
next request message with NULL context. This will force MGC to audit for 
the termination.

Regards,
Sudhanshu Garg
Engineering Project Manager
 
A R I C E N T
 
The Presidency Tower - A
351 / 2, Sector 14, M. G. Road
Gurgaon 122001, Haryana, India
 
Main     +91 124. 417.6218
Fax      +91 124.417.6224
Mobile  +91 999.950.0798

"Yogesh" <[email-masked]> 
12/10/2007 12:55 PM

To
"'Ashish Singh'" <[email-masked]>, "'Rajesh Jain -X \(rajesjai - 
Hughes Software at Cisco\)'" <[email-masked]>
cc
[email-masked], "'Ramesh Babu Kuppili'" <[email-masked]>
Subject
RE: [Megaco] Megaco Add

Hi,

I think even if fully resolved event descriptor is not sent, MGC should 
not
send next message to NULL context.

Cheers !!!
 
Yogesh

Sr. Engineer - Testing
A R I C E N T

-----Original Message-----
From: Ashish Singh [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 12:42 PM
To: Rajesh Jain -X (rajesjai - Hughes Software at Cisco)
Cc: [email-masked]; Ramesh Babu Kuppili
Subject: Re: [Megaco] Megaco Add

Hi Ramesh,

The Event descriptor on termination A6 is over-specified (i.e. it contains 
*
wildcard). It may be possible that MGC is expecting fully resolved Event
descriptor in ADD response.

Thanks
Ashish

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent  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. Aricent 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "John Wainwright" <[email-masked]>
Date: Tue, 11 Dec 2007 08:30:32 -0600

If a line is taken OOS as a result of management action and this is
reported in the SVC message to the MGC, who also responds, how should we
then respond to other messages from the MGC related to this line e.g.
Audit messages.

If an events descriptor was previously enabled for this line e.g. for
onhook/offhook, are these events now ignored as long as the line is OOS?

Thanks
John

---

From: Ashish Singh <[email-masked]>
Date: Tue, 11 Dec 2007 09:56:37 -0800

Hi John,

MG has already reported the state change of the termination through 
Servicechange to MGC and MGC keeps track of it. Afterwards MG should 
respond to Audit Request as usual irrespective of its termination state. 
As per H.248 spec, MG should not processs ADD Request on OOS termination.

It may be possible that operator has put the line in OOS mode to do some 
maintenance (e.g. continuity testing), so I think MG should send Notify 
in OOS state also.

Thanks
Ashish

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 11 Dec 2007 16:12:31 +0100

John,
 
I got two comments:
 
1) Relation of the H.248 ServiceStates Property Model with Management Models
You are not mentioning any management model, which may imply that you are using a very simpliefied one, e.g. the state model of the managed object "physical Termination" is identical to the ServiceState. Right?
Below an excerpt from an ETSI TR, which shows one (of many) possible alternative approaches.
E.g., your management action may lead to an "locked" admin state, still "enabled" operational state, and an H.248 ServiceState OoS.
 
2) Any Termination may still receive H.248 Commands in ServiceState "OoS" in my understanding.
"... and not available for traffic" means just user plane traffic in case of a non-Root termination IMHO.
 
-Albrecht

Draft ETSI TR 183 025<2.1.0> (2007-11)

Annex B   (Informative) Relation of the H.248 ServiceStates Property Model with Management Models

This informative annex provides an example for mapping H.248 ServiceStates to a management state model and vice versa. 

B.1   Introduction

The majority of H.248 procedures are independent of the management plane, i.e. "interactionless" procedures. However some procedures should consider potenticom)

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 11 Dec 2007 16:12:31 +0100

John,
 
I got two comments:

 
-Albrecht

B.1   Introduction

The majority of H.248 procedures are independent of the management plane, i.e. "interactionless" procedures. However some procedures should consider potential interaction aspects between control plane (here H.248) and management plane.

Such interactions might be loosely coupled like in case of provisioning or pre-provisioning activities, but there are also some more tightly coupled interactions, particularly in the area of the ServiceChange Command.

For instance, certain actions, which are resulting in H.248 or management state changes, may result in correspondent state changes in the management or H.248 model respectively.

B.2   Scope

The scope of this document is only on the H.248 ServiceStates Property state model. The H.248 ServiceChange Command model (see Annex F/H.248.1) is not considered. The indicated management technologies and correspondent management state models are just examples. There are many other possibilities in mapping the H.248 ServiceStates Property on dedicated management state models. From that perspective, this document may assist to correlate such management state models with the H.248 ServiceStates Property.

This document provides an example mapping between the H.248 ServiceStates Property states and management plane state models according ITU-T Rec. X.731 and IETF RFC 4268. Other management plane models could be used as well for correlation with the H.248 ServiceStates Property states. For such models the documented mapping could be used as guideline.

B.3   Mapping between Models

B.3.1    Example Management Models

It is proposed to consider the management models from ITU-T Rec. X.731 and IETF RFC 4268 as example. One reason for a management model using ITU-T and IETF technologies is related to the origins of H.248 in these two standardization development organizations (SDO). Another motivation is the fact that RFC 4268 refers explicitly to X.731 and provides already an aligned management model (on top level).

Management models are typically distinguishing three different basic state models, which are related to the three primary factors that are affecting the management state of a managed object with regard to its corresponding resources' availability: operability, administration and usage. The correspondent three basic management state models could be combined.

The correlation with the H.248 ServiceStates Property with a single basic management state model (from RFC 4268), i.e. the operational state model, administrative state model or usage state model, may be used as starting point, but is typically not sufficient, e.g. when considering interactions between H.248 procedures and management procedures.

For this reason is a combined management state model proposed, based on the combination of operational and administrative states, see Table B.3.2.1/1.

Table B.3.2.1/1 - Basic Model Relations 

Relation of H.248 ServiceStates Property Model 
with Management Models

Control State Model
ITU-T Rec. H.248

Management State Models
ITU-T Rec. X.731/IETF RFC 4268

ServiceStates Property

«

Operational
State

Administrative
State

Usage
State

In-Service

«

Enabled

Unlocked

¾

Out-of-Service

«

Disabled

Unlocked

¾

Out-of-Service

«

Enabled

Locked

¾

Out-of-Service

«

Disabled

Locked

¾

NOTE 1

«

Enabled

Shutting Down

¾

Test

«

NOTE 2

NOTE 2

¾

NOTE 2:     There is no explicit state modelled concerning H.248 ServiceStates Property. There might be a transient state in the H.248 ServiceChange Command model, but this is out of scope here.

NOTE 1:     There is no explicit state modelled. "Test" is rather indicated via status attributes, which are used to qualify operational, administrative or usage states. Relevant in case of test might be the availability status attribute "in test", or the control status attributes "subject to test" or "reserved for test".

Other mapping schemes are principally possible.

B.4   Interaction Aspects

Purpose of this clause is to illustrate principle interaction between management use cases and H.248 procedures. Only a few examples are shown. A comprehensive list of all potenal interaction aspects between control plane (here 
H.248) and management plane.

Such interactions might be loosely coupled like in case of provisioning or pre-provisioning activities, but there are also some more tightly coupled interactions, particularly in the area of the ServiceChange Command.

For instance, certain actions, which are resulting in H.248 or management state changes, may result in correspondent state changes in the management or H.248 model respectively.

B.2   Scope

The scope of this document is only on the H.248 ServiceStates Property state model. The H.248 ServiceChange Command model (see Annex F/H.248.1) is not considered. The indicated management technologies and correspondent management state models are just examples. There are many other possibilities in mapping the H.248 ServiceStates Property on dedicated management state models. From that perspective, this document may assist to correlate such management state models with the H.248 ServiceStates Property.

This document provides an example mapping between the H.248 ServiceStates Property states and management plane state models according ITU-T Rec. X.731 and IETF RFC 4268. Other management plane models could be used as well for correlation with the H.248 ServiceStates Property states. For such models the documented mapping could be used as guideline.

B.3   Mapping between Models

B.3.1    Example Management Models

It is proposed to consider the management models from ITU-T Rec. X.731 and IETF RFC 4268 as example. One reason for a management model using ITU-T and IETF technologies is related to the origins of H.248 in these two standardization development organizations (SDO). Another motivation is the fact that RFC 4268 refers explicitly to X.731 and provides already an aligned management model (on top level).

Management models are typically distinguishing three different basic state models, which are related to the three primary factors that are affecting the management state of a managed object with regard to its corresponding resources' availability: operability, administration and usage. The correspondent three basic management state models could be combined.

The correlation with the H.248 ServiceStates Property with a single basic management state model (from RFC 4268), i.e. the operational state model, administrative state model or usage state model, may be used as starting point, but is typically not sufficient, e.g. when considering interactions between H.248 procedures and management procedures.

For this reason is a combined management state model proposed, based on the combination of operational and administrative states, see Table B.3.2.1/1.

Table B.3.2.1/1 - Basic Model Relations 

Relation of H.248 ServiceStates Property Model 
with Management Models

Control State Model
ITU-T Rec. H.248

Management State Models
ITU-T Rec. X.731/IETF RFC 4268

ServiceStates Property

«

Operational
State

Administrative
State

Usage
State

In-Service

«

Enabled

Unlocked

¾

Out-of-Service

«

Disabled

Unlocked

¾

Out-of-Service

«

Enabled

Locked

¾

Out-of-Service

«

Disabled

Locked

¾

NOTE 1

«

Enabled

Shutting Down

¾

Test

«

NOTE 2

NOTE 2

¾

NOTE 2:     There is no explicit state modelled concerning H.248 ServiceStates Property. There might be a transient state in the H.248 ServiceChange Command model, but this is out of scope here.

NOTE 1:     There is no explicit state modelled. "Test" is rather indicated via status attributes, which are used to qualify operational, administrative or usage states. Relevant in case of test might be the availability status attribute "in test", or the control status attributes "subject to test" or "reserved for test".

Other mapping schemes are principally possible.

B.4   Interaction Aspects

Purpose of this clause is to illustrate principle interaction between management use cases and H.248 procedures. Only a few examples are shown. A comprehensive list of all potential interaction aspects is out of scope of this document.

B.4.1    Effect of H.248 Actions on Management Models

Some ServiceChange procedures may affect the H.248 ServiceStates Property. For instance, the ServiceStates Property of a physical Termination could be changed from In-Service to Out-of-Service with a ServiceChangeMethod of "Forced" or "Graceful" and ServiceChangeReason #905 ("Termination taken out of service"), see Annex F.3.10.2 of [5]. 

Such a ServiceStates Property change may lead to a state transition in the management model from {enabled, unlocked} to {disabled, unlocked} when using the sample mapping of clause 3.2. That means that the operational state would change. Such a state change in the management model would be visible for the management system, but would not lead to a notification of the management system because the operational state is read-only in nature (see clause 7.1.1/X.731).

B.4.2    Effect of Management Model State Transition on H.248 Model

Only management actions in the areas of configuration management and/or fault management may principally have an interaction with the H.248 ServiceStates Property.

B.4.2.1    Configuration management

The management action is triggering an H.248 ServiceChange procedure. The management action may lead to a state transition in the management model, and also to a correspondent change of the H.248 ServiceStates Property. See also clause 10. 

B.4.2.2    Fault management

There are not any effects here because the flow of information is typically from the managed entity towards the management systems (see also next sub-clause).

B.4.3    Effect of failures in H.248 entities on State Transition in Management Model and H.248 Model

Such a failure scenario in an H.248 entity itself is triggering. See also clause 10. 

1            an H.248 ServiceChange procedure and also 

2            a notification (e.g. alarm) of the management system.

There may be correspondent state transitions in the management model and the H.248 ServiceStates Property model.

> From: John Wainwright [mailto:[email-masked]]
> Sent: Dienstag, 11. Dezember 2007 15:31
> To: [email-masked]
> Subject: [Megaco] Responses when line is OOS
>
> If a line is taken OOS as a result of management action and
> this is reported in the SVC message to the MGC, who also
> responds, how should we then respond to other messages from
> the MGC related to this line e.g.
> Audit messages.
>
> If an events descriptor was previously enabled for this line
> e.g. for onhook/offhook, are these events now ignored as long
> as the line is OOS?
>
> Thanks
> John
>
>

---

From: Giorgos Tintikakis <[email-masked]>
Date: Thu, 13 Dec 2007 11:20:35 +0200

Hello John,

Please check the same question/answer at next thread:
http://www1.ietf.org/mail-archive/web/megaco/current/msg05626.html

My understanding is that at transitioning to OutofService state
the active descriptors (signal and events) are cleared (or reverted to 
any existing provisional values) .

Regards,
Giorgos

---

From: Carsten Waitzmann <[email-masked]>
Date: Thu, 13 Dec 2007 12:12:40 +0100

Hello Giorgos,

I think it is not linked to the Service State. In the thread you are
referring to, the physical termination, after being reported as out of
service (ServiceChange message), is subtracted by the MGC which causes
the descriptors to default to empty or any provisioned value (see
H.248.1v3 chapter 6.2.4).

best regards
Carsten

-- 
Alcatel-Lucent Deutschland AG
Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026
Vorsitzender des Aufsichtsrats: Michael Oppenhoff
Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf
Henryk Wulf

---

From: Giorgos Tintikakis <[email-masked]>
Date: Thu, 13 Dec 2007 13:35:25 +0200

Hi Carsten,
Yes in case where a valid context exists, but it also covers the case 
where the termination is in the NULL context where no subtraction is 
ordered from MGC.

please check also the next part from thread:
"If the termination is already in the NULL context I still see that the 
descriptors revert back to their provisioned values and no modify is 
required."

Regards,
Giorgos

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 13 Dec 2007 13:15:38 +0100

>onhook/offhook, are these events now ignored as long as the line is
OOS?

The phy Term. is in OoS.
Independent of NULL or non-NULL Context, and
independent of events descriptor setting/values,
the MG will not sent any NOTIFY for events related to bearer traffic.
Just because it may not detect any event because there is "not any
bearer traffic" for consideration in OoS state in my understanding.
 
-Albrecht
 
PS
Other, non-bearer traffic events might be reported (if there are any for
phy Term's in the NULL context). 
E.g. H.248.36 for an eph Term in OoS may be reported.  

	From: Giorgos Tintikakis [mailto:[email-masked]] 
	Sent: Donnerstag, 13. Dezember 2007 12:35
	To: Waitzmann Carsten
	Cc: [email-masked]
	Subject: Re: [Megaco] Responses when line is OOS

	Hi Carsten, 
	Yes in case where a valid context exists, but it also covers the
case where the termination is in the NULL context where no subtraction
is ordered from MGC.
	
	please check also the next part from thread:
	"If the termination is already in the NULL context I still see
that the descriptors revert back to their provisioned values and no
modify is required." 
	
	Regards,
	Giorgos
	
	Carsten Waitzmann wrote: 

		Hello Giorgos,
		
		I think it is not linked to the Service State. In the
thread you are
		referring to, the physical termination, after being
reported as out of
		service (ServiceChange message), is subtracted by the
MGC which causes
		the descriptors to default to empty or any provisioned
value (see
		H.248.1v3 chapter 6.2.4).
		
		best regards
		Carsten

			Hello John,
			
			Please check the same question/answer at next
thread:

			My understanding is that at transitioning to
OutofService state
			the active descriptors (signal and events) are
cleared (or reverted to 
			any existing provisional values) .
			
			Regards,
			Giorgos

			John Wainwright wrote:

				If a line is taken OOS as a result of
management action and this is
				reported in the SVC message to the MGC,
who also responds, how should we
				then respond to other messages from the
MGC related to this line e.g.
				Audit messages.
				
				If an events descriptor was previously
enabled for this line e.g. for
				onhook/offhook, are these events now
ignored as long as the line is OOS?
				
				Thanks
				John

---

From: Giorgos Tintikakis <[email-masked]>
Date: Thu, 13 Dec 2007 16:34:39 +0200

You are right.
But please consider also the case when the termination return to 
"inService" with a new ServiceChange command.
then MGC should update the events descriptor by a Modify command as the 
old one is not valid anymore.
(in case no provisioned  values for the event descriptor exist)

Regards,
Giorgos

Schwarz Albrecht wrote:
> Other, non-bearer traffic events might be reported (if there are any 
> for phy Term's in the NULL context). 
>     *From:* Giorgos Tintikakis [mailto:[email-masked]]
>     *Sent:* Donnerstag, 13. Dezember 2007 12:35
>     *To:* Waitzmann Carsten
>     *Cc:* [email-masked]
>     *Subject:* Re: [Megaco] Responses when line is OOS
>
>     Hi Carsten,
>     case where the termination is in the NULL context where no
>     subtraction is ordered from MGC.
>
>     that the descriptors revert back to their provisioned values and
>     no modify is required."
>
>     Regards,
>     Giorgos
>
>     Carsten Waitzmann wrote:
>>     Hello Giorgos,
>>