Subject: RE: [Megaco] MOVE from MGC to TG supporting CCS

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 7 Jun 2002 13:47:34 -0400

The MG doesn't trigger anything in the MGC.  Call processing dictates what
commands are sent by the MGC.

It may very well be that there are no scenarios that require a Move command
to be initiated by the MGC.  Then again, there may be a scenario that
requires it.  Analysis of the call processing scenarios relevant to your
implementation will reveal if Move is needed or not.

Kevin

-----Original Message-----
From: Elango K [mailto:[email-masked]]
Sent: Friday, June 07, 2002 1:22 AM
To: 'Watson Ding'; [email-masked]
Subject: RE: [Megaco] MOVE from MGC to TG supporting CCS

Hi Watson,

Thanks for the reply.

But is there anything that can be done in the TG where the signalling mode
is CCS, which would make the MGC send a MOVE command ?

Thanks,
Elango.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Watson Ding
Sent: Friday, 7 June 2002 9:16 AM
To: [email-masked]; [email-masked]
Subject: Re: [Megaco] MOVE from MGC to TG supporting CCS

I don't think MG can tirgger a MOVE command.
only MGC can dicide to send a MOVE command or not.

----- Original Message -----
From: Elango K <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 03, 2002 9:31 PM
Subject: [Megaco] MOVE from MGC to TG supporting CCS

> Hi all,
>
> I've the following scenario.
>
> The MGC is connected to a TG where the signalling mode is CCS. In the TG
> point of view, how can we trigger the MGC to initiate a MOVE command.
>
> This scenario is similar to the case in RG, where with the notification of
> flashhook, we could expect a MOVE from the MGC.
>
> Is the above scenario possible ? Pls do clarify.
>
> Thanks & Regards,
> Elango.
>
>
> "Be kind, for everyone you meet is fighting a harder battle."  - Plato
>
>
>
***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> 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.
> FSL 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

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

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
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. 
FSL 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

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

---

From: "Elango K" <[email-masked]>
Date: Mon, 10 Jun 2002 09:34:38 +0530

Hi Kevin and list,

I got your point clear.

Could anyone give me pointers, where I could get information regarding the
call processing scenario involving a TG supporting CCS implementation.

Thanks,
Elango.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kevin Boyle
Sent: Friday, 7 June 2002 11:18 PM
To: [email-masked]; 'Watson Ding'; [email-masked]
Subject: RE: [Megaco] MOVE from MGC to TG supporting CCS

Kevin

-----Original Message-----
From: Elango K [mailto:[email-masked]]
Sent: Friday, June 07, 2002 1:22 AM
To: 'Watson Ding'; [email-masked]
Subject: RE: [Megaco] MOVE from MGC to TG supporting CCS

Hi Watson,

Thanks for the reply.

Thanks,
Elango.

---

From: "Elango K" <[email-masked]>
Date: Mon, 10 Jun 2002 09:34:38 +0530

Hi Kevin and list,

I got your point clear.

Thanks,
Elango.

-----Original Message-----

Kevin

-----Original Message-----
From: Elango K [mailto:[email-masked]]
Sent: Friday, June 07, 2002 1:22 AM
To: 'Watson Ding'; [email-masked]
Subject: RE: [Megaco] MOVE from MGC to TG supporting CCS

Hi Watson,

Thanks for the reply.

Thanks,
Elango.

---

From: Al Varney <[email-masked]>
Date: Mon, 10 Jun 2002 23:23:13 -0500

>call processing scenario involving a TG supporting CCS implementation.

    I can't answer for Kevin, but off-hand the only trunk-based service 
involving a MOVE is likely to be those queuing or terminating into one 
context and then MOVEing to another when an attendant or operator is 
available.  (This isn't unique to CCS -- it applies to any trunk.)  For 
example, if an incoming CCS call is placed into a context in order to 
deliver an announcement ("all operators are busy"), a MOVE could be used to 
connect the call to a context already active to a newly-idled attendant 
position.  Or a MOVE could be used if a different context is to be used 
after waiting for a period ("please stay on the line").  These all involve 
MOVEing an incoming trunk call to a context that is "fixed" in its 
attachment to an attendant or announcement.

    The only other reason I can think of to MOVE a trunk (or a line, for 
that matter) would be if the trunk could invoke a request to place an 
existing call on HOLD, and then be connected to an existing independent 
call that already had a context (call waiting? call park?).   Telcordia had 
some requirements at one time for CCS-based operator services that might 
have invoked a "hold" request on CCS trunks.  You could look try looking 
for updated requirements on their Web site.

Al Varney

---

From: Al Varney <[email-masked]>
Date: Mon, 10 Jun 2002 23:23:13 -0500

Al Varney