RE: RFC 4666 M3UA - Reg Request Message

"Haresign Lincoln" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <849535E338E99741B7F7413F73253EDB051C0AB2@us-nj-mail1.comverse.com>
Brian,

You're right, that will work.  

I'm in agreement with you that adding CIC to the list of RK won't work
and we either need to further modify M3UA, or try to get your
LOADSEL/LOADGRP drafts in alignment with all the requirements that might
exist for all users (if they are not already).

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Tuesday, November 07, 2006 1:40 PM
To: Haresign Lincoln
Cc: [email protected]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Haresign Lincoln wrote:                                           (Tue,
07 Nov 2006 11:42:43)
> Brian,
> 
> I'm just trying to clarify one issue based upon this chain and also 
> some previous ones.  Do you believe that this is a valid scenario:
> 
> SG: DPC=1
> 
> AS1 - RK: DPC=1, OPC=2
> AS2 - RK: DPC=1, OPC=3
>
> The AS share the same point code with the SG.  AS1 receives all 
> messages from PC=2.  AS2 receives all messages from PC=3.

Yes, this is the scenario of which I was speaking.

> If this is valid, I guess this shares the same problem whether or not 
> you are using CIC loadsharing.  If AS1 completely goes away (all ASP 
> wihtin AS1 become INACTIVE), there is little the SG can do but drop 
> the messages.

It can send UPU Inaccessible to PC=2.  At PC=2, ISUP, on receipt of UPU
for PC=1 will start User Part Test procedures, sending periodic UPT
messages to PC=1 until a UPA is returned instead of a UPU.  During the
User Part Test it will send no further ISUP messages to PC=1 and will
perform proper treatment of circuits for the isolated signalling
relation.

> 
> The ETSI spec seems to imply the perhaps this is not valid since is 
> has a finer granularity that PC.

The routing key is not of finer granularity than a PC.  SI is the first
element of finer granularity than a PC.

--brian

--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.