Re: SUA, IPSP SE mode and ASP Active TID label

Jason,

Could you provide an example of where one would need to use TID label
in both directions (because I can't think of one).  Also, there is nothing
stopping an SE IPSP from, upon receiving ASP Active, sending ASP Active
itself and expecting ASP Active Ack before replying with ASP Active Ack:
in contrast to DE it is just that the activation corresponds to both
directions of traffic (duplex) and a single RC instead of each to one
direction of traffic (simplex) and a separate RC.

But back to why you think you need TID label in the first place.  Instead of
trying to split traffic on the basis of transaction identifier, why are you
not using the mechanism provided by SCCP: GTT and the SCCP entity set?  That
is the SS7 way of providing load sharing and redundancy of SCCP subsystems.
Why expose the internal architecture of a single SCCP subsystem?

--brian

Jason Parker wrote:                         (Wed, 12 Dec 2007 16:38:43)
> 
> Brian,
> I presume a discussion about the TID label has happened before!  If this
> topic has been covered in detail could you direct me to it in the
> archives.
>  
> I need to know if it can work in SE mode (since one end will receive an
> ASP Active Ack without the TID label) or if it is only possible in DE
> mode.
> Regards,
> Jason.
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]] 
> Sent: 10 December 2007 19:54
> To: Jason Parker
> Cc: [email protected]
> Subject: Re: [Sigtran] SUA, IPSP SE mode and ASP Active Ack Traffic mode
> param
> 
> Jason,
> 
> No, TID label is different.  (But, don't get me started on TID label.)
> 
> --brian
> 
> Jason Parker wrote:                              (Mon, 10 Dec 2007
> 17:59:59)
> > 
> >    Brian,
> > 
> >    I  can  see  that  will  be ok for Traffic mode, (and the RFC
> mentions
> >    "local  configuration  data  if  there is no request").  Does the
> same
> >    apply  for  the  TID in the ASP Active message, or is this meant to
> be
> >    dynamic?
> > 
> >    Many thanks,
> > 
> >    Jason.
> 
> 
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/

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