RE: TID Label Issues - Issue #2

Brian,

I don't believe that the SUA spec handles this at all.  We have designed
a proprietary mechansim that works with Correlation Ids within the
message.  

I think the TID routing mechansim (like other options in the spec) are
designed for certain mechanisms.  More advanced features (like linked
transactions via a correlation ID or Billing ID) require either a
proprietary mechanism or a new RFC.

However for applications that don't have linked transactions, the TID
routing works quite well.

Regards,
Lincoln 

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

Lincoln,

Linked transactions.  An ASP generates a query to a remote SEP.  The
remote SEP generates a linked transaction back to the ASP.  The linked
transaction has the ASPs TID as a correlation ID, but because it begins
a query, it has no destination TID.

RFC 3868 says:

4.7.3.1.  TCAP traffic

   Messages not containing a destination (or "responding") TID, i.e.,
   Query, Begin, Unidirectional, are loadshared among the available
   ASPs.  Any scheme permitting a fair load distribution among the ASPs
   is allowed (e.g., round robin).

But that is not going to work as the linked transaction will likely go
to the wrong ASP.

--brian

--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/