Subject: [Megaco] Signals and Add, Move or Modify

From: Terry L Anderson <[email-masked]>
Date: Tue, 20 Nov 2001 15:06:43 -0500

Signals are properties of a termination and can be active on a
termination in either the NULL Context or a normal Context.  Signals are
stopped on receipt of a new SignalsDescriptor unless they are also
present in the new descriptor and have KeepAlive set.  But a new command
on the termination that does not contain a SignalsDescriptor should not
affect active signals.

There seem to be cases where this will lead to somewhat odd behavior,
especially where a termination is ADDed or MOVEd to a different
context.  I can see where it might be useful to have a signal (such as a
dialtone) continue when a termination is ADDed to a context, but Signals
can be specified to play to the interior of a context (that is, to the
other terminations in the context).  If such signal is active on a
termination that is ADDed or MOVEd to a context where other terminations
are present, the other terminations will begin hearing the signal
mid-stream.  Is this the intention?  (of course MGC can prevent this by
including an empty Signals Descriptor in any ADD or MOVE if it wishes).

Signals could also be active when a termination is SUBTRACTed.  A signal
playing to the exterior could continue when the termination is in the
NULL context, but continuing probably makes no sense when it was playing
to the interior or the termination was ephemeral.

It may also be difficult to implement this since new resources (new or
different codecs etc) may be needed mid-signal.  There is a similar
difficulty if the payload type is changed mid-signal, by using a MODIFY
without a SignalsDescriptor.  These cases may make logical sense but may
be difficult to implement.  I just want to confirm that this is the
intended behavior.

Life might be simpler if such commands implicitly stopped any active
signals unless specifically requesting them to continue (with a new
SignalsDescriptor containing the continuing signals and KeepAlive), but
I don't believe that that is what we have.

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "derrick.ding" <[email-masked]>
Date: Wed, 21 Nov 2001 14:54:40 +0800

Hi,Christian Groves！
   I agree with Christian.
   In my application on Megaco, MG release the resource of termination include signals when subtract request is received from MGC.
   While when MGC want to play signals on a termination in NULL context, MGC add this termination to a normal context with signal descriptor. 

2001-11-21 10:53:00 you write：
>G'Day Terry,
>
>I don't think it makes a difference to whether the signal plays
>externally or internally. The complication comes from playing a signal
>in the NULL context. 
>
>I agree with your analysis on the behvaiour of the ADD case.
>
>With the subtract I had always thought that if you subtracted a
>termination from a Context (physical or ephemeral) that resources (ie.
>signals) were released.
>
>Do you have a real world scenario of where you want the signal active
>when adding and subtracting from the NULL context?
>
>Regards, Christian
>
>Terry L Anderson wrote:
>> 
>_______________________________________________
>Megaco mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/megaco

            derrick.ding
            [email-masked]

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

---

From: "derrick.ding" <[email-masked]>
Date: Wed, 21 Nov 2001 14:54:40 +0800

Hi,Christian Groves！
   I agree with Christian.

            derrick.ding
            [email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 13:17:21 -0500

Subtract is one case easily dismissed: the Signals descriptor returns to its
default value.  Move in general has to be exercised with caution -- you
could end up with strem mismatches if more than the default stream is
active.

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 3:07 PM
To: Megaco Mailing List
Subject: [Megaco] Signals and Add, Move or Modify

--

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 13:17:21 -0500

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 3:07 PM
To: Megaco Mailing List
Subject: [Megaco] Signals and Add, Move or Modify

--

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Nov 2001 14:02:00 -0500

Comments below.

-----Original Message-----
From: tla [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 11:57 AM
To: Christian Groves
Cc: Megaco Mailing List
Subject: Re: [Megaco] Signals and Add, Move or Modify

> externally or internally. The complication comes from playing a signal

But you agree that this is permitted by current standard (playing a signal
on
termination in NULL)?  I believe that the residential gateway (analog lines)
example in Appendix A plays dialtone (and collects digit events) on lines
without adding them to a context.

[PTT] Yes, definitely, but to invoke those signals you have to send a
request for the termination while it is in the NULL context.  As I mentioned
in my previous reply in this thread, passage from an active context to NULL
in general removes all signals unless provisioning has set some up as
defaults.

> termination from a Context (physical or ephemeral) that resources (ie.

Is this stated somewhere?  I didn't see any such indication that signals
halted in the current spec.

[PTT]
See the first paragraph of section 6.2.4.

> when adding and subtracting from the NULL context?

Not really, I am just trying to see what a MG should implement if asked by
an
MGC.  I have always preferred to ADD a termination to a context before
collecting digits and playing a tone.  This way it is clear that the
termination is in use and removes any ambiguity that it might be selected by
a
future Add=$ (of course MG controls what it selects for $ anyway but getting
it out of NULL makes this simpler).  But I thought the standard (and the
Appendix A example) allowed doing all this in NULL.

Even if dialtone is started when termination is in NULL I would think it
would
be removed when the termination was ADDed (using an empty
SignalsDescriptor),
since presumably the ADD would then take place after all digits are
collected
and so dialtone would be done.  But if stopping the signal is not implicit,
I
am concerned about what the MG should do if the Add does not include any
signals descriptor.  Since I can see little or no use and implemention is
hard, I would have preferred it to implicitely stop, but am afraid that this
would be a change in spec.

[PTT]
The signals (and other properties) will be retained.  See text in 6.2.4.
The reference I can give you is based on
AVD-2155/draft-ietf-megaco-3015corr-00.txt.  Look at the second para before
the descriptor table.

--
-------------------------------------------------------
Terry L Anderson, DMTS                   [email-masked]
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------