Subject: wildcarded termination in Move

From: Sachin Mittal <[email-masked]>
Date: Tue, 17 Oct 2000 15:21:40 +0530

If there are three terminations in an MG
abcd
abce
xyz.
Say abcd  is in Context ID = 1 and both abce and xyz is in NULL Context.
If MGC says Move with ContextID = $ and termination as abc*, what should the
MG do
1. Consider abce while resolving wildcarded abc* -
 Move is valid for abcd (it's in non-NULL context) and invalid for
abce (move is not allowed to move from and to a NULL Context)
2. Don't consider terminations in NULL Context for resolving wildcard since
the basic idea is not to Move to or from NULL Context.

The first option has an impact on further commands in the transaction since a
failure
with one command can cause the side effect of other commands being not executed.

Sachin

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Oct 2000 08:27:41 -0400

> If MGC says Move with ContextID = $ and termination as abc*,
First of all, I think this is illegal, or at least nonsensical.
You CAN'T create a new contextId with CHOOSE.
So if it is legal, you are asking for Russian Roulette - pick
a context where the resulting command would be legal, and do it.
If there is more than one, then it's random which one

> abce (move is not allowed to move from and to a NULL Context)
abcd is valid, abce is not valid

> the basic idea is not to Move to or from NULL Context.
This is correct

> with one command can cause the side effect of other commands
True, but in general if the MGC was foolish enough to do this,
it deserves what it gets.

Brian

---

From: Chanchal Hassija <[email-masked]>
Date: Wed, 18 Oct 2000 10:09:58 +0530

Hi Brian,

If you mean to say that Move with ContextID = $ is nonsensical --- I beg to
differ......

Consider a simple call scenario -- A is talking to B..... and now A wants to put
B on hold and call up C......The simplest way to do it as per my understanding
would be -- MGC shall tell MG to Move A to a new context (Move - ContextID=$ and
TermID = A) where it shall talk to C, and once it is done, move it back to the
context where it was talking to B......

What is your opinion about this....

Thanks
Chanchal....

"Rosen, Brian" <[email-masked]> on 10/17/2000 05:57:41 PM

Please respond to "Rosen, Brian" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Chanchal Hassija/HSS)

Subject:  Re: wildcarded termination in Move

This is correct

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Oct 2000 08:01:06 -0400

Only Add can create a new context:
  "In general, an Add command is used to add Terminations to Contexts.
   If the MGC does not specify an existing Context to which the
   Termination is to be added, the MG creates a new Context.  "

A way to do the consultation hold is to create the new context with
C and move A to that Context.

I'll note that I was a little surprised to read:
"The Termination is either created, or taken from the null Context"
(although I may have wrote it!), since this prohibits an Add of
a termination already in another context.  I'm not sure why we
prohibit that.  I do think there is little practical difficulty in
keeping that restriction.  If we did relax that restriction, you
could do Context=${Add=A{....

Brian

> -----Original Message-----
> From: Chanchal Hassija [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2000 12:40 AM

---

From: Chanchal Hassija <[email-masked]>
Date: Wed, 18 Oct 2000 17:30:32 +0530

Hello Brian....

Do we have any logical reasoning to prohibit MOVE of a termination to
contextID=$.... apart from the fact that it is stated in the protocol.......

Thanks
Chanchal.....

"Rosen, Brian" <[email-masked]> on 10/18/2000 05:31:06 PM

To:   Chanchal Hassija/HSS@HSS, [email-masked]
cc:

Subject:  RE: wildcarded termination in Move

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Oct 2000 08:43:37 -0400

Yes, but it's not all that compelling.
Add is a special case of Move - you don't really need Add/Subtract,
you could do it all with Move.  We tried to keep the functions
separate by restricting move to the clear case of from this context
to that context, with Add being the command you usually use for
creating new contexts or dealing with terminations in null.

Like I said, not all that compelling.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2000 8:01 AM
> To: Rosen, Brian
> Cc: [email-masked]

---

From: Kapil Nayar <[email-masked]>
Date: Wed, 18 Oct 2000 17:58:55 +0530

Hi

If you remove this restriction then why you need Move, i will always use Add to
either:
1. Add a termination to a context from null context
2. Move (read it as Add) a termination to a context from a non-NULL context.

-Kapil Nayar
Hughes Software Systems

"Rosen, Brian" <[email-masked]> on 10/18/2000 05:31:06 PM

To:   [email-masked]
cc:    (bcc: Kapil Nayar/HSS)

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Oct 2000 09:00:58 -0400

Ya, that's one of the reasons it's probably there - separating
functions of Move and Add.

Probably best to leave things as they are.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2000 8:29 AM
> To: Rosen, Brian

---

From: Bob Lukas <[email-masked]>
Date: Wed, 18 Oct 2000 10:59:02 -0700

One good reason for allowing MOVE $ is if the MGC wants to implement on-hold
by moving the ephermeral RTP termination to a "holding context", rather than
moving the physical termination. Another good reason is if the logic of the
MGC wants to implement handsfree/handset transfer by moving the existing RTP
to a new context, then adding the physical termination.
In both these cases, a subtract/add is not equivalent to a move, because the
ephermeral termination will get destroyed during the subtract.

You could force the MGC developer to modify his logic to do it another way,
but why unnecessarily create restrictions.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 5:44 AM
To: [email-masked]
Subject: Re: wildcarded termination in Move

Brian

---

From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 19 Oct 2000 11:01:54 +0200

Hello Brian, all

If things are left as they are, it seems that the case described below is
simply impossible:

(1)
             | +-------------------------------------------------+  | 
             | |Context C1                                       |  | 
             | |  +-------------+                +-------------+ |  | 
             | |  | (Term. T1)  |   +-----+      | (Term. T2)  | |  | 
           <-+--->| RTP Stream  |---|  *  |------| RTP Stream  |<---+-> 
             | |  +-------------+   +-----+      +-------------+ |  | 
             | +-------------------------------------------------+  | 
(2)

             | +-------------------------------------------------+  | 
             | |Context C1                                       |  | 
             | |  +-------------+                                    |  | 
             | |  | (Term. T1)  |   +-----+                      |  | 
           <-+--->| RTP Stream  |---|  *  |                      |  |
             | |  +-------------+   +-----+                      |  | 
             | +-------------------------------------------------+  | 
             | +-------------------------------------------------+  | 
             | |Context C2                                       |  | 
             | |                                 +-------------+ |  | 
             | |                    +-----+      | (Term. T2)  | |  | 
             | |                    |  *  |------| RTP Stream  |<---+-> 
             | |                    +-----+      +-------------+ |  | 
             | +-------------------------------------------------+  | 

C2 didn't exist in (1). How to go from (1) to (2)?
- We can't use a MOVE $ (too bad..)
- we can't  use Context = $ {Add = T2} because T2 is in a non-NULL context
- we can't use "Subtract/Add" because we have only RTP Terminations we don't
want to remove.

This is not a textbook case, as far as this case may occur if the Call
Server/MGC is connected to the IN and receives, for instance, an INAP
"SplitLeg" message requiring such an handling of connections.

Regards,

               ```
              (o o)
----------oOO--(_)-OOo--------------
Jean-Emmanuel CHAPRON
FRANCE TELECOM R&D
DAC/ACE
38-40 rue du général Leclerc
92794 Issy-les-Moulineaux Cedex 9 - France
Tel: +33 1 45 29 64 50
-------------------------------------

> -----Message d'origine-----
> De : Rosen, Brian [mailto:[email-masked]]
> Envoyé : mercredi 18 octobre 2000 15:01
> À : [email-masked]
> Objet : Re: wildcarded termination in Move
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Oct 2000 09:33:30 -0400

I may be finessing the answer but
   Context=1{Subtract=T1....
   Context=${Add=T1...
gets you an equivalent

Brian

> From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS
> [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 5:02 AM
>              | |  +-------------+                             
>        |  |

---

From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 19 Oct 2000 15:45:06 +0200

I don't understand your solution: T1 is an ephemeral Termination: its TermID
is not provisionned in the MG. As soon as T1 is subtracted from C1, it
disappears, and its TermID too. How can the MGC re-use this TermID to add it
to a new Context?
Can the MGC set the TermID of an ephemeral Termination when it creates it? 

               ```
              (o o)
----------oOO--(_)-OOo--------------
Jean-Emmanuel CHAPRON
FRANCE TELECOM R&D
DAC/ACE

> De : Rosen, Brian [mailto:[email-masked]]
> Envoyé : jeudi 19 octobre 2000 15:34
> À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS';
> [email-masked]
> Objet : RE: wildcarded termination in Move
> 
> 
> >              | 
> +-------------------------------------------------+  | 
> >              | |Context C1                                  
>      |  | 
> >              | |  +-------------+                
> +-------------+ |  | 
> >              | 
> +-------------------------------------------------+  | 
> > (2)
> > 
> >              | 
> +-------------------------------------------------+  | 
> >              | |Context C1                                  
>      |  | 
> >              | |  +-------------+                             
> >        |  | 
> >              | 
> +-------------------------------------------------+  | 
> >              | 
> +-------------------------------------------------+  | 
> >              | |Context C2                                  
>      |  | 
> >              | |                                 
> +-------------+ |  | 
> >              | |                    +-----+      | (Term. 
> T2)  | |  | 
> >              | 
> +-------------------------------------------------+  | 
> > 
> >

---

From: Fabien Capoen <[email-masked]>
Date: Thu, 19 Oct 2000 17:09:31 +0200

If I can dare to speak on this list ... (to introduce myself, I work on 'NGN' standards for alcatel),
on this subject I have the following thoughts:

- there needs to be a mean (for a service as simple as call holding) to temporarily 'separate' terminations being in the same context whatever their nature (physical/ephemeral)

- the 'Context=${Move=' solution seems the only one (we could think of 2 other ones: the first to allow add on terminations being in a not null context, but this one has already been rejected because it breaks the add/move complementarity - move becomes
just a special case of add; the second being a special NULL-like context: the ONHOLD context, for ephemeral terminations. This one is not very elegant)

- the 'Context=${Move=' solution does not break the add/move complementarity: add remains reserved for non existing terminations or terminations in the null context, whereas move is reserved for terminations in a not null context

- I have looked in the standard, and I could not see it explicitely forbidden. The only thing is that it is not explicitely allowed: in §6.1, the creation of a new context is only described for the add command. Changing 'In general, an Add command is used
to add Terminations to Contexts' of §6.1 into 'In general, an Add OR MOVE command is used to add Terminations to Contexts' could solve the problem.
And really, isn't it true to say that move also adds terminations to a context ? Isn't the only difference between move and add on the nature of the termination on which the add/move is applied ?

The question I have is then: what concrete problems do people see with allowing 'context=$' in a move request ?

     Regards ... Fabien C.

                                                              
                                                              
 cc:      (bcc: Fabien CAPOEN/FR/ALCATEL)                     

Woops, sorry, didn't pay close enough attention.  Your example has TWO
RTP streams and no physical terminations.  Unusual, but legal.

Well, I'm stuck.  I can think of stupid things to do, but nothing
that looks useful.  Maybe a change is warranted.

Need other opinions on allowing Context=${Move=...

Brian

> Sent: Thursday, October 19, 2000 9:45 AM
> > > > > > Consider a simple call scenario -- A is talking to
> B..... and
> > > > > > now A wants to put
> > > > > > B on hold and call up C......The simplest way to do
> it as per
> > > > > > my understanding
> > > > > > > If MGC says Move with ContextID = $ and
> termination as abc*,
> > > > > > > what should the
> > > > > > > MG do
> > > > > > > 2. Don't consider terminations in NULL Context
> for resolving
> > > > > > > wildcard since
> > > > > > > with one command can cause the side effect of
> other commands
> > > > > > > being not executed.

---

From: "Rupsis, Paul" <[email-masked]>
Date: Thu, 19 Oct 2000 15:47:05 -0400

> there needs to be a means (for a service as simple as call holding)
> to temporarily 'separate' terminations being in the same context
> whatever their nature (physical/ephemeral)

Isn't that what Topology provides (e.g., Context = C1 {Topology{T1, T2,
isolate}} )

One problem with enabling Moves of terminations in and out of contexts is
that statistics are reset. 

Paul Rupsis

-----Original Message-----
From: Fabien Capoen [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 10:10 AM
To: [email-masked]
Subject: Re: wildcarded termination in Move

If I can dare to speak on this list ... (to introduce myself, I work on
'NGN' standards for alcatel),
on this subject I have the following thoughts:

- there needs to be a mean (for a service as simple as call holding) to
temporarily 'separate' terminations being in the same context whatever their
nature (physical/ephemeral)

- the 'Context=${Move=' solution seems the only one (we could think of 2
other ones: the first to allow add on terminations being in a not null
context, but this one has already been rejected because it breaks the
add/move complementarity - move becomes
just a special case of add; the second being a special NULL-like context:
the ONHOLD context, for ephemeral terminations. This one is not very
elegant)

- the 'Context=${Move=' solution does not break the add/move
complementarity: add remains reserved for non existing terminations or
terminations in the null context, whereas move is reserved for terminations
in a not null context

- I have looked in the standard, and I could not see it explicitely
forbidden. The only thing is that it is not explicitely allowed: in §6.1,
the creation of a new context is only described for the add command.
Changing 'In general, an Add command is used
to add Terminations to Contexts' of §6.1 into 'In general, an Add OR MOVE
command is used to add Terminations to Contexts' could solve the problem.
And really, isn't it true to say that move also adds terminations to a
context ? Isn't the only difference between move and add on the nature of
the termination on which the add/move is applied ?

The question I have is then: what concrete problems do people see with
allowing 'context=$' in a move request ?

     Regards ... Fabien C.

                                                              

                                                              

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 20 Oct 2000 08:07:09 -0400

I did think it was not allowed, but since I think we need it,
I'm more than happy to use your interpretation!

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 8:02 PM
> To: Rosen, Brian
> G'Day all,
> I'm really confused now, taking sentences out of context (pardon the
> pun) can add a little confusion.
> 
> The MOVE command chapter in H248 doesn't not prohibit moving a
> termination to Context "?". It mentions target Context ID. 
> 
> The Context chapter says:
> "In general, an Add command is used to add Terminations to 
> Contexts."  
> and the sentence after:
> "If the MGC does not specify an existing Context to which the
> Termination is to be added, the MG creates a new Context.talks about
> that if Context "?" is specified then a context ID is provided."
> 
> The "In general" statement cited below is in the sentence about a
> termination "?" and an ADD command. 
> 
> The "If the MG...." statements talks about Context "?".
> 
> MOVE Context "?", ta seems to me to be a fundamental part of what we
> defined and I don't see where this is disallowed. To clarify things at
> most you could put a CR linefeed after the in general sentence above.
> 
> Cheers, Christian
> 
> 
> "Rosen, Brian" wrote:
> > 
> > > > > > > If you remove this restriction then why you need 
> Move, i will
> > > > > > > always use Add to
> > > > > > > either:
> > > > > > > > TermID = A) where it shall talk to C, and once 
> it is done,
> > > > > > > > move it back to the
> > > > > > > > > Say abcd  is in Context ID = 1 and both abce 
> and xyz is in
> > > > > > > > > NULL Context.
> > > > > > > > > The first option has an impact on further 
> commands in the
> > > > > > > > > transaction since a
> > > > > > > > > failure

---

From: "Nguyen, Chuong" <[email-masked]>
Date: Fri, 20 Oct 2000 12:43:43 -0500

-----Original Message-----
From: Bob Lukas [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 12:59 PM
To: [email-masked]
Subject: Re: wildcarded termination in Move

One good reason for allowing MOVE $ is if the MGC wants to implement on-hold
by moving the ephermeral RTP termination to a "holding context", rather than
moving the physical termination.

<cnn>
General comment:  To either put the physical or ephemeral term on hold,
one could use the topology/isolate instead of creating a hold context.
From the original question after isolating the required termination,
one can add Termination C to the same context.
Therefore a Move would not even be needed to start with.

But if one really wants to use a Move, one should Add Term C first.
Otherwise if there was an error in Adding Term C, one would have to clean -
either Move Term A back to the original context or cleanup both contexts.

Another good reason is if the logic of the

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 5:44 AM
To: [email-masked]
Subject: Re: wildcarded termination in Move

Brian

---

From: "Nguyen, Chuong" <[email-masked]>
Date: Fri, 20 Oct 2000 13:09:50 -0500

-----Original Message-----
From: Rupsis, Paul [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 2:47 PM
To: [email-masked]
Subject: Re: wildcarded termination in Move

I think only Subtract can reset statistics.
Move does not reset statistics.

Paul Rupsis

-----Original Message-----
From: Fabien Capoen [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 10:10 AM
To: [email-masked]
Subject: Re: wildcarded termination in Move

     Regards ... Fabien C.

                                                              

                                                              

Brian

---

From: "Rupsis, Paul" <[email-masked]>
Date: Fri, 20 Oct 2000 14:19:14 -0400

> Chuong Nguyen wrote:
> Move does not reset statistics

If that is the case, then what does the "dur" statistic in the network
package [Section E.11.4] reflect when an ephemeral has been moved into/outof
different contexts?

  "StatisticsID: dur (0x0001) 
   Description: Provides duration of time the termination has been in the
context."
   
It is also then confusing what is meant in  Section 7.2.4 "Move Command",
when it states:

"By convention, the Termination is subtracted from its previous Context."

This *seems* to imply that statistics should be reset due to the subtract.

Paul Rupsis

-----Original Message-----
From: Nguyen, Chuong [mailto:[email-masked]]
Sent: Friday, October 20, 2000 1:10 PM
To: 'Rupsis, Paul'; [email-masked]
Subject: RE: wildcarded termination in Move

-----Original Message-----
From: Rupsis, Paul [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 2:47 PM
To: [email-masked]
Subject: Re: wildcarded termination in Move

Paul Rupsis

-----Original Message-----
From: Fabien Capoen [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 10:10 AM
To: [email-masked]
Subject: Re: wildcarded termination in Move

     Regards ... Fabien C.

                                                              

                                                              

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 13:55:37 -0500

Don't consider terminations in NULL context for MOVE.  I know it's an
arbitrary choice, but it's more sensible than failing a transaction by
trying something that shouldn't have been tried in the first place.

> From: Sachin Mittal [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 5:52 AM
> Subject: wildcarded termination in Move
>
>