Subject: RE: [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

Christian Groves wrote:

> 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.

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.

> 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.

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.

> Do you have a real world scenario of where you want the signal active
> 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.

> Regards, Christian
>
> Terry L Anderson wrote:
> >
> > 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

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

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 22 Nov 2001 11:21:52 +1100

G'Day Terry,

I think Tom has covered your points. I don't have anymore to add.

Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 22 Nov 2001 11:21:52 +1100

G'Day Terry,

Christian