RE: TID Label Issues - Issue #1

Brian,

Good question.

In this case, I don't believe that "return on error" applies.
Everything at the SCCP level is valid at this point and we are now doing
TCAP processing.  There are really two options (and we have implemented
them both).

1) The SG can drop the message.  

2) The SG can send and ABORT.

I would leave this issue as implementation specific.  However if you are
interested in specifying this in the IG, I'd be happy to work on the
wording.

Regards,
Lincoln


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

Lincoln,

Another issue:

RFC 3868 says:

4.7.3.1.  TCAP traffic

   ....

   If an ASP is not available, the SG may generate (X)UDTS "routing
   failure", if the return option is used.

But when I look at Q.713 (07/96) Section 3.13 Return Cause, my choices
are:

   0 0 0 0 0 0 0 0   no translation for an address of such nature
   0 0 0 0 0 0 0 1   no translation for this specific address
   0 0 0 0 0 0 1 0   sybsystem congestion
   0 0 0 0 0 0 1 1   subsystem failure
   0 0 0 0 0 1 0 0   unequipped user
   0 0 0 0 0 1 0 1   MTP failure
   0 0 0 0 0 1 1 0   network congestion
   0 0 0 0 0 1 1 1   unqualified
   0 0 0 0 1 0 0 0   error in message transport (Note)
   0 0 0 0 1 0 0 1   error in local processing (Note)
   0 0 0 0 1 0 1 0   destination cannot perform reassembly (Note)
   0 0 0 0 1 0 1 1   SCCP failure
   0 0 0 0 1 1 0 0   hop counter violation
   0 0 0 0 1 1 0 1   segmentation not supported
   0 0 0 0 1 1 1 0   segmentation failure
   0 0 0 0 1 1 1 1   |
         to          |  spare
   1 1 1 1 1 1 1 1   |

   Note - Only applicable to XUDT(S) message.

I don't see "routing failure" on the list.

Which one did you use?

--brian

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