RE: TID Label Issues - Issue #1

Brian,

Or, we can specify in the IG that if a message is received for an
unrecognized TID, the SG can either discard or send an ABORT in
response.

Regards,
Lincoln 

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

Lincoln,

It is an issue that requres a modification to the RFC.

--brian

Haresign Lincoln wrote:                                           (Wed,
11 Oct 2006 16:11:37)
> Brian,
> 
> I don't see a major issue here that prevents the use of TID routing.
> 
> Lincoln
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Wednesday, October 11, 2006 4:07 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> Subject: Re: TID Label Issues - Issue #1
> 
> Lincoln,
> 
> The issue is that it is already specified in the RFC as (X)UDTS 
> "routing failure".
> 
> --brian
> 
> Haresign Lincoln wrote:
(Wed,
> 11 Oct 2006 15:54:06)
> > 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/
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/

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