Subject: RE: [Megaco] Question on the semantics of Subtract command

From: "Kamitses, Jerry" <[email-masked]>
Date: Fri, 17 Dec 2004 10:22:46 -0500

Tom,
Thanks for such a prompt reply. 

Regarding operation of the Subtract command, I am a little surprised that 
this important side effect of Subtract (which I learned of thru the grapevine) 
seems to be nowhere expressly mentioned in the RFC? The section that specifies 
signals and events doesn't mention it, and neither does the section on subtract, 
other than the reference to property that I cited below, where "property" seems 
to have acquired additional meaning. Elsewhere the RFC seems to view "properties" 
and "events and signals" as being distinct? For example, Section 6.2.1 Termination 
dynamics, contains the text:
   The Termination properties, and events and signals are described in
   the ensuing subclauses.  
This seems to say that "events and signals" are distinct from "properties"?
Likewise  6.2.3 Packages includes the text:
   Properties, Events, Signals and Statistics defined in Packages, as
   well as parameters to them, are referenced by identifiers (Ids).

Again suggesting that "Properties" and "Events, Signals" are different 
animals? Same again in section 6.2.4 Termination properties and 
descriptors:
	Terminations have properties.  
	The properties have unique PropertyIDs. 

This section (6.2.4) also addresses the effect of the Subtract command 
when it describes what occurs when a termination is returned to the 
NULL context.
	If not provisioned otherwise, the properties in all descriptors 
	except TerminationState and LocalControl default to empty/"no value" 
	when a Termination is first created or returned to the null Context.  

All use of the expression "property" in this section are clearly referring 
to Property type properties and not signals/events, for example: 
	... properties are referred to by a name consisting of the PackageName 
	and a PropertyId.  
	... Properties may be read-only or read/write.  

In addition, the RFC does take pains to specify that the Subtract command 
may not include any eventsDescriptor or signalsDescriptor. One seemingly 
straightforward inference of this restriction regarding Subtract is that 
the Subtract command is not intended to have any effect on the signal/event 
state of a termination (except for the obvious case that the subtract 
eliminates an ephemeral termination). The statement in section (6.2.4) 
	In general, if a Descriptor is completely omitted from one of the 
	aforementioned Commands, the properties in that Descriptor retain 
	their prior values for the Termination(s) upon which the Command acts.  
contributes to the conclusion that Subtract should have no effect on 
the eventsDescriptor or the signalsDescriptor (since these descriptors will 
always be completely omitted in the Subtract).  The key to this confusion 
is the vague use of "aforementioned Commands" instead precisely specifying 
the commands which apply.

If the MGC's intention is to stop a signal as part of a Subtract then 
a Modify with empty signalsDescriptor ahead of the Subtract seems like 
a pretty straightforward way to accomplish this.

Furthermore, if a signal is active on a termination in the null context, and 
an Add command that omits any eventsDescriptor or signalsDescriptor is sent 
to that termination, then does the protocol require the signal to be stopped 
in this case too?  If not (which I believe is the case?), then we seem to 
have this strange asymmetry regarding events/signals:  the event/signal 
can persist unaffected when the termination is added to a context but not 
survive the termination being removed. I don't quite understand the 
rationale behind this?

In light of the above I am a bit puzzled as to the definitive source of 
"a Subtract definitely ends an on-going signal"?  Apparently the source is 
not the actual RFC3525. Could it be in one of the implementer's guides, 
or some other email thread?

Lastly, regarding your comment:
  [subtract side effect] may possibly install an alternative if a 
  non-empty Signals descriptor was provisioned as the default for 
  the termination.

I am assuming the source for this in the RFC is again the text:
    When a provisioned Termination is Subtracted from a Context, its
    property values shall revert to:
    -  the default value, if specified for the property and not
       overridden by provisioning;
    -  otherwise, the provisioned value.

In this case I am somewhat unclear as to exactly how this works for signals?
If there is such a default signal provisioned for a termination then exactly 
when is it re-activated? Only as a side effect of the Subtract command, or 
might this also apply whenever the termination receives an empty 
signalsDescriptor? 

I also have a question regarding the effect of Subtract on actual property 
type "properties" for a termination. Property type properties can be altered 
via MGC commands that contain instances of the  propertyParm, present in the 
mediaDescriptor subdescriptors localControlDescriptor or terminationStateDescriptor. 

Instances of these descriptors may be present in Add and Modify type requests 
sent to a termination in either the NULL or a non-NULL context. 

If the MGC changes the value of a property type property of a termination while 
in the NULL context then according to the above RFC text this change will persist 
at most until the next Subtract. Correct?

Is there is no means available in the protocol for the MGC to make a more permanent 
change to a termination property type property that will persist across subsequent 
add/subtract commands? Is there no distinction between property type properties that 
are set when the termination is in a non-NULL context (which could be viewed as part 
of an active call) vs. those set while the termination is in the NULL context 
(which could be viewed more as semi-permanent)?

Also, while a termination is in a non-NULL context is it still valid for the MGC to 
send a modify to the NULL context for the termination? This isn't discussed in 
the section on Modify and I couldn't seem to find any other reference to this.
If the NULL context is still a valid context for commands while the termination 
is in a non-NULL context, and the MGC sets a property type property value, or 
signals and/or events, for the NULL context at that termination, then do these 
changes apply to the termination in the non-NULL context as well?  

Thanks again.

Happy Holidays

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: Thursday, December 16, 2004 8:33 PM
To: Kamitses, Jerry
Cc: [email-masked]; Christian Groves; Kevin Boyle
Subject: Re: [Megaco] Question on the semantics of Subtract command;
Question regarding Digitmap Completion Events

Answers below, marked by [PTT].

Kamitses, Jerry wrote:
> Reference RFC 3525    Gateway Control Protocol Version 1
> 
> 
> Question 1) I would appreciate some clarification regarding precise effect 
> of the Subtract command on physical terminations.  In Section  7.2.3 Subtract, 
> the final paragraph states:
> 
>    When a provisioned Termination is Subtracted from a Context, its
>    property values shall revert to:
>    -  the default value, if specified for the property and not
>       overridden by provisioning;
>    -  otherwise, the provisioned value.
> 
> 1a) I assume "provisioned Termination" in the 1st line should read "physical Termination"
> since the concept of "provisioned Termination" does not appear elsewhere in the RFC.
> Is this correct, or is there some other meaning for "provisioned Termination" that is 
> intended here?
> 
[PTT] I may have introduced this phrase once upon a time.  It's probably a red 
herring, but I have always believed that one could provision terminations that 
would otherwise be ephemerals -- PVCs in effect.  That's why the term, but I 
expect in normal practice this is identical with "physical termination".

> (1b) It is not clear to me from the context exactly what is meant by "property"? Is 
> "property" used to refer strictly to the formal concept of termination properties, 
> that is,  parameters that are assigned values via the 
>         propertyParm         = pkgdName parmValue
> productions in the formal syntax using the localControlDescriptor and/or terminationStateDescriptor.  
> 
> Or is "property" here used in some more generic sense to possibly refer to other 
> aspects of the termination state?
> 
> For example, if a subtract is sent to a termination with a currently active signal then 
> does the signal stop as a side effect of receiving the subtract, or should the signal 
> be unaffected by the subtract.?

[PTT] "Property" here is intended in the generic sense that all descriptor values 
are properties of the termination.  Thus a Subtract definitely ends an on-going 
signal, and may possibly install an alternative if a non-empty Signals descriptor 
was provisioned as the default for the termination.
> 
> Question 2) Digitmap Completion Events 
> 
> 2a)  Section 7.1.9 Events Descriptor contains the text:
>     The default streamID is 0, indicating that the event to be
>     detected is not related to a particular media stream.
> 
> We have assumed that streamID 0 also could mean the event is related to all 
> media streams. That is, for those events which apply to media streams, then 
> when there are one or more streams on the context, and the MGC wants to enable 
> an event concurrently on all streams, must the MGC send one instance of the 
> event with streamID 0, or must the MGC send multiple instances each a separate 
> non-0 streamID?
>
[PTT] One instance with streamID 0 will pick up digitmap completion events from 
all active streams.  If it is important to relate the event to the originating 
stream, you might want to enable the events against the individual streams.

> 2b) This section also contains the text: 
>   If a digit map completion event is present or implied in the
>    EventsDescriptor, the EventDM parameter is used to carry either the
>    name or the value of the associated digit map.  
> 
> Could you please explain "implied" digitmap completion event and provide a 
> pointer to RFC text that discusses this concept? 

[PTT] I believe this was meant to refer to the use of the "ALL" wildcard as 
described in the preceding paragraph.  I would have to look at the Megaco 
correspondance between February and May of 2000 to verify that.  (The text first 
appears in the RFC 2886 corrigendum to RFC 2885.)
> 
> 2c) Regarding the statement in section 7.1.14.6 DigitMap Activation
>    A digit map completion event that does not contain an eventDM field
>    in its requested actions field is considered an error.  
> We have encountered instances of the following message syntax
> 
>     ... Events = 1 { dd/ce }, DigitMap = { (0 | xxxxxxxx|x.#) } ...
> 
> Since the digitMapDescriptor in the above example omits the digitMapName, 
> then clearly it has no possible use except in the context of the associated 
> completion event.  Perhaps  this could be an instance of an "implied" digitMapDescriptor 
> for the completion event,  and be allowed even though it seems to technically violate 
> the correct syntax for the ce event, which should be 
> 
>     ... Events = 1 { dd/ce{ DigitMap = { (0 | xxxxxxxx|x.#) } }  }, ...
> 
> Is the 1st Events example above allowable ?
> 
[PTT] I think I'll leave this one for Kevin or Christian to comment on.
> 
> Thanks.
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Dec 2004 10:39:29 +1100

Hello Jerry,

The latest IG can be found at:
http://[email-masked]/av-arch/avc-site/2001-2004/0411_Gen/H_248_Sub-Series_IG.zip 

PW: Avguest

As Tom has clarified in his earlier email the behaviour that is intended was 
that a Subtract stops signals and returns values to default (or provisioned). 
Yes this wasn't described in the best way that is why it was updated in the IG 
to be made clearer.

I have attached a message from 2000 to show this has been the case for a long 
time and is not something we recently dreamed up.

===========================================================================
-------- Original Message --------
Subject: 	Re: Event and Signal descriptor on Subtract
Date: 	Thu, 20 Apr 2000 08:16:10 -0500
From: 	Tom-PT Taylor <[email-masked]>
Reply-To: 	Tom-PT Taylor <[email-masked]>
To: 	[email-masked]

Based on the E-mail I just put out yesterday, this would be so, but the
default values of these descriptors (in the absence of provisioned
values) would be "empty".

       -----Original Message-----
       From:   Hemant Agrawal [SMTP:[email-masked]]
       Sent:   Thursday, April 20, 2000 6:23 AM
       To:     [email-masked]
       Subject:        Event and Signal descriptor on Subtract

        Hi Brian, Tom, list,

        In ref to section 7.2.3 for Subtract command
        "When a provisioned Termination is Subtracted from a context, its
       property
        values shall revert to:
        *    the default value, if specified for the property and not
       overridden by
       provisioning,
        *    otherwise, the provisioned value."

         Is this action also valid for signal and event descriptor, that
       is, after
       a  termination
        is subtracted from a context, MG stops playing signals and stop
       listening
       for
        events (since the default value of Event & Signal Descriptor is
       NULL).

        thanks
        Hemant Agrawal

        ________________________________________
        Hemant Agrawal
        Ficon Technology
        E-mail: [email-masked]
        Web: http://www.ficon-tech.com
===========================================================================

In answer to your queury on "Also, while a termination is in a non-NULL context 
is it still valid for the MGC to send a modify to the NULL context for the 
termination?" I would say no, the MG would send back an error code "435 Name: 
Termination ID is not in specified Context"

Regards, Christian

> [PTT] I think I'll leave this one for Kevin or Christian to comment on.

Subject: Re: Event and Signal descriptor on Subtract
From: Tom-PT Taylor <[email-masked]>
To: [email-masked]
Date: Thu, 20 Apr 2000 08:16:10 -0500

Based on the E-mail I just put out yesterday, this would be so, but the
default values of these descriptors (in the absence of provisioned
values) would be "empty".

	-----Original Message----- 
From:   Hemant Agrawal [SMTP:[email-masked]] 
Sent:   Thursday, April 20, 2000 6:23 AM 
To:     [email-masked] 
Subject:        Event and Signal descriptor on Subtract 

	 Hi Brian, Tom, list, 

	 In ref to section 7.2.3 for Subtract command 
 "When a provisioned Termination is Subtracted from a context, its
property 
 values shall revert to: 
 *    the default value, if specified for the property and not
overridden by 
provisioning, 
 *    otherwise, the provisioned value." 

	  Is this action also valid for signal and event descriptor,
that is, after 
a  termination 
 is subtracted from a context, MG stops playing signals and stop
listening 
for 
 events (since the default value of Event & Signal Descriptor is NULL). 

	 thanks 
 Hemant Agrawal 

	 ________________________________________ 
 Hemant Agrawal 
 Ficon Technology 
 E-mail: [email-masked] 
 Web: http://www.ficon-tech.com <http://www.ficon-tech.com>