Re: FW: RFC 4666 M3UA

Kevin,

I believe that you are talking about the multiple SG as STP scenario.
For this scenario to work correctly, from the SS7 perspective, each STP
must view the ASP Point Code to be an alias point code that is local to
the STP in the same sense as an ANSI T1.111.4/2000 SCCP "Alias" point
code described in ANSI T1.111.4/2000 3.9 and 3.A.  That is, the remote
ASP is connecting via M3UA to a local MTP-SAP on the STP which is shared
between STP pairs in the ANSI T1.111.4 "Alias" sense.

When set up in this manner, each STP must respond to TFC in the
appropriate manner as dictated by, for example, ANSI T1.111.4 Section
13.7, and in your case:

 13.7.5 If T15 expires after the last updated of the congestion
 status of the signalilng route set towards destination X by a
 transfer-controlled message relating to the same destination, the
 signalling-route-set-congestion-rest procedure is invoked (see
 13.9).

and

 13.9 The signalling-route-set-congestion-test procedure is used at
 an originating signalling point to update the congestion status
 associated with a route set towards a certain destination.  The
 purpose is to test whether or not signalling messages destined
 towards that destination with a given message priority or higher
 may be sent.

 ...

Because the "Alias" point code is considered local to the STP, the STP
must respond in the same manner as a signalling end point under sections
13.7 and 13.9.

The DAUD procedure is not intended to trigger SS7 procedures at the SG,
but is intended as an optional procedure invoked by the ASP to permit
the ASP to syncrhonize its state with regard to availability and
congestion of remote signalling points to support restart.

The SCON is the equivalent of the MTP-STATUS.

So, sending RCT is the obligation of the STP which "owns" the ASP's
signalling point code in the SS7 sense.  Route set status changes
resulting from the procedure are indicated to the ASP using SCON.

Because your implementation appears to be sending RCT under the correct
circumstances, but is mere placing the wrong point code in the test
message, it is likely just a bug.

--brian

Lyndon Ong wrote:                                (Wed, 12 Sep 2007 15:15:00)
> 
>    Ken,Javier,Lyndon,
>    I got your names from an inquiry to the IETF about the RFC 4666.
>    Recently  I  have  been involved in some testing of SS7 congestion and
>    it's  reaction  from  and  IP  network  using  M3UA.  The SS7 physical
>    connection  utilized  two  ITP's  with  BLinks  to the SS7 network. It
>    appears  the  ITP's  tested were not capable of transmitting the RCT (
>    Route  Congestion  Test)  message  in  response  to the TFC ( Transfer
>    Congestion)  they  received  with a proper Originating Point Code. The
>    ITP  responded  to  the  TFC  with  a  RCT  that  contained  it's  own
>    originating  point code. The RCT should contain the OPC of the node at
>    the  end  of  the  trunks.  This would be the IP endpoint not the ITP.
>    Further  it appears there is no provision within M3UA to facilitate IP
>    endpoints  to  send  a message to the ITP that would generate a proper
>    RCT.
>    If possible could you respond to my concerns.
>     1. Do  I  understand  the  M3UA  protocol  in  the belief there is no
>        workable  RCT provision, or is there a provision that would enable
>        the  ITP  to  reply  to  a  received  TFC  with a RCT that has the
>        originating point code of the IP endpoint?
>     2. I  notice  the  DAUD message contains an Information Parameter. Is
>        there  an  intent  or possibility the DAUD message could trigger a
>        RCT  on  the  SS7  side  of the ITP with the correct OPC of the IP
>        endpoint?
> 


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