RE: DRN and TID Label Issues -- Issue #3

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

With the exception of linked dialogs (which I agree is not solved by TID
routing alone), nothing we are doing is proprietary with the exception
of sending ABORTs or discarding when unable to route.  This obviously
only applies to ongoing dialogs and is a temporary situation when an ASP
dies.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 11, 2006 5:08 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email protected]
Subject: Re: DRN and TID Label Issues -- Issue #3

Lincoln,

Haresign Lincoln wrote:
(Wed, 11 Oct 2006 17:02:48)
> Brian,
> 
> The default routing mechanism is not very well specified in the RFC.  
> It basically states that it is implemenation specific.  Should we also

> throw out that feature because it is not well described.

Default ASP is a purely local matter (local to the SG and the SS7
network).  As such it does not have to be specific to permit
interoperability.  When requirements are placed on sending messages to
another implementation such as in the case of DRN/TID label, where
vagueness causes lack of interoperability, the issue appears.

> 
> I think that all the problems with TID are solvable (as we have solved
> them) when working with a specific class of applications.

But in a proprietary way, it seems.

> 
> With regards to the DRN issue, since we have not implemented the DRN 
> mechanism, I have not studied it extensively to find out if there are 
> any holes.
> 
> Personally, the only issue I see is that the IG/RFC should specify 
> that the range for the DRN is three bytes.  Otherwise connection 
> oriented would not work.

It must also specify a stateless mapping between DRN and DLR.

--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.