Subject: ServiceChangeMethod Failover

From: Terry L Anderson <[email-masked]>
Date: Mon, 6 Nov 2000 11:08:01 -0500

The use of ServiceChangeMethod = Failover and the procedures behind it
are not totally clear in 7.2.8.  The paragraph describing the use of
ServiceChangeAddress indicate that new transaction requests go to the
new address but replies and pending indications continue to go to the
"address from which the corresponding request originated."

The next paragraph discussing ServiceChangeMgcId (which I believe is
used with Handoff) does NOT make clear whether a similar distinction is
made between new transactions and replies and pending indictions or
whether all messages go to the new MGC.  The text merely says "the new
MGC that will take over from the current MGC." It is not clear what
"take over" means.  The issue is the procedures behind a handoff: is it
gradual (ServiceChange with Handoff is sent but the MGC must wait around
for replies and pending indications before it can go out of service) or
abrupt (ServiceChange can be sent and then immediately MGC can go out of
service and the new MGC handle all subsequent activity).

I think that text should be more specific about the procedures relating
to Handoff.

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

---

From: "Tulpule, Naren" <[email-masked]>
Date: Mon, 6 Nov 2000 11:23:17 -0800

Hi Brian,
  that's what I thought, yet section 11.5 (Failure of an MGC) states:

 No recommendation is made on how the MGCs involved in the Handoff
   maintain state information; this is considered to be out of scope of
   this recommendation. The MGC and MG may take the following steps when
   Handoff occurs.  When the MGC initiates a HandOff, the handover
   should be transparent to Operations on the Media Gateway.
   Transactions can be executed in any order, and could be in progress
   when the ServiceChange is executed.  Accordingly, commands in
   progress continue, transaction replies are sent to the new MGC (after
   a new control association is established), and the MG should expect
   outstanding transaction replies from the new MGC.  No new messages
   shall be sent to the new MGC until the control association is
   established.  Repeated transaction requests shall be directed to the
   new MGC.  The MG shall maintain state on all terminations and
   contexts.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, November 06, 2000 11:05 AM
To: [email-masked]
Subject: Re: ServiceChangeMethod Failover

Replies and Pendings ALWAYS go back from whence they came, no exceptions.

We do need to make this clear in the text.

Brian

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Monday, November 06, 2000 11:08 AM
> To: [email-masked]
> Subject: ServiceChangeMethod Failover
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Nov 2000 14:39:34 -0500

I don't think so.  I always considered a Notify to be a new command,
which would go to the "current" control association.  That would mean
the "old" MGC would have to deal with currently outstanding transactions,
but not outstanding EventsDescriptors.  The "new" MGC would get
Notifies for events occurring after the ServiceChange.

Brian

> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Monday, November 06, 2000 2:31 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Thanks for the clarification.  Just to be clear then, to take
> an MGC out of
> service using Handoff, one must send the ServiceChange with
> Handoff, then
> send modifies with EventsDescriptor to cancel any event lists
> and wait for
> all replies before shutting down.   Then the new MGC must
> send modifies with
> EventsDescriptor to reinitiate any event lists still desired.  Is this
> correct.
>
> "Rosen, Brian" wrote:
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Nov 2000 14:49:05 -0500

Rats!  I thought we had been through that text and decided to make
it consistent with the "replies go back to the originator" rule.
My recollection is that we decided that replies ALWAYS go back to
who sent them, ALWAYS, no exceptions.

The failure model that I know how to deal with is that transactions
not started always work.  Transactions completed stay good, but
transactions "in the middle" may or may not be completed, and it's
too hard to try to keep these in the middle things working across a
handover.  We often have the same kind of thing in the MGC - calls
up stay up, calls started immediately after handover work, calls actually
in process, but not established, are often dropped.

Brian

> From: Tulpule, Naren [mailto:[email-masked]]
> Sent: Monday, November 06, 2000 2:23 PM
> To: Rosen, Brian; [email-masked]
> Subject: RE: ServiceChangeMethod Failover
>
>
> Hi Brian,

---

From: "Taylor, Tom-PT" <[email-masked]>
Date: Mon, 6 Nov 2000 15:16:48 -0600

I agree with this view.

> Sent: Monday, November 06, 2000 2:40 PM

---

From: "Whitton, Alan" <[email-masked]>
Date: Tue, 7 Nov 2000 08:55:26 -0600

OK,

What happens if you have a call originated from your FIRST (MGC1)
controller, MGC1 then gracefully hands over to MGC2 (let's say for a
software upgrade). The first call is still "UP" (especially for NAS calls
this is VERY likely). MGC1 now goes OFF LINE for it's software update (say 6
hours was waited for). Now our user finally hangs up his modem, and the
teardown process begins. Your statements seems to suggest that the EVENT
will go to MGC1, even though MGC2 is now completely in control?

More likely than not in this model the MG hangs up the call, and the "new"
MGC (MGC2) will get REL messages from the SS7 network also, and tear down
will occur on both sides, however, there is the question about accounting
records (both Radius and AMMA).

Food for thought,

Cheers,
Alan

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, November 06, 2000 2:49 PM
To: [email-masked]
Subject: Re: ServiceChangeMethod Failover

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Nov 2000 13:30:12 -0500

I just dealt with this one on a related thread.  The Notify is a new
command, and goes to the new (MGC2) controller.

Brian

-----Original Message-----
From: Alan Whitton [mailto:[email-masked]]
Sent: Tuesday, November 07, 2000 9:55 AM
To: Rosen, Brian; [email-masked]
Subject: RE: ServiceChangeMethod Failover

OK,

Food for thought,

Cheers,
Alan

-----Original Message-----
From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, November 06, 2000 2:49 PM
To: [email-masked]
Subject: Re: ServiceChangeMethod Failover

Brian

> From: Tulpule, Naren [ mailto:[email-masked]
<mailto:[email-masked]> ]
> From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > From: Terry L Anderson [ mailto:[email-masked] <mailto:[email-masked]> ]

> > I think that text should be more specific about the
<mailto:[email-masked]>
> > http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent
internal) http://www.gti.net/tla <http://www.gti.net/tla>