Subject: [Megaco] Service change Restart

From: [email-masked]
Date: Thu, 13 Mar 2003 09:07:04 +0530

Hi List
I have a query regarding the processing of Service Change Restart.
consider the following scenario:

Termination is in state InService.
Command recieved from MGC to Restart the termination (with or wothout delay).

what MG could possibly do in this case?

Thanks
Sachin Gupta

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) 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. HSS 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

---

From: [email-masked]
Date: Fri, 14 Mar 2003 11:47:37 +0530

How about ServiceChange Restart on ROOT from MGC?Does the protocol inhibit it?
(It can be an easier means for the MGC to inform MG to delete all contexts
rather than 'Subtract'ing each of them, when MGC is taken gracefully
out-of-service)

Tom Taylor <[email-masked]> on 03/14/2003 12:27:35 AM

To:   Sachin Gupta-PNGN/HSS@HSS, Megaco List <[email-masked]>
cc:    (bcc: Kushanava Laha/HSS)

Subject:  Re: [Megaco] Service change Restart

I agree that it's very difficult to assign any real meaning to an MGC-initiated
restart of a termination.  My background in switch software development tells me
that a restart clears certain aspects of state.  However, that makes little
sense in
the Megaco case, because the MGC can do that directly by subtracting the
termination
from any context it is in and resetting descriptors if it is not in a context.

Conclusion: the only thing an MGC-initiated restart of a termination does is
change
its state to in-service if it is not already there.

> what MG could possibly do in this case?
[disclaimer snipped]

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 14 Mar 2003 10:03:23 -0500

This work is ongoing in SG16 as future Annex F.  Both of these items are
intended to be clarified by the new work.

The input documents to the San Jose Rapporteurs' Meeting can be found as
AVD-2310, AVD-2311, and AVD-2298 at
ftp://standard.pictel.com/avc-site/0302_San/.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

This is where the RFC is completely inadequate as it stands.  I wouldn't
mind seeing 
it rewritten to specify separately what happens for ServiceChange on ROOT
vs. 
ServiceChange on individual terminations.  With regard to the latter, there
is also 
something else I'd like to see ironed out: the service state is a writable
property 
in TerminationState, yet it is manipulated by ServiceChange.  One or the
other of 
these should go.

I am quite prepared to submit a proposal for new text for section 7.2.8 in 
particular.  Would there be interest in reviewing such a proposal?  We could
submit 
it as a contribution into SG 16's May meeting if that is workable.

[email-masked] wrote:
> 
> How about ServiceChange Restart on ROOT from MGC?Does the protocol 
> inhibit it? (It can be an easier means for the MGC to inform MG to 
> delete all contexts rather than 'Subtract'ing each of them, when MGC 
> is taken gracefully
> out-of-service)
> 
> 
> 
> 
> 
> I agree that it's very difficult to assign any real meaning to an 
> MGC-initiated restart of a termination.  My background in switch 
> software development tells me that a restart clears certain aspects of 
> state.  However, that makes little sense in the Megaco case, because 
> the MGC can do that directly by subtracting the termination
> Conclusion: the only thing an MGC-initiated restart of a termination 
> does is change its state to in-service if it is not already there.
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 14 Mar 2003 10:03:23 -0500

Kevin

---

From: [email-masked]
Date: Mon, 17 Mar 2003 12:14:15 +0530

Hi
     Related to Service change restart I have few queries:

1) What should MG do when it receives Service Change Restart on a already
inservice termination which is in Non-Null context
     Should it give a error response or whether MG should clear the call and
remove the termination from the context ?

2) If ServiceChange Restart with delay is recd. for an already Inservice
termination which may or may not be in call then what should be
     MG behaviour. Should it mark the termination as Out-Of-Service till the
delay timer expires and remove the termination from the context
    or give a error response ?

    In both of the above cases if MG were to give a error response then there is
no error-code defined which specifies that MG is already
in the state which MGC has requested.

3) What should be the MGC behaviour in the following scenario:
     1) MGC recevies a Service Change graceful with NonNull delay for a
termination in context.
     2) Now MG want to cancel the graceful timer. The only way do currently is
by sending a
          service Change Restart.
     Now what should be MGC behaviour. Should it only stop the timer and
continue the call or end the call and the mark the termination
     as Inservice.

Pls Comment.

Regards
Venkat

Tom Taylor <[email-masked]> on 03/13/2003 06:57:35 PM

cc:

[disclaimer snipped]

---

From: [email-masked]
Date: Mon, 17 Mar 2003 12:14:15 +0530

Hi

Pls Comment.

Regards
Venkat

[disclaimer snipped]

---

From: [email-masked]
Date: Mon, 17 Mar 2003 19:51:40 +0530

I would surely appreciate a symmetry (if not completely) in the ServiceChange
method.

regards,
Kushanava

Tom Taylor <[email-masked]> on 03/14/2003 08:00:18 PM

To:   Kushanava Laha/HSS@HSS
cc:   Sachin Gupta-PNGN/HSS@HSS, Megaco List <[email-masked]>

This is where the RFC is completely inadequate as it stands.  I wouldn't mind
seeing
it rewritten to specify separately what happens for ServiceChange on ROOT vs.
ServiceChange on individual terminations.  With regard to the latter, there is
also
something else I'd like to see ironed out: the service state is a writable
property
in TerminationState, yet it is manipulated by ServiceChange.  One or the other
of
these should go.

> I agree that it's very difficult to assign any real meaning to an
MGC-initiated

---

From: [email-masked]
Date: Mon, 17 Mar 2003 19:51:40 +0530

regards,
Kushanava

MGC-initiated

---

From: [email-masked]
Date: Tue, 18 Mar 2003 09:25:04 +0530

Hi Kevin

Thanks for the useful pointer...
I did like to know if the Annex-F is intended to be part of H.248v2 only or will
also be applicable to H.248v1.
Any information about the time lines by when it would be finalised/ freezed.

regards,
-kapil nayar
http://www.hssworld.com

"Kevin Boyle" <[email-masked]> on 03/14/2003 08:33:23 PM

To:   "Tom-PT Taylor" <[email-masked]>, Kushanava Laha/HSS@HSS
cc:   Sachin Gupta-PNGN/HSS@HSS, Megaco List <[email-masked]> (bcc: Kapil
      Nayar/HSS)

Subject:  RE: [Megaco] Service change Restart

Kevin

---

From: [email-masked]
Date: Tue, 18 Mar 2003 09:25:04 +0530

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:09:19 +0530

Hi

2) If ServiceChange Restart with delay is recd by MG  for an already Inservice

3) If Service Change Graceful with delay is    received by MG for an already out
of service termination then how should MG behave?
    Should it mark the termination in-service right now and after timer expiry
mark it out-of-service or should it give an error?

In all of the above cases if MG were to give a error response then there is no
error-code defined which specifies that MG is already
in the state which MGC has requested , however there is an error-code
"Not-Ready" defined as
"The command directed to a  termination was not executed because of the service
state of the termination"
which can be used in these situations for conveying MGC that requested operation
is not done.

I Hope all these issues are addressed in the SG16 Annex F.

Regards
Venkat

[email-masked] on 03/18/2003 09:25:04 AM

To:   "Kevin Boyle" <[email-masked]>
cc:   "Tom-PT Taylor" <[email-masked]>, Kushanava Laha/HSS@HSS,
      Sachin Gupta-PNGN/HSS@HSS, Megaco List <[email-masked]> (bcc: B Venkat
      S.R Swamy/HSS)

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:09:19 +0530

Hi

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 18 Mar 2003 13:57:46 -0500

The current plan is to incorporate it back into both V1 and V2 (since the
new Annex doesn't change the existing spec, it only makes clarifications).
The current timeline is May, however, I wouldn't be surprised if the Annex
will be held until February 2004.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 17, 2003 10:55 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]; [email-masked];
Megaco List

Hi Kevin

Thanks for the useful pointer...
I did like to know if the Annex-F is intended to be part of H.248v2 only or
will also be applicable to H.248v1. Any information about the time lines by
when it would be finalised/ freezed.

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

This is where the RFC is completely inadequate as it stands.  I wouldn't
mind seeing it rewritten to specify separately what happens for
ServiceChange on ROOT vs. ServiceChange on individual terminations.  With
regard to the latter, there is also something else I'd like to see ironed
out: the service state is a writable property in TerminationState, yet it is
manipulated by ServiceChange.  One or the other of these should go.

I am quite prepared to submit a proposal for new text for section 7.2.8 in
particular.  Would there be interest in reviewing such a proposal?  We could
submit it as a contribution into SG 16's May meeting if that is workable.

[email-masked] wrote:
> the MGC can do that directly by subtracting the termination from any 
> context it is in and resetting descriptors if it is not in a
context.

---

From: [email-masked]
Date: Thu, 20 Mar 2003 13:12:30 +0530

Hi Kevin
     Few clarifications needed on the service change procedures:

4) What should be the MGC behaviour in the following scenario:

I hope SG16 Annex F will also clarify doubts over the above items.

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

---

From: [email-masked]
Date: Thu, 20 Mar 2003 13:12:30 +0530

Hi Kevin

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 24 Mar 2003 10:59:15 -0500

Well, that's why I said the "current plan".  As Christian has pointed out,
final decisions have yet to be made on where and how to incorporate the
Annex into the Recommendation.

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2003 7:04 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]; Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked];
[email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

G'Day,

I don't think it has been decided to incorporate it back into both v1 and
v2.
>From discussion at SanJose I thought we would take the decision on what 
>to do
with the work ie. annex, appendix or merging when it came nearer to the time
to approve the work.

Regards, Christian

Kevin Boyle wrote:
> 
> The current plan is to incorporate it back into both V1 and V2 (since 
> the new Annex doesn't change the existing spec, it only makes 
> clarifications). The current timeline is May, however, I wouldn't be 
> surprised if the Annex will be held until February 2004.
> 
> Kevin
> 
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]; 
> [email-masked]; Megaco List
> I did like to know if the Annex-F is intended to be part of H.248v2 
> only or will also be applicable to H.248v1. Any information about the 
> time lines by when it would be finalised/ freezed.
> 
> regards,
> -kapil nayar
> http://www.hssworld.com
> 
> This work is ongoing in SG16 as future Annex F.  Both of these items 
> are intended to be clarified by the new work.
> 
> The input documents to the San Jose Rapporteurs' Meeting can be found 
> as AVD-2310, AVD-2311, and AVD-2298 at 
> This is where the RFC is completely inadequate as it stands.  I 
> wouldn't mind seeing it rewritten to specify separately what happens 
> for ServiceChange on ROOT vs. ServiceChange on individual 
> terminations.  With regard to the latter, there is also something else 
> I'd like to see ironed
> I am quite prepared to submit a proposal for new text for section 
> 7.2.8 in particular.  Would there be interest in reviewing such a 
> proposal?  We could submit it as a contribution into SG 16's May 
> meeting if that is workable.
> 
> [email-masked] wrote:
> >
> > software development tells me that a restart clears certain aspects 
> > of state.  However, that makes little sense in the Megaco case, 
> > because the MGC can do that directly by subtracting the termination 
> > from any context it is in and resetting descriptors if it is not in 
> > a
> context.
> >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
> >
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 24 Mar 2003 10:59:15 -0500

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2003 7:04 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]; Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked];

G'Day,

Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 24 Mar 2003 11:24:47 -0500

Comments inline. [KJBII]

Before we get too bogged down into a lot of scenario by scenario details,
keep in mind that the intent of this work is to define as simple a model as
possible.  There is no need to define an enormous state machine that has a
state for every possible scenario.  There are, in reality two states, and a
possible third pseudo-state: In service, Out of service, and the fleeting
delayed OOS brought about by things like a SC Graceful.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 20, 2003 2:43 AM
To: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

[KJBII] MGs may not remove terms from context without a Subtract command
from the MGC.  The MG should Restart the term, in accordance with its
function and provisioning, and await cleanup commands from the MGC.  If that
restart means that the media stream is lost, then that is something that the
MGC should take into account before requesting that the MG restart a
particular termination.

2) If ServiceChange Restart with delay is recd by MG  for an already
Inservice termination which may or may not be in call then what should be
     MG behaviour. Should it mark the termination as Out-Of-Service till the
delay timer expires and remove the termination from the context
    or give a error response ?

[KJBII] If the term is inservice, and the command is to restart, why would
you remove it from service?  The delay is just that -- a delay.  Don't do
anything with the term until the delay expires, and then Restart it upon the
expiry of the delay.

3) If Service Change Graceful with delay is    received by MG for an already
out
of service termination then how should MG behave?
    Should it mark the termination in-service right now and after timer
expiry mark it out-of-service or should it give an error?

[KJBII] So, an out of service termination receives a command to take it out
of service.  I say acknowledge the command, and leave the termination as it
is -- delay or not.  Since it is already out of service, this is,
effectively, a no-op.  Now, the implications to think about are: What if the
MG took the term OOS, and then, later, the MGC sends a Forced or Graceful?
This has the implication that the MG, by itself, cannot bring the
termination back into service.  It implies, to me, that BOTH the MG and MGC
must take action on that term in order to have it return to service.

In all of the above cases if MG were to give a error response then there is
no error-code defined which specifies that MG is already in the state which
MGC has requested , however there is an error-code "Not-Ready" defined as
"The command directed to a  termination was not executed because of the
service state of the termination" which can be used in these situations for
conveying MGC that requested operation is not done.

     2) Now MG want to cancel the graceful timer. The only way do currently
is by sending a

[KJBII] I believe that any SC command received while there is one still
awaiting its SCDelay expiry effectively overrides the existing command.  For
example, if a SC Graceful with a long delay is in progress, and a SC Forced
with comes during the delay timing, then the Graceful is cancelled, and the
Forced is executed as signaled.

Regards
Venkat

To:   "Kevin Boyle" <[email-masked]>
cc:   "Tom-PT Taylor" <[email-masked]>, Kushanava Laha/HSS@HSS,
      Sachin Gupta-PNGN/HSS@HSS, Megaco List <[email-masked]> (bcc: B
Venkat
      S.R Swamy/HSS)

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

context.

DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) 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. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 24 Mar 2003 11:24:47 -0500

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 20, 2003 2:43 AM
To: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

context.

---

From: [email-masked]
Date: Tue, 25 Mar 2003 15:17:57 +0530

Hi Kevin
     Thanks for you clarifications.
But the points that I have mentioned were basically not normal scenario but
are scenario developing because of the inconsistancy between MG-MGC termination
state machine. This can be due to any reason like switchovers or some
malfunctioning at either end.
So there should be some mechanism to correct this inconsistancy by providing
error responses
to such SC requests.
I have still have some doubts on the point 2 and 4  below (comments inline
[bvswamy]).

Regards
Venkat

"Kevin Boyle" <[email-masked]> on 03/24/2003 09:54:47 PM

To:   B Venkat S.R Swamy/HSS@HSS, [email-masked]
cc:

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 20, 2003 2:43 AM
To: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

[bvswamy]  Does this mean MG should not generate any megaco message towards MGC
          for these set of terminations till the delay timer expires because by
          sending SC Restart with delay, MGC is implicitly telling that the
terminations
          are out-of-service at his end and is not expecting any messages for
that
          terminations.Please correct me if I am wrong.

[bvswamy] Does this mean that any call running on the terminations will get
           cleared when MGC receives such overriding messages(Forced or
Restart).

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

context.

---

From: [email-masked]
Date: Tue, 25 Mar 2003 15:17:57 +0530

Hi Kevin

Regards
Venkat

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 20, 2003 2:43 AM
To: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

context.

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 26 Mar 2003 13:28:50 -0500

More comments inline. [KJBII]

You did make a good point about having a SCReason to specify that a Restart
isn't really a Restart, but is rather a cancellation of a pending
ServiceChange command.  I think it is useful to have such a Reason code, and
I will see about submitting a proposal to the next SG16 meeting to add one.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 25, 2003 4:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin
     Thanks for you clarifications.
But the points that I have mentioned were basically not normal scenario but
are scenario developing because of the inconsistancy between MG-MGC
termination state machine. This can be due to any reason like switchovers or
some malfunctioning at either end. So there should be some mechanism to
correct this inconsistancy by providing error responses to such SC requests.
I have still have some doubts on the point 2 and 4  below (comments inline
[bvswamy]).

[KJBII] If the MG cannot execute a command, then, I agree, it should return
an error.

Regards
Venkat

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 20, 2003 2:43 AM
To: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

[bvswamy]  Does this mean MG should not generate any megaco message towards
MGC
          for these set of terminations till the delay timer expires because
by
          sending SC Restart with delay, MGC is implicitly telling that the
terminations
          are out-of-service at his end and is not expecting any messages
for that
          terminations.Please correct me if I am wrong.

[KJBII] I do not see why any other messaging would have to be held.  The
Restart will execute at the end of the delay -- that doesn't mean that no
other messaging can be sent during the delay.  What if the term is in
context, the MGC sends a SC Restart with delay, and then subsequently sends
a subtract?  I think it entirely reasonable that the Subtract be executed,
even though there is a pending Restart.

Also, Restart does NOT mean the terms go out of service and then back in
service.  It means that the terms were reset to an initial state.  Think of
it like the difference between restarting windows and turning off the
computer.  In the turning off case, the computer has halted function.  In
the other, the computer is still functioning, but is reloading itself.  Now,
does a restart mean that functionality will cease to work for a short time?
Probably -- but that is a matter of implementation.  I can conceive of a
Restart that would be fast enough that there may not be a perceptible
interruption of functionality on a particular term.

Keep in mind, however, that a Restart on Root will affect ALL terms on the
MG, and WILL result in service disruption.  This is one of the differences
between Root and other terms.

[KJBII] As always, it is up to the MGC to take appropriate action.
Certainly, if the MGC receives a Forced to override a Graceful, then the MGC
should tear down the context at that time, rather than waiting for the delay
to expire.  In the case of a Restart, the Graceful is certainly cancelled,
and the MGC can leave the context as it is, if it so chooses.

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

context.

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 26 Mar 2003 13:28:50 -0500

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 25, 2003 4:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

Regards
Venkat

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 20, 2003 2:43 AM
To: [email-masked]
Subject: RE: [Megaco] Service change Restart

Hi Kevin

Regards
Venkat

Hi Kevin

regards,
-kapil nayar
http://www.hssworld.com

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Friday, March 14, 2003 9:30 AM
To: [email-masked]
Cc: [email-masked]; Megaco List
Subject: Re: [Megaco] Service change Restart

context.