Signaling Transport (sigtran)

headers 권도형 | 2 Mar 2007 06:18

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

±ÇµµÇü,

±ÇµµÇü 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/

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.

±ÇµµÇü,

±ÇµµÇü 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/

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

???,

??? 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/

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
>
>

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

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/

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

11	June 2013
3	May 2013
1	April 2013
5	March 2013
1	February 2013
3	January 2013
2	December 2012
8	October 2012
6	July 2012
9	April 2012
6	December 2011
2	November 2011
8	October 2011
21	September 2011
16	August 2011
19	July 2011
6	June 2011
2	May 2011
38	April 2011
25	March 2011
20	February 2011
29	January 2011
25	November 2010
28	October 2010
29	September 2010
2	August 2010
2	July 2010
11	June 2010
11	May 2010
16	April 2010
63	March 2010
7	February 2010
6	January 2010
27	December 2009
20	November 2009
27	October 2009
4	September 2009
3	August 2009
55	July 2009
18	June 2009
5	May 2009
9	April 2009
39	March 2009
31	February 2009
8	January 2009
24	December 2008
7	November 2008
21	October 2008
24	September 2008
5	August 2008
30	July 2008
18	June 2008
19	May 2008
16	April 2008
30	March 2008
33	February 2008
16	January 2008
38	December 2007
48	November 2007
26	October 2007
22	September 2007
37	August 2007
81	July 2007
76	June 2007
76	May 2007
85	April 2007
43	March 2007
51	February 2007
72	January 2007
70	December 2006
173	November 2006
168	October 2006
107	September 2006
43	August 2006
64	July 2006
120	June 2006
99	May 2006
6	April 2006
38	March 2006
266	February 2006
201	January 2006
205	December 2005
169	November 2005
303	October 2005
69	September 2005
13	August 2005
53	July 2005
42	June 2005
10	May 2005
48	April 2005
54	March 2005
38	February 2005
18	January 2005
46	December 2004
12	November 2004
38	October 2004
65	September 2004
95	August 2004
60	July 2004
83	June 2004
118	May 2004
43	April 2004
44	March 2004
105	February 2004
77	January 2004
54	December 2003
15	November 2003
76	October 2003
207	September 2003
112	August 2003
336	July 2003
192	June 2003
182	May 2003
168	April 2003
330	March 2003
453	February 2003
551	January 2003
355	December 2002
186	November 2002
218	October 2002
245	September 2002
127	August 2002
223	July 2002
371	June 2002
453	May 2002
373	April 2002

DAVA came before ASP_ACTIVE_ACK is coreect?

Re: DAVA came before ASP_ACTIVE_ACK is coreect?

GT Routing with NULL(H'0000) PC

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

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

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

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

DPC in REG REQ

Re: DPC in REG REQ

Re: DPC in REG REQ

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31