권도형 | 2 Mar 06:18 2007

DAVA came before ASP_ACTIVE_ACK is coreect?

Dear Sir,

We use SUA Layer. (SG vendor is CISCO).

When our system is up and sends ASP_ACTIVE to SG, SG response with ASP_ACTIVE_ACK.

But SG sends us DAVA messages before ASP_ACTIVE_ACK message.

 

We discard SNM messages that send before ASP_ACTIVE_ACK.

Should we accept these DAVA messages?

 

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Brian F. G. Bidulock | 2 Mar 06:57 2007

Re: DAVA came before ASP_ACTIVE_ACK is coreect?

±ÇµµÇü,

±ÇµµÇü wrote:                                 (Fri, 02 Mar 2007 14:18:18)
> 
>    Dear Sir,
> 
>    We use SUA Layer. (SG vendor is CISCO).

Please do no use vendor names on this list, particularly as it is
unimportant to the discussion.

> 
>    When  our  system  is  up and sends ASP_ACTIVE to SG, SG response with
>    ASP_ACTIVE_ACK.
> 
>    But SG sends us DAVA messages before ASP_ACTIVE_ACK message.
> 
> 
>    We discard SNM messages that send before ASP_ACTIVE_ACK.
> 
>    Should we accept these DAVA messages?

They can be processed, discarded or ignored.  If you assume that all
destinations are accessible anyway, there is no difference.  The sending of
SNMM messages between ASP Active and ASP Active Ack is intended (and only
necessary) to indicate restricted, congested, or inaccessible destinations.

The pertinent passage is RFC 4666/4.5.1:

   For the particular case that an ASP becomes active for an AS and
   destinations normally accessible to the AS are inaccessible,
   restricted, or congested, the SG MAY send DUNA, DRST, or SCON
   messages for the inaccessible, restricted, or congested destinations
   to the ASP newly active for the AS to prevent the ASP from sending
   traffic for destinations that it might not otherwise know that are
   inaccessible, restricted, or congested.  For the newly activating ASP
   from which the SGP has received an ASP Active message, these DUNA,
   DRST, and SCON messages MAY be sent before sending the ASP Active Ack
   that completes the activation procedure.

Nevertheless, it makes sense that it might be necessary to send or process a
DAVA during that period as well (e.g. if a destination becomes available after
the ASP Active is received but before the ASP Active is sent, and possible
after a DUNA has already been sent).

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
권도형 | 5 Mar 13:06 2007

GT Routing with NULL(H'0000) PC

Dear, Sir
When the following message came to SG, SG can route this message?

Sending CLDT Message from ASP to SG (SUA Layer)
Destination Address is composed of these parameters.
---
Destination Address
	+Route Indicator : Route on Global Title (1)
	+Address Indicator
		- Include GT : True
		- Include PC : False
		- Include SSN : True
	+Global Title
		- ???????????? (Some Value) (skip detail)
	+Subsystem number
		- ? (Some Value) (skip detail)
	+Point code
		- Parameter Tag: Point Code (0x8002)
		- Parameter Length: 8
		- Point code: 0 (0x00 00 00 00) <- the focus is this

The GT and SSN value is correct.
---

I know that the PC value cannot be 0.
But with our test results, in some cases, SG can route these messages (with 0 PC included) to the right Destination.
Is these
Is that message perfectly wrong?

Ps: Thank you very much Brian F. G. Bidulock.
Brian F. G. Bidulock | 5 Mar 13:14 2007

Re: GT Routing with NULL(H'0000) PC

±ÇµµÇü,

±ÇµµÇü wrote:                                                                       (Mon, 05 Mar 2007 21:06:28)
> Dear, Sir
> When the following message came to SG, SG can route this message?
> 
> Sending CLDT Message from ASP to SG (SUA Layer)
> Destination Address is composed of these parameters.
> ---
> Destination Address
> 	+Route Indicator : Route on Global Title (1)
> 	+Address Indicator
> 		- Include GT : True
> 		- Include PC : False

It does not really matter what the PC is, with (Include PC : False) it will
not be included in the resulting SCCP message.  The SG is welcome to route the
message on global title.

It would be better form to not include the PC parameter in the message, but
the SG can be forgiving if it wants.

--brian

> 		- Include SSN : True
> 	+Global Title
> 		- ???????????? (Some Value) (skip detail)
> 	+Subsystem number
> 		- ? (Some Value) (skip detail)
> 	+Point code
> 		- Parameter Tag: Point Code (0x8002)
> 		- Parameter Length: 8
> 		- Point code: 0 (0x00 00 00 00) <- the focus is this
> 
> The GT and SSN value is correct.
> ---
> 
> I know that the PC value cannot be 0.
> But with our test results, in some cases, SG can route these messages (with 0 PC included) to the right Destination.
> Is these
> Is that message perfectly wrong?
> 
> Ps: Thank you very much Brian F. G. Bidulock.
> 
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
권도형 | 5 Mar 13:40 2007

RE: GT Routing with NULL(H'0000) PC

Thanks again.
I confused with "RFC 3868 / 3.10.2.2.  Address Indicator".
" For example, the PC
   parameter is present in the destination address of the CLDT sent from
   ASP->SG, but bit 2 is set to "0" meaning "do not populate this in the
   SCCP called party address".  The effect is that the SG only uses the
   PC to populate the MTP routing label DPC field, but does not include
   it in the SCCP called party address."

According to this example, wrong PC value can cause wrong MTP routing.
But I thought that SG may discard this PC value when SG cannot find right route. Am I right?

Addition to last question, the SG engineer told me that some error messages logged on SG when that message (0
PC valued) came (but I have not received the exact error message)


-----Original Message-----
From: Brian F. G. Bidulock [mailto:bidulock <at> openss7.org] 
Sent: Monday, March 05, 2007 9:14 PM
To: 권도형
Cc: sigtran <at> ietf.org
Subject: Re: [Sigtran] GT Routing with NULL(H'0000) PC

±ÇµµÇü,

±ÇµµÇü wrote:                                                                       (Mon, 05 Mar 2007 21:06:28)
> Dear, Sir
> When the following message came to SG, SG can route this message?
> 
> Sending CLDT Message from ASP to SG (SUA Layer)
> Destination Address is composed of these parameters.
> ---
> Destination Address
> 	+Route Indicator : Route on Global Title (1)
> 	+Address Indicator
> 		- Include GT : True
> 		- Include PC : False

It does not really matter what the PC is, with (Include PC : False) it will
not be included in the resulting SCCP message.  The SG is welcome to route the
message on global title.

It would be better form to not include the PC parameter in the message, but
the SG can be forgiving if it wants.

--brian

> 		- Include SSN : True
> 	+Global Title
> 		- ???????????? (Some Value) (skip detail)
> 	+Subsystem number
> 		- ? (Some Value) (skip detail)
> 	+Point code
> 		- Parameter Tag: Point Code (0x8002)
> 		- Parameter Length: 8
> 		- Point code: 0 (0x00 00 00 00) <- the focus is this
> 
> The GT and SSN value is correct.
> ---
> 
> I know that the PC value cannot be 0.
> But with our test results, in some cases, SG can route these messages (with 0 PC included) to the right Destination.
> Is these
> Is that message perfectly wrong?
> 
> Ps: Thank you very much Brian F. G. Bidulock.
> 
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran


-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/


_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Brian F. G. Bidulock | 5 Mar 16:10 2007

Re: GT Routing with NULL(H'0000) PC

???,

??? wrote:                                                                             (Mon, 05 Mar 2007 21:40:49)
> Thanks again.
> I confused with "RFC 3868 / 3.10.2.2.  Address Indicator".
> " For example, the PC
>    parameter is present in the destination address of the CLDT sent from
>    ASP->SG, but bit 2 is set to "0" meaning "do not populate this in the
>    SCCP called party address".  The effect is that the SG only uses the
>    PC to populate the MTP routing label DPC field, but does not include
>    it in the SCCP called party address."
> 
> According to this example, wrong PC value can cause wrong MTP routing.

That assumes that the SG itself does not perform GT.

> But I thought that SG may discard this PC value when SG cannot find right route. Am I right?

As I said, the SG is welcome to perform routing based on GT and come up with a
new PC.

--brian

> 
> Addition to last question, the SG engineer told me that some error messages logged on SG when that message
(0 PC valued) came (but I have not received the exact error message)
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock <at> openss7.org] 
> Sent: Monday, March 05, 2007 9:14 PM
> To: 권도형
> Cc: sigtran <at> ietf.org
> Subject: Re: [Sigtran] GT Routing with NULL(H'0000) PC
> 
> ±ÇµµÇü,
> 
> ±ÇµµÇü wrote:                                                                       (Mon, 05 Mar 2007 21:06:28)
> > Dear, Sir
> > When the following message came to SG, SG can route this message?
> > 
> > Sending CLDT Message from ASP to SG (SUA Layer)
> > Destination Address is composed of these parameters.
> > ---
> > Destination Address
> > 	+Route Indicator : Route on Global Title (1)
> > 	+Address Indicator
> > 		- Include GT : True
> > 		- Include PC : False
> 
> It does not really matter what the PC is, with (Include PC : False) it will
> not be included in the resulting SCCP message.  The SG is welcome to route the
> message on global title.
> 
> It would be better form to not include the PC parameter in the message, but
> the SG can be forgiving if it wants.
> 
> --brian
> 
> > 		- Include SSN : True
> > 	+Global Title
> > 		- ???????????? (Some Value) (skip detail)
> > 	+Subsystem number
> > 		- ? (Some Value) (skip detail)
> > 	+Point code
> > 		- Parameter Tag: Point Code (0x8002)
> > 		- Parameter Length: 8
> > 		- Point code: 0 (0x00 00 00 00) <- the focus is this
> > 
> > The GT and SSN value is correct.
> > ---
> > 
> > I know that the PC value cannot be 0.
> > But with our test results, in some cases, SG can route these messages (with 0 PC included) to the right Destination.
> > Is these
> > Is that message perfectly wrong?
> > 
> > Ps: Thank you very much Brian F. G. Bidulock.
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> bidulock <at> openss7.org
> http://www.openss7.org/

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Michael Tuexen | 5 Mar 19:12 2007
Picon

Fwd: Invitation to the SIGTRAN Protocol Testing Plugtests Event - 16-20 April 2007 in Moscow - Russia - 2nd reminder

Dear all,

I'm forwarding this reminder...

Best regards
Michael

Begin forwarded message:

> From: Aurélie Sfez <Aurelie.Sfez <at> etsi.org>
> Date: March 5, 2007 12:06:40 PM GMT+01:00
> To: "Michael Tuexen_Internet" <tuexen <at> fh-muenster.de>
> Subject: FW: Invitation to the SIGTRAN  Protocol Testing Plugtests  
> Event - 16-20 April 2007 in Moscow - Russia - 2nd reminder
>
> Dear Mr Tuexen,
>
> Would you be so kind to forward the 2nd reminder to the sigtran  
> mailing list ?
>
> I thank you in advance.
>
> Best Regards,
>
> Aurelie Sfez
> Plugtests Event Coordinator
> Tel: +33 4 92 94 42 95
> Fax: +33 4 92 38 49 14
> http://www.etsi.org/plugtests/calendar.htm
>
> From: Plugtests
> Sent: 05 March 2007 12:03
> Subject: Invitation to the SIGTRAN Protocol Testing Plugtests Event  
> - 16-20 April 2007 in Moscow - Russia - 2nd reminder
> Importance: High
>
> 2nd Reminder !
> Registration is open until 31st of March 2007.
>
> Please take into account that you will need a few weeks to obtain  
> your VISA in order to get to Moscow. Please find all the  
> information about how to get a VISA under Travel and VISA information.
>
>
> From: Plugtests
> Sent: 23 January 2007 17:46
> Subject: Invitation to the SIGTRAN Protocol Testing Plugtests Event  
> - 16-20 April 2007 in Moscow - Russia
>
> Dear Madam,
> Dear Sir,
>
> The ETSI’s PlugtestsTM Service is pleased to invite you to the next  
> SIGTRAN Interoperability Test Event, which will take place from  
> 16th to 20th April 2007 at ZNIIS (Russian Central Science Research  
> Institute) in Moscow.
>
> ZNIIS possesses interesting facilities which will provide the  
> community additional value such as SS7 connectivity to address  
> further SS7-SIGTRAN interoperability after the first experience  
> gained at the last event. We will also gain valuable knowledge from  
> their NGN testing experience.
>
> The SIGTRAN (Protocol Testing) family of protocols (IUA, DUA, V5UA,  
> M2PA, M2UA, M3UA, SUA) addresses the transport of packet-based PSTN  
> signaling over IP Networks, taking into account functional and  
> performance requirements of the PSTN signaling.
> This event is an opportunity for engineers from competing  
> organizations to meet together in a commercially secure  
> environment, to share experiences and improve interoperability  
> between their implementations.
> Should you be interested, you will be able to retrieve all  
> information related to this event at the following address: http:// 
> www.etsi.org/plugtests/SIGTRAN.htm
>
> Registration is open until 31st of March 2007.
>
> Please take into account that you will need a few weeks to obtain  
> your VISA in order to get to Moscow. Please find all the  
> information about how to get a VISA under Travel & VISA information.
>
> We would be pleased to welcome you to SIGTRAN Protocol Testing  
> Plugtests Event.
>
>
> Yours faithfully,
>
>
> Philippe Cousin
> Interoperability Service Manager
>
>
Ambika Tripathy | 7 Mar 12:52 2007
Picon

DPC in REG REQ

 
Hi Brain,
 
       I have one doubt regarding the DPC parameter in the REG REQ message.
As per RFC-3332
 
Destination Point Code:

      The Destination Point Code parameter is mandatory, and identifies
      the Destination Point Code of incoming SS7 traffic for which the
      ASP is registering.  The format is the same as described for the
      Affected Destination parameter in the DUNA message (See Section
      3.4.1).  Its format is:

Should i think the DPC mean the OPC of the ASP end if the scenario is like below.
 
ASP                               SG
-----------------------------------------
---------------REG REQ------------>
OPC = 2.2.2           OPC = 1.1.1
DPC = 1.1.1            DPC = 2.2.2
 
Then what will be the DPC value of the REG REQ message from ASP?
--
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Brian F. G. Bidulock | 7 Mar 13:42 2007

Re: DPC in REG REQ

Ambika,

In this case, DPC is used as viewed from the SG.  That is, the DPC is the
point code in the DPC portion of the MTP Routing Label in messages that the
SG will send to the ASP.  Therefore, the DPC is the point code belonging to
the ASP.

(Most things in these RFCs, such as ASP state, is as viewed from the SG).

--brian

Ambika Tripathy wrote:                          (Wed, 07 Mar 2007 17:22:45)
> 
> 
> 
>    Hi Brain,
> 
> 
> 
>            I  have  one  doubt regarding the DPC parameter in the REG REQ
>    message.
> 
>    As per RFC-3332
> 
> 
> 
>    Destination Point Code:
>            The   Destination  Point  Code  parameter  is  mandatory,  and
>    identifies
>          the Destination Point Code of incoming SS7 traffic for which the
>          ASP is registering.  The format is the same as described for the
>          Affected Destination parameter in the DUNA message (See Section
>          3.4.1).  Its format is:
> 
>    Should  i think the DPC mean the OPC of the ASP end if the scenario is
>    like below.
> 
> 
> 
>    ASP                               SG
> 
>    -----------------------------------------
> 
>    ---------------REG REQ------------>
> 
>    OPC = 2.2.2           OPC = 1.1.1
> 
>    DPC = 1.1.1            DPC = 2.2.2
> 
> 
> 
>    Then what will be the DPC value of the REG REQ message from ASP?
>    --
>    Br,
>    Ambika Prasad Tripathy
>    Nethawk Networks
>    Cell: +91-94375 47730

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Dheeraj.Dubey | 7 Mar 13:53 2007

Re: DPC in REG REQ



Hi Ambika,

As per my knowledge, REG REQ is used to share Routing Information (in RK parameter) to Remote User. It is just like as the Capabilites Exchages b/w Local and Remote user (useful to take Routing decisions). So, when you send REG REQ to Remote user, you should set  your own PC (Local PC or OPC(in your terms)) in DPC parameter of Routing Key.


In your Call flow, PC of ASP will be DPC for REG REQ (ASP->SG).

--- Dheeraj



"Ambika Tripathy" <ambika.tripathy <at> gmail.com>

03/07/2007 05:22 PM

To
sigtran <sigtran <at> ietf.org>, bidulock <bidulock <at> openss7.org>
cc
Subject
[Sigtran] DPC in REG REQ





 
Hi Brain,
 
       I have one doubt regarding the DPC parameter in the REG REQ message.
As per RFC-3332
 
Destination Point Code:

     The Destination Point Code parameter is mandatory, and identifies
     the Destination Point Code of incoming SS7 traffic for which the
     ASP is registering.  The format is the same as described for the
     Affected Destination parameter in the DUNA message (See Section
     3.4.1).  Its format is:

Should i think the DPC mean the OPC of the ASP end if the scenario is like below.
 
ASP                               SG
-----------------------------------------
---------------REG REQ------------>
OPC = 2.2.2           OPC = 1.1.1
DPC = 1.1.1            DPC = 2.2.2
 
Then what will be the DPC value of the REG REQ message from ASP?
--
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730 _______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Gmane