Subject: [Sigtran] ringback tone / voice announcements in BICC
From: Victor Pascual Ávila <[email-masked]>
To: [email-masked]
Date: Tue, 10 Feb 2009 20:14:52 +0100
List-Id: Signaling Transport <sigtran.ietf.org>

Hello,
excuse me if this mailing list is not intended for such questions.

I'm digging into the ITU-T BICC specs and I fail to clarify which
nodes COULD be generating the ringback tone in a BICC network.

Once the ACM is sent and the Alerting takes place, the caller is
allowed to hear the ringback tone or even announcements from the
network for a period of time. It is quite common that the nearest
local exchange to the callee (terminating) generates this ringback
tone.

>From the call flows I found in the specs (I understand the call flows
to be informative in nature), in the unsuccessful call set-up
procedure, tones or announcements are generated in the originating
exchange. On the other hand, in the successful call set-up procedure,
they are generated in the terminating exchange.

Is it possible, for a successful call, to generate the ringback tone
at the originating exchange (kind of similar to SIP)?

Thank you,
-- 
Victor Pascual Ávila

Date: Tue, 10 Feb 2009 12:33:50 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Victor Pascual =?iso-8859-1?Q?�vila?= <[email-masked]>
Mail-Followup-To: Victor Pascual =?iso-8859-1?Q?�vila?= <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] ringback tone / voice announcements in BICC
Reply-To: [email-masked]

Victor,

Victor Pascual �vila wrote:                  (Tue, 10 Feb 2009 20:14:52)
> 
> Is it possible, for a successful call, to generate the ringback tone
> at the originating exchange (kind of similar to SIP)?

No.

--brian

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

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 13:55:49 -0000
From: "David Laight" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: [Sigtran] M3UA notify following ASP-up-ack

Should an M3UA SGP always send out a Nofity with the current
state of the AS following an ASP-Up-Ack?

This message is shown in the all the n+k sparing/loadsharing
examples in section 5 of RFC 4666.
Section 3.8.2 only states that the notifications are sent
when the AS state itself changes.

Without such a notification it is almost impossible for
a loadshare ASP to know whether it is allowed to send
traffic following its own ASP activate sequence, since
it cannot know whether the AS was already active, or still
has insufficient ASP.

The only alternative is for the ASP to (effectively) assume
that the AS is 'active' unless/until told otherwise.

	David

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to

From: "Sergey Mikhailov" <[email-masked]>
To: "David Laight" <[email-masked]>
Date: Tue, 17 Feb 2009 21:16:35 +0700
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify following ASP-up-ack

David,

yes, it should, provided this ASP Up Ack message follows the ASP transition 
from ASP-Down to ASP-Inactive, see Section 4.3.4.5 of RFC 4666:

"When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a 
Notify message SHOULD be sent, by the ASP-UP receptor, after sending the 
ASP-UP-ACK, in order to inform the ASP of the current AS state."

Regards,
Sergey Mikhailov.

----- Original Message ----- 
From: "David Laight" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, February 17, 2009 8:55 PM
Subject: [Sigtran] M3UA notify following ASP-up-ack

> Should an M3UA SGP always send out a Nofity with the current
> state of the AS following an ASP-Up-Ack?
>
> This message is shown in the all the n+k sparing/loadsharing
> examples in section 5 of RFC 4666.
> Section 3.8.2 only states that the notifications are sent
> when the AS state itself changes.
>
> Without such a notification it is almost impossible for
> a loadshare ASP to know whether it is allowed to send
> traffic following its own ASP activate sequence, since
> it cannot know whether the AS was already active, or still
> has insufficient ASP.
>
> The only alternative is for the ASP to (effectively) assume
> that the AS is 'active' unless/until told otherwise.
>
> David
>
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 
> 1PT, UK
> Registration No: 1397386 (Wales)
> P Please consider the environment and don't print this e-mail unless you 
> really need to
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran 

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 15:02:24 -0000
From: "David Laight" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: [Sigtran] M3UA notify following ASP-up-ack

> yes, it should, provided this ASP Up Ack message follows the ASP
transition 
> from ASP-Down to ASP-Inactive, see Section 4.3.4.5 of RFC 4666:
> 
> "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular
AS, a 
> Notify message SHOULD be sent, by the ASP-UP receptor, after sending
the 
> ASP-UP-ACK, in order to inform the ASP of the current AS state."

That doesn't explain the presence of the 2nd (and 3rd)
NOTIFY(AS-INACTIVE)
in sections 5.1.3 (and 5.1.4).

There is also the presumable assumption that they would be replaced
by NOTIFY(AS-ACTIVE) if the AS is already active.

If a NOTIFY() isn't generated followning every ASP-UP-ACK [1] then
with slight reordering of the requests the example in 5.1.4 leaves
the latter connections no idea of the actual AS state and whether
they should be sending traffic.

We don't send traffic until we've received an explicit indication
of AS-ACTIVE. But on a loadshare config the latter connections
aren't receiving the indication.

	David

[1] or when the registration procedures finish.

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to

Content-class: urn:content-classes:message
Date: Tue, 17 Feb 2009 16:10:09 -0000
To: "David Laight" <[email-masked]>, "sigtran" <[email-masked]>
Subject: Re: [Sigtran] M3UA notify following ASP-up-ack

> > yes, it should, provided this ASP Up Ack message follows the ASP
transition 
> > from ASP-Down to ASP-Inactive, see Section 4.3.4.5 of RFC 4666:
> > 
> > "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular
AS, a 
> > Notify message SHOULD be sent, by the ASP-UP receptor, after sending
the 
> > ASP-UP-ACK, in order to inform the ASP of the current AS state."

Grrr.... now I'm getting confused between the difference between
ASP-INACTIVE and AS-INACTIVE.

I suspect the 'problem' is that the quoted text isn't in rfc 3332.
(and the examples in section 5 of rfc 3332 don't contain the
relevant NOTIFY messages.)

	David

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to

From: "Sergey Mikhailov" <[email-masked]>
To: "David Laight" <[email-masked]>
Date: Tue, 17 Feb 2009 23:33:05 +0700
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA notify following ASP-up-ack

David,
see my comments below.

----- Original Message ----- 
From: "David Laight" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, February 17, 2009 10:02 PM
Subject: Re: [Sigtran] M3UA notify following ASP-up-ack

>> yes, it should, provided this ASP Up Ack message follows the ASP
> transition
>> from ASP-Down to ASP-Inactive, see Section 4.3.4.5 of RFC 4666:
>>
>> "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular
> AS, a
>> Notify message SHOULD be sent, by the ASP-UP receptor, after sending
> the
>> ASP-UP-ACK, in order to inform the ASP of the current AS state."
>
> That doesn't explain the presence of the 2nd (and 3rd)
> NOTIFY(AS-INACTIVE)
> in sections 5.1.3 (and 5.1.4).

Don't confuse AS state changes and ASP state changes. These ASPs move from 
ASP-Down to ASP-Inactive and they are sent NOTIFY about the current AS 
state. Regardless of the AS state change.

>
> There is also the presumable assumption that they would be replaced
> by NOTIFY(AS-ACTIVE) if the AS is already active.

NOTIFY always reports the actual AS state, of course. Regardless of state of 
any specific ASP.

>
> If a NOTIFY() isn't generated followning every ASP-UP-ACK [1] then
> with slight reordering of the requests the example in 5.1.4 leaves
> the latter connections no idea of the actual AS state and whether
> they should be sending traffic.

Normally any ASP always learns AS state whenever that ASP moves from 
ASP-Down to ASP-Inactive (I assume that 'SHOULD' is respected in 4.3.4.5). 
Then the ASP will receive notifications on the AS state changes, as long as 
this ASP is not in ASP-Down.

>
> We don't send traffic until we've received an explicit indication
> of AS-ACTIVE. But on a loadshare config the latter connections
> aren't receiving the indication.

Once again: they do receive, as soon as they move from ASP-Down to 
ASP-Inactive.

Sergey Mikhailov. 

Date: Tue, 17 Feb 2009 23:32:05 -0800 (PST)
From: [email-masked]
To: sigtran <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: [Sigtran] Query regarding trafic mode for IPSP.
Reply-To: [email-masked]

--0-271527193-1234942325=:56217
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
�
I have some doubts regarding dynamic RK registration procedure and different traffic mod for IPSP end point in M3UA.
�
1. Let endpoint A (OPC= 1.1.1) communicate with endpoint B (2.2.2) then� 
should both ends send REG REQ message in case of IPSP DE mode?
�
2- If both end register RK,should endpoint use one RC for sending data and one RC for receiving data for same RK.
�
3.Which end should send REG REQ message in case of IPSP SE model?
�
4.In IPSP mode, what are the possible trffic mode?Can IPSP endpoint being in all traffic mode for m3ua?
5. In IPSP mode, should peer IPSPs use the same Traffic Mode Type, or can they use different modes ?
�
Thanks for any clarifications.
�
Best regards.
Padmalochan.
�

      
--0-271527193-1234942325=:56217
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have some doubts regarding <SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">dynamic RK registration procedure and different traffic mod for IPSP end point in M3UA.</SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV>1. <SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">Let endpoint A (OPC= 1.1.1) communicate with endpoint B (2.2.2) then&nbsp; </SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">should both ends send REG REQ message in case of <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:place w:st="on"><st1:City w:st="on">IPSP</st1:City> <st1:State w:st="on">DE</st1:State></st1:place> mode?</SPAN></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">2- If both end register RK,should endpoint use one RC for sending data and one RC for receiving data for same RK.</SPAN></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN></SPAN><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">3.<SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">Which end should send REG REQ message in case of IPSP SE model?</SPAN></SPAN></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN></SPAN></SPAN>&nbsp;</DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt;
 FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">
<DIV>4.In IPSP mode, what are the possible trffic mode?Can IPSP endpoint being in all traffic mode for m3ua?</DIV>
<DIV>5. In IPSP mode, should peer IPSPs use the same Traffic Mode Type, or can they use different modes ?</DIV></SPAN></SPAN></SPAN>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">Thanks for any clarifications.</SPAN></SPAN></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">Best regards.</SPAN></SPAN></SPAN></DIV>
<DIV><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA">Padmalochan.</SPAN></SPAN></SPAN></DIV>
<DIV>&nbsp;</DIV></td></tr></table><br>

--0-271527193-1234942325=:56217--

Date: Wed, 18 Feb 2009 02:18:04 -0800 (PST)
From: [email-masked]
To: sigtran <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: [Sigtran] Query regarding re-registration procedure in m3ua.
Reply-To: [email-masked]

--0-796819373-1234952284=:27882
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
�
As per the rfc-4666, 
�
4.4.1.� Registration

An ASP MAY request modification of an existing Routing Key by�� including a Routing Context parameter in a Registration Request message.Upon receipt of a Registration Request message containing a Routing Context, if the SGP determines that the Routing Context� applies to an existing Routing Key, the SGP MAY adjust the existing�� Routing Key to match the new information provided in the Routing Key� parameter.� A Registration Response "ERR Routing Key Change Refused"� is returned if the SGP does not support this re-registration�� procedure or RC does not exist.� Otherwise, a Registration Response
�� "Successfully Registered" is returned.
�
I have doubt regarding the state chage after re-registration procedure.
Supposed the curent state is ASP_ACTIVE, should after receive the state of the ASP chage to ASP INACTIVE?
�
should ASP start the active procedure again?
�
Br,
Padmalochan
�
�

      
--0-796819373-1234952284=:27882
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>As per the rfc-4666, </DIV>
<DIV>&nbsp;</DIV>
<DIV>4.4.1.&nbsp; Registration<BR></DIV>
<DIV>An ASP MAY request modification of an existing Routing Key by&nbsp;&nbsp; including a Routing Context parameter in a Registration Request message.Upon receipt of a Registration Request message containing a Routing Context, if the SGP determines that the Routing Context&nbsp; applies to an existing Routing Key, the SGP MAY adjust the existing&nbsp;&nbsp; Routing Key to match the new information provided in the Routing Key&nbsp; parameter.&nbsp; A Registration Response "ERR Routing Key Change Refused"&nbsp; is returned if the SGP does not support this re-registration&nbsp;&nbsp; procedure or RC does not exist.&nbsp; Otherwise, a Registration Response<BR>&nbsp;&nbsp; "Successfully Registered" is returned.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have doubt regarding the state chage after re-registration procedure.</DIV>
<DIV>Supposed the curent state is ASP_ACTIVE, should after receive the state of the ASP chage to ASP INACTIVE?</DIV>
<DIV>&nbsp;</DIV>
<DIV>should ASP start the active procedure again?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></td></tr></table><br>

--0-796819373-1234952284=:27882--

From: "Barry Nagelberg" <[email-masked]>
To: <[email-masked]>
Date: Wed, 18 Feb 2009 08:38:56 -0500
Importance: Normal
Cc: sigtran <[email-masked]>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.

Padmalochan,

No, there is no need to change the ASP_ACTIVE state at the SGP after the receipt after the modification of an existing
Routing Key.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Wednesday, February 18, 2009 5:18 AM
To: sigtran
Cc: bidulock
Subject: [Sigtran] Query regarding re-registration procedure in m3ua.

Hi,

As per the rfc-4666,

4.4.1.  Registration

An ASP MAY request modification of an existing Routing Key by   including a Routing Context parameter in a Registration
Request message.Upon receipt of a Registration Request message containing a Routing Context, if the SGP determines that
the Routing Context  applies to an existing Routing Key, the SGP MAY adjust the existing   Routing Key to match the new
information provided in the Routing Key  parameter.  A Registration Response "ERR Routing Key Change Refused"  is
returned if the SGP does not support this re-registration   procedure or RC does not exist.  Otherwise, a Registration
Response
   "Successfully Registered" is returned.

I have doubt regarding the state chage after re-registration procedure.
Supposed the curent state is ASP_ACTIVE, should after receive the state of the ASP chage to ASP INACTIVE?

should ASP start the active procedure again?

Br,
Padmalochan

Date: Fri, 20 Feb 2009 13:24:07 -0800 (PST)
From: Chris Benson <[email-masked]>
To: [email-masked]
Cc: bidulock <[email-masked]>, sigtran <[email-masked]>
Subject: Re: [Sigtran] Query regarding trafic mode for IPSP.

Padmalochan,

Two point-to-point peer communicating IPSPs will NOT be in the 
same AS. There is a one-to-one correspondence of AS to Routing 
Key, so the two communicating IPSPs will serve different 
Routing Keys (be in different ASs). If only dynamic registration
is used, then each IPSP will register its own RK with the other.

The Routing Context used is just a shorthand index number
that specifies the RK. Its use is optional by mutual agreement.
Each side's RC references its RK. They are different (but may
have the same value!!). It wouldn't generally be needed in
simple IPSP cconfigurations.

In response to your numbered questions:

1. Yes both send REG REQ if dynamic registration is needed.
2. RC is often not needed. If needed it refers to an RK
   which describes an AS represented by one of the IPSPs.
   RC is not used to distinguish between two peer IPSPs.
   It is used to distinguish between two ASs (RKs) at the
   SAME IPSP. If one IPSP is in only one local AS, then
   RC isn't needed.
3. Both send REG REQ (if dynamic registration is required).

In M3UA, the raffic mode specifies how you would like to
RECEIVE user-data amongst multiple local ASPs, IPSPs, or
SGPs within a single AS or SG.

4. Yes all M3UA traffic modes are possible in an IPSP.
5. Peer IPSPs can have different traffic modes (different
   ways of RECEIVING data). It is only that IPSPs on the
   SAME side (not peers) that service the same AS must
   have the same traffic mode for incoming user-data.

Best regards, from Chris Benson.

On Tue, 17 Feb 2009, [email-masked] wrote:

>>  Date: Tue, 17 Feb 2009 23:32:05 -0800 (PST)
>>  From:  <[email-masked]>
>>  To: sigtran <[email-masked]>
>>  Cc: bidulock <[email-masked]>
>>  Subject: [Sigtran] Query regarding trafic mode for IPSP.
>>  
>>  Hi,
>>   
>>  I have some doubts regarding dynamic RK registration procedure and different traffic mod for IPSP end point in M3UA.
>>   
>>  1. Let endpoint A (OPC= 1.1.1) communicate with endpoint B (2.2.2) then  
>>  should both ends send REG REQ message in case of IPSP DE mode?
>>   
>>  2- If both end register RK,should endpoint use one RC for sending data and one RC for receiving data for same RK.
>>   
>>  3.Which end should send REG REQ message in case of IPSP SE model?
>>   
>>  4.In IPSP mode, what are the possible trffic mode?Can IPSP endpoint being in all traffic mode for m3ua?
>>  5. In IPSP mode, should peer IPSPs use the same Traffic Mode Type, or can they use different modes ?
>>   
>>  Thanks for any clarifications.
>>   
>>  Best regards.
>>  Padmalochan.
>>   

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 11:41:15 -0500
From: "Hecht Martin" <[email-masked]>
To: <[email-masked]>
Cc: Hecht Martin <[email-masked]>
Subject: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers

This is a multi-part message in MIME format.

------_=_NextPart_001_01C995D5.88457F5F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

To the mailing list,

In the M2PA RFC it details how to resynchronize sequence numbers after
LPR/RPR as follows:

		M2PA (at both the LPO and RPO ends) uses the BSN value
in the
		received Link Status Ready message to resynchronize its
sequence
		numbers, if this is required by MTP2.  
 
The problem is the "required by MTP2" issue.  If one side resynchronizes
its FSN to the BSN received in the READY message, but the other side
didn't implement this, then the FSN on the next MSU received would be
wrong and the MSU will be discarded.

For example, I am running M2PA conformance tests against the INET.  It
doesn't resynchronize its FSN to the incoming BSN as described above.
So the next FSN sent by the Inet is not expected and is discarded.

So, the question is, is the resynchronizing really optional?  Or am I
misunderstanding the meaning of synchronize and the FSN is not set to
the BSN of the incoming READY message?

Thanks,
Martin

Martin Hecht
Engineering
Signaling Core Group
Comverse
Office: +856 608-2712
[email-masked]
www.comverse.com <http://www.comverse.com/> 

------_=_NextPart_001_01C995D5.88457F5F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>Processor Outage and Resynchronizing Sequence Numbers</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">To the mailing list,</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">In the</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> M2PA RFC it details how to resynchronize sequence</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">numbers after LPR/RPR</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">as follows:</FONT></SPAN></P>
<UL DIR=LTR><UL DIR=LTR>
<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">M2PA (at both the LPO and RPO ends) uses the BSN value in the</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">received Link Status Ready message to resynchronize its sequence</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">numbers, if this is required by MTP2.&nbsp;</FONT></SPAN><SPAN LANG="en-us"> </SPAN></P>
</UL></UL>
<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri"></FONT></SPAN><SPAN LANG="en-us">&nbsp;</SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">The problem is the</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">&#8220;required</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> by MTP2</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">&#8221;</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> issue.&nbsp; If one side resynchronizes its FSN</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> to the BSN received in the READY message</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">, but the other side didn</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">&#8217;</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">t implement this, then the</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">FSN on</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">the</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> next MSU received would be wrong</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> and the MSU will be discarded.</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">For example, I am running M2PA conformance tests against the INET.&nbsp; It doesn</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">&#8217;</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">t resynchronize its FSN</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">to the</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"> incoming BSN as</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">described above.&nbsp; So the</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">next</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">FSN sent by the Inet is not expected and is</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">discarded</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">.</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">So, the question is, is the resynchronizing really optional?</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp; Or am I misunderstanding the meaning of synchronize and the FSN is not set</FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">to the</FONT></SPAN><SPAN LANG="en-us"><FONT FACE="Calibri"></FONT></SPAN><SPAN LANG="en-us"> <FONT FACE="Calibri">BSN of the incoming READY message?</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">Thanks,</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">Martin</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><B></B></SPAN><SPAN LANG="en-us"><B></B></SPAN><B><SPAN LANG="en-us"></SPAN></B><B><SPAN LANG="en-us"><FONT COLOR="#828282" SIZE=2 FACE="Verdana">Martin Hecht</FONT></SPAN></B><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><BR>
</SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT COLOR="#808080" SIZE=2 FACE="Verdana">Engineering</FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT COLOR="#808080" SIZE=2 FACE="Verdana">Sign</FONT><FONT COLOR="#808080" SIZE=2 FACE="Verdana">aling Core Group<BR>
</FONT></SPAN><SPAN LANG="en-us"><B></B></SPAN><SPAN LANG="en-us"><B></B></SPAN><B><SPAN LANG="en-us"></SPAN></B><B><SPAN LANG="en-us"><FONT COLOR="#808080" SIZE=2 FACE="Verdana">Comverse<BR>
</FONT></SPAN></B><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT COLOR="#808080" SIZE=2 FACE="Verdana">Office: +856 608-2712</FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><BR>
</SPAN><SPAN LANG="en-us"></SPAN><A HREF="mailto:[email-masked]"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U></U></SPAN><U><SPAN LANG="en-us"></SPAN></U><U><SPAN LANG="en-us"><FONT COLOR="#808080" SIZE=2 FACE="Verdana">[email-masked]</FONT></SPAN></U><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><BR>
</SPAN><SPAN LANG="en-us"></SPAN><A HREF="http://www.comverse.com/"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U></U></SPAN><U><SPAN LANG="en-us"></SPAN></U><U><SPAN LANG="en-us"><FONT COLOR="#808080" SIZE=2 FACE="Verdana">www.comverse.com</FONT></SPAN></U><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C995D5.88457F5F--

Date: Mon, 23 Feb 2009 15:02:23 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Hecht Martin <[email-masked]>
Mail-Followup-To: Hecht Martin <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers
Reply-To: [email-masked]

Martin,

Please don't use brand names on this list.

"if this is required by MTP2"

Resynchronization is required by ITU-T Q.703 1996,
ETSI EN 300 008-1, and ANSI T1.111.3/2000.

However, I am a little bit confused as to why you
think that the one end synchronizing and the other
end not will cause a problem.  Could you provide
a message sequence chart for what you think the
problem will be?

--brian

Hecht Martin wrote:                           (Mon, 23 Feb 2009 11:41:15)
> 
>    To the mailing list,
> 
>    In the M2PA RFC it details how to resynchronize sequence numbers after
>    LPR/RPR as follows:
> 
>    M2PA (at both the LPO and RPO ends) uses the BSN value in the
>        received Link Status Ready message to resynchronize its sequence
>        numbers, if this is required by MTP2.
> 
> 
>    The problem is the "required by MTP2" issue.  If one side
>    resynchronizes its FSN to the BSN received in the READY message, but
>    the other side didn't implement this, then the FSN on the next MSU
>    received would be wrong and the MSU will be discarded.
> 
>    For example, I am running M2PA conformance tests against the INET.  It
>    doesn't resynchronize its FSN to the incoming BSN as described above.
>    So the next FSN sent by the Inet is not expected and is discarded.
> 
>    So, the question is, is the resynchronizing really optional?  Or am I
>    misunderstanding the meaning of synchronize and the FSN is not set to
>    the BSN of the incoming READY message?
> 
>    Thanks,
> 
>    Martin
> 
>    Martin Hecht
>    Engineering
> 
>    Signaling Core Group
>    Comverse
>    Office: +856 608-2712
>    [1][email-masked]
>    [2]www.comverse.com
> 
> References
> 
>    1. mailto:[email-masked]
>    2. http://www.comverse.com/

> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

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

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 09:37:14 -0500
From: "Hecht Martin" <[email-masked]>
To: <[email-masked]>
Cc: Hecht Martin <[email-masked]>, [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers

Brian,

Excuse me for using a brand name in my email, I meant no disrespect to
the product I named.

I am running test 3.4.1-1 from the M2PA Test 08 Specification.  After
the exchange of READY messages of step (12) synchronization is not
happening at SP B and the Data Messages from SP B are sent with, what SP
A considers to be, an invalid FSN.  SP A is discarding the data messages
and SP B takes the link Out-of-Service due to T7 excessive delay of ACK.

SP A   READY BSN 1 FSN 1     --------------->
                             <---------------  SP B   READY BSN 1 FSN 3
                             <---------------  SP B   Data Msg. BSN 1
FSN 4
SP A   Data Msg. BSN 1 FSN 2 ---------------->
                             <---------------  SP B   Empty Data Msg.
BSN 2 FSN 4
                             <---------------  SP B   Link Status OOS

My understanding is that the Data Message from SP B after the exchange
of READY messages should have an FSN of 2.  SP A is discarding both the
Data Message and the Empty Data Message.

Best regards,
Martin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, February 23, 2009 5:02 PM
To: Hecht Martin
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence
Numbers

Martin,

Please don't use brand names on this list.

"if this is required by MTP2"

Resynchronization is required by ITU-T Q.703 1996,
ETSI EN 300 008-1, and ANSI T1.111.3/2000.

However, I am a little bit confused as to why you
think that the one end synchronizing and the other
end not will cause a problem.  Could you provide
a message sequence chart for what you think the
problem will be?

--brian

Hecht Martin wrote:                           (Mon, 23 Feb 2009
11:41:15)
> 
>    To the mailing list,
> 
>    In the M2PA RFC it details how to resynchronize sequence numbers
after
>    LPR/RPR as follows:
> 
>    M2PA (at both the LPO and RPO ends) uses the BSN value in the
>        received Link Status Ready message to resynchronize its
sequence
>        numbers, if this is required by MTP2.
> 
> 
>    The problem is the "required by MTP2" issue.  If one side
>    resynchronizes its FSN to the BSN received in the READY message,
but
>    the other side didn't implement this, then the FSN on the next MSU
>    received would be wrong and the MSU will be discarded.
> 
>    For example, I am running M2PA conformance tests against the INET.
It
>    doesn't resynchronize its FSN to the incoming BSN as described
above.
>    So the next FSN sent by the Inet is not expected and is discarded.
> 
>    So, the question is, is the resynchronizing really optional?  Or am
I
>    misunderstanding the meaning of synchronize and the FSN is not set
to
>    the BSN of the incoming READY message?
> 
>    Thanks,
> 
>    Martin
> 
>    Martin Hecht
>    Engineering
> 
>    Signaling Core Group
>    Comverse
>    Office: +856 608-2712
>    [1][email-masked]
>    [2]www.comverse.com
> 
> References
> 
>    1. mailto:[email-masked]
>    2. http://www.comverse.com/

> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

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

Date: Tue, 24 Feb 2009 11:26:00 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Hecht Martin <[email-masked]>
Mail-Followup-To: Hecht Martin <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers
Reply-To: [email-masked]

Martin,

Yes, I was afraid of that.  Test case 3.4.1 was only updated to
M2PA draft level 11.  Some changes were made to the final that
invalidate it.

The current test looks like this:

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000001--  PROCESSOR-RECOVERED    |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                 READY  --000000, 000000->                         |
  |  [ 35 bytes]     DATA  --000001, 000000->                         |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000001->                         |
  |                        <-000001, 000001--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

But it should look like this:

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000002--  PROCESSOR-RECOVERED    |
  |                 READY  --000002, 000000->                         |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                        <-000001, 000002--  DATA [   35 bytes]     |
  |              DATA-ACK  --000003, 000001->                         |
  |                        <-000001, 000003--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

So the PROCESSOR-RECOVERED acknowledges all oustanding messages
even though they are cleared from the buffer.  This is in
fitting with the text that states that:

   The BSN in the Link Status Processor Recovered message is set
   to the FSN of the last User Data message received (and not
   discarded) from the peer M2PA.

Here "not discarded" means that it passed FSN and BSN sanity
checks.  This is in fitting with the procedures of ANSI
T1.111.3/2000 Clause 8 which states:

   If level 3 requests level 2 to resume normal operation,
   level 2 resumes acceptable of message signal units from
   remote level 2 and normal transmission of message signal
   units and fill-in signal units.  The first message signal
   unit or fill-in signal unit transmitted acknowledges all
   message signal units that have been accepted from remote
   level 2, including any message signal units for which
   acknowledgement were previously withheld because of level 2
   congestion (see section 9).

Also ITU-T Rec. Q.703 (1996) Clause 8 which states:

   Because of the above, in order to (sic) avoid sending of old
   messages, the level 2 buffers on both sides should be flushed
   immediately after the local/remote processor outage state
   terminates.  In addition, the synchronization of the level 2
   sequence numbers has to be assured.  This is necessary for
   the correct operation of the link.  It is understood that
   each side is responsible for the flushing and synchronization
   concerning its own level 2 and that the specific actions
   concerning the synchonization of the level 2 sequence numbers
   must not rely on the action of the other side.  How these
   measure are performed is considered to be implementation
   dependent.

Most of the problems with sychronization of level 2 sequence
numbers under Q.703/T1.111.3 have to do with the flushing of the
retransmission buffer.  The FSN is set to the first received BSN
to avoid a NAK requiring retransmission of a flused MSU from the
RTB.  M2PA does not have this problem as it is (in the final)
assured that the MSU has reached the other side before it
receives the PROCESSOR-RECOVERED (which is now transmitted on
the data stream and cannot overtake MSUs from the RTB).
Therefore, the BSN in the READY received in response to the
PROCESSOR-RECOVERED is simply the FSNT.

The situation of 3.4.1 previouly was trying to handle the race
conditions of sending PROCESSOR-RECOVERED and READY on the
control stream instead of the data stream.

Sorry, but I gave up updating the M2PA test spec because if it
is not going to an INFORMATIONAL RFC there isn't much point.
I will likely just update the validation test suite software
and the M2PA implementation instead.

--brian

Hecht Martin wrote:                           (Tue, 24 Feb 2009 09:37:14)
> Brian,
> 
> Excuse me for using a brand name in my email, I meant no disrespect to
> the product I named.
> 
> I am running test 3.4.1-1 from the M2PA Test 08 Specification.  After
> the exchange of READY messages of step (12) synchronization is not
> happening at SP B and the Data Messages from SP B are sent with, what SP
> A considers to be, an invalid FSN.  SP A is discarding the data messages
> and SP B takes the link Out-of-Service due to T7 excessive delay of ACK.
> 
> SP A   READY BSN 1 FSN 1     --------------->
>                              <---------------  SP B   READY BSN 1 FSN 3
>                              <---------------  SP B   Data Msg. BSN 1
> FSN 4
> SP A   Data Msg. BSN 1 FSN 2 ---------------->
>                              <---------------  SP B   Empty Data Msg.
> BSN 2 FSN 4
>                              <---------------  SP B   Link Status OOS
> 
> My understanding is that the Data Message from SP B after the exchange
> of READY messages should have an FSN of 2.  SP A is discarding both the
> Data Message and the Empty Data Message.
> 
> Best regards,
> Martin
> 

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

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 13:43:06 -0500
From: "Hecht Martin" <[email-masked]>
To: <[email-masked]>
Cc: Hecht Martin <[email-masked]>, [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers

Brian,

I'll have to think about your response.

By the way, am I correct in my understanding that the synchronization
actually takes place according to the READY messages that must be
exchanged?

M2PA (at both the LPO and RPO ends) uses the BSN value in the
   received Link Status Ready message to resynchronize its sequence
   numbers, if this is required by MTP2.  M2PA SHALL NOT resume
   transmitting User Data messages until it has sent the Link Status
   Ready message.

In the test below I don't see the SP A responding with a READY after
receiving the READY from SP B.  Is that just understood?

Thanks,
Martin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, February 24, 2009 1:26 PM
To: Hecht Martin
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence
Numbers

Martin,

Yes, I was afraid of that.  Test case 3.4.1 was only updated to
M2PA draft level 11.  Some changes were made to the final that
invalidate it.

The current test looks like this:

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000001--  PROCESSOR-RECOVERED    |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                 READY  --000000, 000000->                         |
  |  [ 35 bytes]     DATA  --000001, 000000->                         |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000001->                         |
  |                        <-000001, 000001--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

But it should look like this:

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000002--  PROCESSOR-RECOVERED    |
  |                 READY  --000002, 000000->                         |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                        <-000001, 000002--  DATA [   35 bytes]     |
  |              DATA-ACK  --000003, 000001->                         |
  |                        <-000001, 000003--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

So the PROCESSOR-RECOVERED acknowledges all oustanding messages
even though they are cleared from the buffer.  This is in
fitting with the text that states that:

   The BSN in the Link Status Processor Recovered message is set
   to the FSN of the last User Data message received (and not
   discarded) from the peer M2PA.

Here "not discarded" means that it passed FSN and BSN sanity
checks.  This is in fitting with the procedures of ANSI
T1.111.3/2000 Clause 8 which states:

   If level 3 requests level 2 to resume normal operation,
   level 2 resumes acceptable of message signal units from
   remote level 2 and normal transmission of message signal
   units and fill-in signal units.  The first message signal
   unit or fill-in signal unit transmitted acknowledges all
   message signal units that have been accepted from remote
   level 2, including any message signal units for which
   acknowledgement were previously withheld because of level 2
   congestion (see section 9).

Also ITU-T Rec. Q.703 (1996) Clause 8 which states:

   Because of the above, in order to (sic) avoid sending of old
   messages, the level 2 buffers on both sides should be flushed
   immediately after the local/remote processor outage state
   terminates.  In addition, the synchronization of the level 2
   sequence numbers has to be assured.  This is necessary for
   the correct operation of the link.  It is understood that
   each side is responsible for the flushing and synchronization
   concerning its own level 2 and that the specific actions
   concerning the synchonization of the level 2 sequence numbers
   must not rely on the action of the other side.  How these
   measure are performed is considered to be implementation
   dependent.

Most of the problems with sychronization of level 2 sequence
numbers under Q.703/T1.111.3 have to do with the flushing of the
retransmission buffer.  The FSN is set to the first received BSN
to avoid a NAK requiring retransmission of a flused MSU from the
RTB.  M2PA does not have this problem as it is (in the final)
assured that the MSU has reached the other side before it
receives the PROCESSOR-RECOVERED (which is now transmitted on
the data stream and cannot overtake MSUs from the RTB).
Therefore, the BSN in the READY received in response to the
PROCESSOR-RECOVERED is simply the FSNT.

The situation of 3.4.1 previouly was trying to handle the race
conditions of sending PROCESSOR-RECOVERED and READY on the
control stream instead of the data stream.

Sorry, but I gave up updating the M2PA test spec because if it
is not going to an INFORMATIONAL RFC there isn't much point.
I will likely just update the validation test suite software
and the M2PA implementation instead.

--brian

Hecht Martin wrote:                           (Tue, 24 Feb 2009
09:37:14)
> Brian,
> 
> Excuse me for using a brand name in my email, I meant no disrespect to
> the product I named.
> 
> I am running test 3.4.1-1 from the M2PA Test 08 Specification.  After
> the exchange of READY messages of step (12) synchronization is not
> happening at SP B and the Data Messages from SP B are sent with, what
SP
> A considers to be, an invalid FSN.  SP A is discarding the data
messages
> and SP B takes the link Out-of-Service due to T7 excessive delay of
ACK.
> 
> SP A   READY BSN 1 FSN 1     --------------->
>                              <---------------  SP B   READY BSN 1 FSN
3
>                              <---------------  SP B   Data Msg. BSN 1
> FSN 4
> SP A   Data Msg. BSN 1 FSN 2 ---------------->
>                              <---------------  SP B   Empty Data Msg.
> BSN 2 FSN 4
>                              <---------------  SP B   Link Status OOS
> 
> My understanding is that the Data Message from SP B after the exchange
> of READY messages should have an FSN of 2.  SP A is discarding both
the
> Data Message and the Empty Data Message.
> 
> Best regards,
> Martin
> 

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

Date: Tue, 24 Feb 2009 12:44:55 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Hecht Martin <[email-masked]>
Mail-Followup-To: Hecht Martin <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers
Reply-To: [email-masked]

Hecht,

Hecht Martin wrote:                           (Tue, 24 Feb 2009 13:43:06)
> Brian,
> 
> I'll have to think about your response.
> 
> By the way, am I correct in my understanding that the synchronization
> actually takes place according to the READY messages that must be
> exchanged?
> 
> M2PA (at both the LPO and RPO ends) uses the BSN value in the
>    received Link Status Ready message to resynchronize its sequence
>    numbers, if this is required by MTP2.  M2PA SHALL NOT resume
>    transmitting User Data messages until it has sent the Link Status
>    Ready message.

Well now, here's the rub.  MTP2 requires that when either side clears
its RTB that it resynchronize by setting FSNT to BSNR; however, FSNT
is only different from BSNR when some message in the RTB has failed
to reach the other end.  This cannot happen for M2PA as specified in
the RFC because SCTP is a reliable transport and both the PROCESSOR-
RECOVERED and READY messages are sent ordered on the data stream.
This means that all messages sent before it are received before these
messages are received.  Therefore, FSNT and BSNR must always be the
same and is is only necessary to set FNST to BSNR "if this is required
by [the] MTP2 [state machine used]".

So, put short, because SCTP does not lose messages, and as long as
PROCESSOR-RECOVERED and the READY messages in this sequence are sent
on the data stream, resynchronization is not necessary.

An example:

For ANSI T1.111.3 the following is the scenario:

 SP A BSN:FSN                  FSN:BSN SP B

 FISU [7F:7F] --------------->
              <--------------- [7F:7F] FISU
 MSU  [7F:00] -----\
 MSU  [7F:01] -----X\ lost
 MSU  [7F:02] -----\ \
 MSU  [7F:03] -----\\ \
 MSU  [7F:04] -----\\X-\------ [7F:7F] SIPO
 MSU  [7F:05] -----\X\\ \---->
 MSU  [7F:06] -----X\\\\
 MSU  [7F:07] ----X\\\\\\---->
              <--/ \\\\\\---->
                    \\\\\---->
                     \\\\---->
                      \\\---->
                       \\---->
                        \---->
              <--------------- [7F:7F] SIPO
 FISU [7F:07] --------------->
               long duration
 RTB contains                  RB contains
 MSUS 00 thru 07               MSU 00 only
 FSNT is 07
                               Ack all accepted
 Clear RTB                     MSUs with ACK withheld

              <--------------- [7F:00] FISU
 Set FSNT to BSNR
 FSNT is now 00                Clear RB

 MSU  [7F:01] ---------------->
              <--------------- [7F:01] FISU

Notice that if MSU 01 could not be lost or missequenced then
BSNR after acking withheld MSUs would match FSNT.

The M2PA case is:

 SP A BSN:FSN                  FSN:BSN SP B

 LSR  [7F:7F] --------------->
              <--------------- [7F:7F] LSR
 DATA [7F:00] -----\
 DATA [7F:01] -----\\
 DATA [7F:02] -----\\\
 DATA [7F:03] -----\\\\
 DATA [7F:04] -----\\X++------ [7F:7F] LSPO
 DATA [7F:05] -----\X\\\\---->
 DATA [7F:06] -----X\\\\\---->
 DATA [7F:07] ----X\\\\\\---->
              <--/ \\\\\\---->
                    \\\\\---->
                     \\\\---->
                      \\\---->
                       \\---->
                        \---->
               long duration

 RTB contains
 MSUs 00 thru 07
 FSNT is 07
                               Ack all accepted
 Clear RTB                     MSUS with ACKs withheld

              <--------------- [7F:07] LSPR
 Set FSNT to BSR
 FSNT is still 07

 LSR  [7F:07] --------------->
              <--------------- [7F:07] LSR
 MSU  [7F:08] --------------->
              <--------------- [7F:08] ACK

So, again, because the LSPR and LSR cannot overtake DATA when
sent ordered on the data stream, M2PA does not require
resynchronization of sequence numbers.

>
> In the test below I don't see the SP A responding with a READY after
> receiving the READY from SP B.  Is that just understood?

We changed to "it has sent" from "it has received" in 48 hours
before the RFC was released.  But of course you are right, there
should be a READY sent by the recovering end before it resumes
sending DATA.

--brian

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

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 15:41:31 -0500
From: "Hecht Martin" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers

Hi Brian,

Thanks for this and the other responses.

It is my understanding that any message received during the local
processor outage and received between the processor recovered and the
READY handshake, will not be sent to L3.  This means that they are lost
messages.

I understand from your emails that the sync will be as if they were
ack'd, even though they are lost, i.e. not sent to L3.

Is this understanding correct?

Thanks again,
Martin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, February 24, 2009 2:45 PM
To: Hecht Martin
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence
Numbers

Hecht,

Hecht Martin wrote:                           (Tue, 24 Feb 2009
13:43:06)
> Brian,
> 
> I'll have to think about your response.
> 
> By the way, am I correct in my understanding that the synchronization
> actually takes place according to the READY messages that must be
> exchanged?
> 
> M2PA (at both the LPO and RPO ends) uses the BSN value in the
>    received Link Status Ready message to resynchronize its sequence
>    numbers, if this is required by MTP2.  M2PA SHALL NOT resume
>    transmitting User Data messages until it has sent the Link Status
>    Ready message.

Well now, here's the rub.  MTP2 requires that when either side clears
its RTB that it resynchronize by setting FSNT to BSNR; however, FSNT
is only different from BSNR when some message in the RTB has failed
to reach the other end.  This cannot happen for M2PA as specified in
the RFC because SCTP is a reliable transport and both the PROCESSOR-
RECOVERED and READY messages are sent ordered on the data stream.
This means that all messages sent before it are received before these
messages are received.  Therefore, FSNT and BSNR must always be the
same and is is only necessary to set FNST to BSNR "if this is required
by [the] MTP2 [state machine used]".

So, put short, because SCTP does not lose messages, and as long as
PROCESSOR-RECOVERED and the READY messages in this sequence are sent
on the data stream, resynchronization is not necessary.

An example:

For ANSI T1.111.3 the following is the scenario:

 SP A BSN:FSN                  FSN:BSN SP B

 FISU [7F:7F] --------------->
              <--------------- [7F:7F] FISU
 MSU  [7F:00] -----\
 MSU  [7F:01] -----X\ lost
 MSU  [7F:02] -----\ \
 MSU  [7F:03] -----\\ \
 MSU  [7F:04] -----\\X-\------ [7F:7F] SIPO
 MSU  [7F:05] -----\X\\ \---->
 MSU  [7F:06] -----X\\\\
 MSU  [7F:07] ----X\\\\\\---->
              <--/ \\\\\\---->
                    \\\\\---->
                     \\\\---->
                      \\\---->
                       \\---->
                        \---->
              <--------------- [7F:7F] SIPO
 FISU [7F:07] --------------->
               long duration
 RTB contains                  RB contains
 MSUS 00 thru 07               MSU 00 only
 FSNT is 07
                               Ack all accepted
 Clear RTB                     MSUs with ACK withheld

              <--------------- [7F:00] FISU
 Set FSNT to BSNR
 FSNT is now 00                Clear RB

 MSU  [7F:01] ---------------->
              <--------------- [7F:01] FISU

Notice that if MSU 01 could not be lost or missequenced then
BSNR after acking withheld MSUs would match FSNT.

The M2PA case is:

 SP A BSN:FSN                  FSN:BSN SP B

 LSR  [7F:7F] --------------->
              <--------------- [7F:7F] LSR
 DATA [7F:00] -----\
 DATA [7F:01] -----\\
 DATA [7F:02] -----\\\
 DATA [7F:03] -----\\\\
 DATA [7F:04] -----\\X++------ [7F:7F] LSPO
 DATA [7F:05] -----\X\\\\---->
 DATA [7F:06] -----X\\\\\---->
 DATA [7F:07] ----X\\\\\\---->
              <--/ \\\\\\---->
                    \\\\\---->
                     \\\\---->
                      \\\---->
                       \\---->
                        \---->
               long duration

 RTB contains
 MSUs 00 thru 07
 FSNT is 07
                               Ack all accepted
 Clear RTB                     MSUS with ACKs withheld

              <--------------- [7F:07] LSPR
 Set FSNT to BSR
 FSNT is still 07

 LSR  [7F:07] --------------->
              <--------------- [7F:07] LSR
 MSU  [7F:08] --------------->
              <--------------- [7F:08] ACK

So, again, because the LSPR and LSR cannot overtake DATA when
sent ordered on the data stream, M2PA does not require
resynchronization of sequence numbers.

>
> In the test below I don't see the SP A responding with a READY after
> receiving the READY from SP B.  Is that just understood?

We changed to "it has sent" from "it has received" in 48 hours
before the RFC was released.  But of course you are right, there
should be a READY sent by the recovering end before it resumes
sending DATA.

--brian

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

Date: Wed, 25 Feb 2009 08:04:36 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Hecht Martin <[email-masked]>
Mail-Followup-To: Hecht Martin <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers
Reply-To: [email-masked]

Hecht,

Hecht Martin wrote:                           (Tue, 24 Feb 2009 15:41:31)
> Hi Brian,
> 
> Thanks for this and the other responses.
> 
> It is my understanding that any message received during the local
> processor outage and received between the processor recovered and the
> READY handshake, will not be sent to L3.  This means that they are lost
> messages.

They may or may not be sent to L3 depending on the
duration of the outage.

If the processor outage was of "long-term", the messages
are too old and MTP L3 will flush buffers (discarding
these messages) before resuming.

However, when the outage is short, L3 will simply resume
without flushing buffers and these messages in the RB
will be delivered to L3 in the normal way upon resume.

> 
> I understand from your emails that the sync will be as if they were
> ack'd, even though they are lost, i.e. not sent to L3.
> 

If you are used to thinking of an L2 that only acks
messages when they are delivered to L3, consider that
these messages _have_ been presented to L3 as a group,
and so are all acknowledged: L3 simply decides whether
to discard the group or not after they are presented.

Therefore it is not a resynchronization of sequence
numbers.  

ITU-T Rec. Q.704 (07/96) 5.6.2:

  "In the case that processor outage is of long-term,
   the remote side completes the time-controlled
   changeover procedure.  In order to (sic) avoid
   sending out old messages (see clause 8/Q.703) the
   level 2 buffers on both sides of the link should be
   flushed immediately, when the local/remote processor
   outage state terminates.  The decision whether
   processor outage is of long-term is a local thing.
   At the remote side long-term processor outage occurs
   when the time-controlled changeover timer T1 expires.
   At the local side an equivalent timer is used in
   quite the same way."

MTP L3 timer T1 represents the maximum amount of time
that traffic will be withheld (buffered) on time-
controlled changeover.  Any message that is older (has
been buffered for longer) than the duration of this
timers during processor outage is "too old" to be
placed on the network and is flushed.  This is because
messages in the same flow (SLS) may have already been
diverted under the time-controlled changeover procedure
to an alternate link and message loss is preferrable to
message missequencing:

ITU-T Rec. Q.706 (03/93) 1.2:

  b) Loss of messages

     Not more than one in 10^7 messages will be lost
     due to failure in the MTP.

  c) Message out-of-sequence

     Not more than one in 10^10 messages will be
     delivered out-of-sequence to the User Parts due to
     failure in the MTP.  This value also includes
     duplication of messages.

> Is this understanding correct?
> 
> Thanks again,
> Martin

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

Date: Thu, 26 Feb 2009 14:09:46 +0530
From: Arvind Kumar <[email-masked]>
To: [email-masked]
Subject: [Sigtran] SCTP Abort

--0016e65206206aac310463ce4bd4
Content-Type: multipart/alternative; boundary16e65206206aac2a0463ce4bd2

--0016e65206206aac2a0463ce4bd2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello Sigtran Gurus!
I am bringing Signaling Gateway Stack with Softswitch as follows:

           Signaling Gateway -------------          Softswitch
           192.168.103.160                                192.168.103.170

    Association is established then goes down, softswitch establishes the
association (four way handshake), it brings up the association, but suddenly
Signaling Gateway is aborting the association by sending SCTP ABORT. This is
happening again and again.
Surprising thing is that there is no reason in  ABORT msg.
Could you please give me any clue regarding this.

I have attached the log.

Thanks & Regards,
Arvind

--0016e65206206aac2a0463ce4bd2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Sigtran Gurus! <br>
I am bringing Signaling Gateway Stack with Softswitch as follows:<br>
<br>
<br>
<br>
<br>
���������� Signaling
Gateway
-------------���������
Softswitch <br>
����������
192.168.103.160�������������������������������
192.168.103.170<br>
<br>
��� Association is established then goes down,
softswitch establishes the association (four way handshake), it brings
up the association, but suddenly Signaling Gateway is aborting the
association by sending SCTP ABORT. This is happening again and again.<br>
Surprising thing is that there is no reason in� ABORT msg. <br>
Could you please give me any clue regarding this.<br>
<br>
I have attached the log.<br>
<br>
<br>
Thanks &amp; Regards,<br>
Arvind<br>
<br>
<br>
<br>
<br>
<br>
<br>

--0016e65206206aac2a0463ce4bd2--
--0016e65206206aac310463ce4bd4
Content-Type: text/x-log; charset=windows-1252; name="sctp.log"
Content-Disposition: attachment; filename="sctp.log"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_frn6tvli

qgtZC1kCOENHPAUDwAMAABAD7eM9AAAQAAAAAAA--0016e65206206aac310463ce4bd4--

Date: Thu, 26 Feb 2009 16:23:22 +0530
From: Ankit Kumar Sharma <[email-masked]>
To: Arvind Kumar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] SCTP Abort

--00163646d50c3947e00463d02975
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

There are junk values in sctp.log file. What is the format for this file?
What about the T-bit? is it set in abort msg?

Please see SCTP RFC for more details on T-bit.

Please look at the below link as well:
https://www.ietf.org/mailman/private/sigtran/2009-January/000155.html

Cheers,
Ankit Kumar Sharma
ARICENT
On Thu, Feb 26, 2009 at 2:09 PM, Arvind Kumar <[email-masked]>wrote:

> Hello Sigtran Gurus!
> I am bringing Signaling Gateway Stack with Softswitch as follows:
>
>
>
>
>            Signaling Gateway -------------          Softswitch
>            192.168.103.160                                192.168.103.170
>
>     Association is established then goes down, softswitch establishes the
> association (four way handshake), it brings up the association, but suddenly
> Signaling Gateway is aborting the association by sending SCTP ABORT. This is
> happening again and again.
> Surprising thing is that there is no reason in  ABORT msg.
> Could you please give me any clue regarding this.
>
> I have attached the log.
>
>
> Thanks & Regards,
> Arvind
>
>
>
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>
>

--00163646d50c3947e00463d02975
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There are junk values in sctp.log file. What is the format for this file?<div><br></div><div>What about the T-bit? is it set in abort msg?</div><div><br></div><div>Please see SCTP RFC for more details on T-bit.<br><br></div>
<div>Please look at the below link as well:</div><div><a href="https://www.ietf.org/mailman/private/sigtran/2009-January/000155.html">https://www.ietf.org/mailman/private/sigtran/2009-January/000155.html</a></div><div><br>
</div><div>Cheers,</div><div>Ankit Kumar Sharma</div><div>ARICENT<br><div class="gmail_quote">On Thu, Feb 26, 2009 at 2:09 PM, Arvind Kumar <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello Sigtran Gurus! <br>
I am bringing Signaling Gateway Stack with Softswitch as follows:<br>
<br>
<br>
<br>
<br>
���������� Signaling
Gateway
-------------���������
Softswitch <br>
����������
192.168.103.160�������������������������������
192.168.103.170<br>
<br>
��� Association is established then goes down,
softswitch establishes the association (four way handshake), it brings
up the association, but suddenly Signaling Gateway is aborting the
association by sending SCTP ABORT. This is happening again and again.<br>
Surprising thing is that there is no reason in� ABORT msg. <br>
Could you please give me any clue regarding this.<br>
<br>
I have attached the log.<br>
<br>
<br>
Thanks &amp; Regards,<br><font color="#888888">
Arvind<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font><br>_______________________________________________<br>
Sigtran mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/sigtran" target="_blank">https://www.ietf.org/mailman/listinfo/sigtran</a><br>
<br></blockquote></div><br></div>

--00163646d50c3947e00463d02975--

From: =?ISO-8859-1?Q?Michael_T�xen?= <[email-masked]>
To: Ankit Kumar Sharma <[email-masked]>
Date: Thu, 26 Feb 2009 14:16:20 +0100
Cc: Arvind Kumar <[email-masked]>, [email-masked]
Subject: Re: [Sigtran] SCTP Abort

... the log file can be read by Wireshark. I think it
is in .pcap format.

Best regards
Michael

On Feb 26, 2009, at 11:53 AM, Ankit Kumar Sharma wrote:

> There are junk values in sctp.log file. What is the format for this  
> file?
>
> What about the T-bit? is it set in abort msg?
>
> Please see SCTP RFC for more details on T-bit.
>
> Please look at the below link as well:
> https://www.ietf.org/mailman/private/sigtran/2009-January/000155.html
>
> Cheers,
> Ankit Kumar Sharma
> ARICENT
> On Thu, Feb 26, 2009 at 2:09 PM, Arvind Kumar  
> <[email-masked]> wrote:
> Hello Sigtran Gurus!
> I am bringing Signaling Gateway Stack with Softswitch as follows:
>
>
>
>
>            Signaling Gateway -------------          Softswitch
>            192.168.103.160                                 
> 192.168.103.170
>
>     Association is established then goes down, softswitch  
> establishes the association (four way handshake), it brings up the  
> association, but suddenly Signaling Gateway is aborting the  
> association by sending SCTP ABORT. This is happening again and again.
> Surprising thing is that there is no reason in  ABORT msg.
> Could you please give me any clue regarding this.
>
> I have attached the log.
>
>
> Thanks & Regards,
> Arvind
>
>
>
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

Content-class: urn:content-classes:message
Date: Thu, 26 Feb 2009 09:27:12 -0500
From: "Haresign Lincoln" <[email-masked]>
To: "Arvind Kumar" <[email-masked]>, <[email-masked]>
Subject: Re: [Sigtran] SCTP Abort

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9981E.522DB168
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The SG is aborting the connection after receiving an ASP Active (the log
is an ethereal trace as Michael indicated).  For some reason, the SG
doesn't expect an ASP active.  I've seen this on some SGs that are
expecting to receive a REG REQ before ASP Active.  Can you configure the
softswitch to do Dynamic Registration?

Regards,
Lincoln

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Arvind Kumar
Sent: Thursday, February 26, 2009 3:40 AM
To: [email-masked]
Subject: [Sigtran] SCTP Abort

Hello Sigtran Gurus! 
I am bringing Signaling Gateway Stack with Softswitch as follows:

           Signaling Gateway -------------          Softswitch 
           192.168.103.160
192.168.103.170

    Association is established then goes down, softswitch establishes
the association (four way handshake), it brings up the association, but
suddenly Signaling Gateway is aborting the association by sending SCTP
ABORT. This is happening again and again.
Surprising thing is that there is no reason in  ABORT msg. 
Could you please give me any clue regarding this.

I have attached the log.

Thanks & Regards,
Arvind

------_=_NextPart_001_01C9981E.522DB168
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The SG is aborting the connection after receiving an ASP Active
(the log is an ethereal trace as Michael indicated).&nbsp; For some reason, the SG
doesn&#8217;t expect an ASP active.&nbsp; I&#8217;ve seen this on some SGs that are expecting to
receive a REG REQ before ASP Active.&nbsp; Can you configure the softswitch to do
Dynamic Registration?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<br>
Lincoln<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>Arvind
Kumar<br>
<b>Sent:</b> Thursday, February 26, 2009 3:40 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [Sigtran] SCTP Abort<o:p></o:p></span></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'>Hello Sigtran Gurus! <br>
I am bringing Signaling Gateway Stack with Softswitch as follows:<br>
<br>
<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signaling Gateway
-------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Softswitch <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
192.168.103.160&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
192.168.103.170<br>
<br>
&nbsp;&nbsp;&nbsp; Association is established then goes down, softswitch
establishes the association (four way handshake), it brings up the association,
but suddenly Signaling Gateway is aborting the association by sending SCTP
ABORT. This is happening again and again.<br>
Surprising thing is that there is no reason in&nbsp; ABORT msg. <br>
Could you please give me any clue regarding this.<br>
<br>
I have attached the log.<br>
<br>
<br>
Thanks &amp; Regards,<br>
Arvind<br>
<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9981E.522DB168--

Date: Thu, 26 Feb 2009 08:20:01 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Arvind Kumar <[email-masked]>
Mail-Followup-To: Arvind Kumar <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] SCTP Abort
Reply-To: [email-masked]

Arvind,

Your log file shows both implementations using
Adler32 checksum.  The checksum was updated to 
CRC32c some years ago, why is it using Adler32?

That is: a conforming SCTP configuration might
be a better place to start...

--brian

Arvind Kumar wrote:                          (Thu, 26 Feb 2009 14:09:46)
> 
>    Hello Sigtran Gurus!
>    I am bringing Signaling Gateway Stack with Softswitch as follows:
>               Signaling Gateway -------------          Softswitch
>               192.168.103.160
>    192.168.103.170
>        Association is established then goes down, softswitch establishes
>    the association (four way handshake), it brings up the association,
>    but suddenly Signaling Gateway is aborting the association by sending
>    SCTP ABORT. This is happening again and again.
>    Surprising thing is that there is no reason in  ABORT msg.
>    Could you please give me any clue regarding this.
>    I have attached the log.
>    Thanks & Regards,
>    Arvind

> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

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

From: Ashish_Soregaonkar <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 26 Feb 2009 21:04:11 +0530
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Sigtran] SCTP Abort

Arvind,

Have you noticed that the SG is aborting the association in response to management messages sent on stream 1. While for similar management messages on stream 0 it replies with the expected response. Though M3UA Error is expected here as per RFC 4333 & 3332.

I agree with Brian. It would be better to check the conformance of you SCTP implementation.

HTH,
_Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian F. G. Bidulock
Sent: Thursday, February 26, 2009 8:50 PM
To: Arvind Kumar
Cc: [email-masked]
Subject: Re: [Sigtran] SCTP Abort

Arvind,

Your log file shows both implementations using
Adler32 checksum.  The checksum was updated to 
CRC32c some years ago, why is it using Adler32?

That is: a conforming SCTP configuration might
be a better place to start...

--brian

Arvind Kumar wrote:                          (Thu, 26 Feb 2009 14:09:46)
> 
>    Hello Sigtran Gurus!
>    I am bringing Signaling Gateway Stack with Softswitch as follows:
>               Signaling Gateway -------------          Softswitch
>               192.168.103.160
>    192.168.103.170
>        Association is established then goes down, softswitch establishes
>    the association (four way handshake), it brings up the association,
>    but suddenly Signaling Gateway is aborting the association by sending
>    SCTP ABORT. This is happening again and again.
>    Surprising thing is that there is no reason in  ABORT msg.
>    Could you please give me any clue regarding this.
>    I have attached the log.
>    Thanks & Regards,
>    Arvind

> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sigtran

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

From: =?ISO-8859-1?Q?Michael_T�xen?= <[email-masked]>
To: Ashish_Soregaonkar <[email-masked]>
Date: Thu, 26 Feb 2009 16:58:59 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Sigtran] SCTP Abort

Hi Ashish,

I do not see any management messages sent on stream 1...

The SCTP implementations are pretty outdated... The one
of the softswitch includes a single IP address in the
INIT chunk and it uses the Adler checksum. Not sure whether
the SCTP stack of the SG just adopts to it.

I'm not sure how good the SCTP stack of the SG is, but
the T-bit is set in all ABORTs. If the stack is correct,
it means that it has no state about the association.

This would mean that it responds to an ASPUP with an
ASPUP-ACK and removes the state at the M3UA and SCTP
layer without notifying the peer. The ABORTs are in
response to incoming packets when the state is already
gone.

Best regards
Michael

On Feb 26, 2009, at 4:34 PM, Ashish_Soregaonkar wrote:

>
> Arvind,
>
> Have you noticed that the SG is aborting the association in response  
> to management messages sent on stream 1. While for similar  
> management messages on stream 0 it replies with the expected  
> response. Though M3UA Error is expected here as per RFC 4333 & 3332.
>
> I agree with Brian. It would be better to check the conformance of  
> you SCTP implementation.
>
> HTH,
> _Ashish
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Brian F. G. Bidulock
> Sent: Thursday, February 26, 2009 8:50 PM
> To: Arvind Kumar
> Cc: [email-masked]
> Subject: Re: [Sigtran] SCTP Abort
>
> Arvind,
>
> Your log file shows both implementations using
> Adler32 checksum.  The checksum was updated to
> CRC32c some years ago, why is it using Adler32?
>
> That is: a conforming SCTP configuration might
> be a better place to start...
>
> --brian
>
> Arvind Kumar wrote:                          (Thu, 26 Feb 2009  
> 14:09:46)
>>
>>   Hello Sigtran Gurus!
>>   I am bringing Signaling Gateway Stack with Softswitch as follows:
>>              Signaling Gateway -------------          Softswitch
>>              192.168.103.160
>>   192.168.103.170
>>       Association is established then goes down, softswitch  
>> establishes
>>   the association (four way handshake), it brings up the association,
>>   but suddenly Signaling Gateway is aborting the association by  
>> sending
>>   SCTP ABORT. This is happening again and again.
>>   Surprising thing is that there is no reason in  ABORT msg.
>>   Could you please give me any clue regarding this.
>>   I have attached the log.
>>   Thanks & Regards,
>>   Arvind
>
>
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sigtran
>
>
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION  
> intended solely
> for the use of the addressee(s). If you are not the intended  
> recipient, please
> notify the sender by e-mail and delete the original message.  
> Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any  
> other person and
> any such actions are unlawful. This e-mail may contain viruses.  
> Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable  
> for any damage
> you may sustain as a result of any virus in this e-mail. You should  
> carry out your
> own virus checks before opening the e-mail or attachment. Infosys  
> reserves the
> right to monitor and review the content of all messages sent to or  
> from this e-mail
> address. Messages sent to or from this e-mail address may be stored  
> on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>

From: Ashish_Soregaonkar <[email-masked]>
To: =?iso-8859-1?Q?Michael_T�xen?= <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 26 Feb 2009 21:37:40 +0530
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Sigtran] SCTP Abort

Oh yes. My bad. I should have said maintenance message ASPUP. 

You can look at the difference between packet 2 & 8 and similarity between 8 & 11. 
2- ASPUP - stream 1 - Abort
8- ASPUP - stream 0 - no abort
11 - ASPAC - stream 1 - abort

Thanks,
_Ashish

-----Original Message-----
From: Michael T�xen [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 9:29 PM
To: Ashish_Soregaonkar
Cc: [email-masked]
Subject: Re: [Sigtran] SCTP Abort

Hi Ashish,

I do not see any management messages sent on stream 1...

The SCTP implementations are pretty outdated... The one
of the softswitch includes a single IP address in the
INIT chunk and it uses the Adler checksum. Not sure whether
the SCTP stack of the SG just adopts to it.

I'm not sure how good the SCTP stack of the SG is, but
the T-bit is set in all ABORTs. If the stack is correct,
it means that it has no state about the association.

This would mean that it responds to an ASPUP with an
ASPUP-ACK and removes the state at the M3UA and SCTP
layer without notifying the peer. The ABORTs are in
response to incoming packets when the state is already
gone.

Best regards
Michael

On Feb 26, 2009, at 4:34 PM, Ashish_Soregaonkar wrote:

>
> Arvind,
>
> Have you noticed that the SG is aborting the association in response  
> to management messages sent on stream 1. While for similar  
> management messages on stream 0 it replies with the expected  
> response. Though M3UA Error is expected here as per RFC 4333 & 3332.
>
> I agree with Brian. It would be better to check the conformance of  
> you SCTP implementation.
>
> HTH,
> _Ashish
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Brian F. G. Bidulock
> Sent: Thursday, February 26, 2009 8:50 PM
> To: Arvind Kumar
> Cc: [email-masked]
> Subject: Re: [Sigtran] SCTP Abort
>
> Arvind,
>
> Your log file shows both implementations using
> Adler32 checksum.  The checksum was updated to
> CRC32c some years ago, why is it using Adler32?
>
> That is: a conforming SCTP configuration might
> be a better place to start...
>
> --brian
>
> Arvind Kumar wrote:                          (Thu, 26 Feb 2009  
> 14:09:46)
>>
>>   Hello Sigtran Gurus!
>>   I am bringing Signaling Gateway Stack with Softswitch as follows:
>>              Signaling Gateway -------------          Softswitch
>>              192.168.103.160
>>   192.168.103.170
>>       Association is established then goes down, softswitch  
>> establishes
>>   the association (four way handshake), it brings up the association,
>>   but suddenly Signaling Gateway is aborting the association by  
>> sending
>>   SCTP ABORT. This is happening again and again.
>>   Surprising thing is that there is no reason in  ABORT msg.
>>   Could you please give me any clue regarding this.
>>   I have attached the log.
>>   Thanks & Regards,
>>   Arvind
>
>
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sigtran
>
>
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION  
> intended solely
> for the use of the addressee(s). If you are not the intended  
> recipient, please
> notify the sender by e-mail and delete the original message.  
> Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any  
> other person and
> any such actions are unlawful. This e-mail may contain viruses.  
> Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable  
> for any damage
> you may sustain as a result of any virus in this e-mail. You should  
> carry out your
> own virus checks before opening the e-mail or attachment. Infosys  
> reserves the
> right to monitor and review the content of all messages sent to or  
> from this e-mail
> address. Messages sent to or from this e-mail address may be stored  
> on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>

From: =?ISO-8859-1?Q?Michael_T�xen?= <[email-masked]>
To: Ashish_Soregaonkar <[email-masked]>
Date: Thu, 26 Feb 2009 18:41:05 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Sigtran] SCTP Abort

On Feb 26, 2009, at 5:07 PM, Ashish_Soregaonkar wrote:

> Oh yes. My bad. I should have said maintenance message ASPUP.
>
> You can look at the difference between packet 2 & 8 and similarity  
> between 8 & 11.
> 2- ASPUP - stream 1 - Abort
It is stream 0, stream sequence number 1.
I guess this is an M3UA level retransmission...
>
> 8- ASPUP - stream 0 - no abort
It is stream 0, stream sequence number 0.
>
> 11 - ASPAC - stream 1 - abort
It is stream 0, stream sequence number 1.

At least this is what Wireshark tells me...
>
>
> Thanks,
> _Ashish
>
> -----Original Message-----
> From: Michael T�xen [mailto:[email-masked]]
> Sent: Thursday, February 26, 2009 9:29 PM
> To: Ashish_Soregaonkar
> Cc: [email-masked]
> Subject: Re: [Sigtran] SCTP Abort
>
> Hi Ashish,
>
> I do not see any management messages sent on stream 1...
>
> The SCTP implementations are pretty outdated... The one
> of the softswitch includes a single IP address in the
> INIT chunk and it uses the Adler checksum. Not sure whether
> the SCTP stack of the SG just adopts to it.
>
> I'm not sure how good the SCTP stack of the SG is, but
> the T-bit is set in all ABORTs. If the stack is correct,
> it means that it has no state about the association.
>
> This would mean that it responds to an ASPUP with an
> ASPUP-ACK and removes the state at the M3UA and SCTP
> layer without notifying the peer. The ABORTs are in
> response to incoming packets when the state is already
> gone.
>
> Best regards
> Michael
>
> On Feb 26, 2009, at 4:34 PM, Ashish_Soregaonkar wrote:
>
>>
>> Arvind,
>>
>> Have you noticed that the SG is aborting the association in response
>> to management messages sent on stream 1. While for similar
>> management messages on stream 0 it replies with the expected
>> response. Though M3UA Error is expected here as per RFC 4333 & 3332.
>>
>> I agree with Brian. It would be better to check the conformance of
>> you SCTP implementation.
>>
>> HTH,
>> _Ashish
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Brian F. G. Bidulock
>> Sent: Thursday, February 26, 2009 8:50 PM
>> To: Arvind Kumar
>> Cc: [email-masked]
>> Subject: Re: [Sigtran] SCTP Abort
>>
>> Arvind,
>>
>> Your log file shows both implementations using
>> Adler32 checksum.  The checksum was updated to
>> CRC32c some years ago, why is it using Adler32?
>>
>> That is: a conforming SCTP configuration might
>> be a better place to start...
>>
>> --brian
>>
>> Arvind Kumar wrote:                          (Thu, 26 Feb 2009
>> 14:09:46)
>>>
>>>  Hello Sigtran Gurus!
>>>  I am bringing Signaling Gateway Stack with Softswitch as follows:
>>>             Signaling Gateway -------------          Softswitch
>>>             192.168.103.160
>>>  192.168.103.170
>>>      Association is established then goes down, softswitch
>>> establishes
>>>  the association (four way handshake), it brings up the association,
>>>  but suddenly Signaling Gateway is aborting the association by
>>> sending
>>>  SCTP ABORT. This is happening again and again.
>>>  Surprising thing is that there is no reason in  ABORT msg.
>>>  Could you please give me any clue regarding this.
>>>  I have attached the log.
>>>  Thanks & Regards,
>>>  Arvind
>>
>>
>>> _______________________________________________
>>> Sigtran mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>>
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>> **************** CAUTION - Disclaimer *****************
>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
>> intended solely
>> for the use of the addressee(s). If you are not the intended
>> recipient, please
>> notify the sender by e-mail and delete the original message.
>> Further, you are not
>> to copy, disclose, or distribute this e-mail or its contents to any
>> other person and
>> any such actions are unlawful. This e-mail may contain viruses.
>> Infosys has taken
>> every reasonable precaution to minimize this risk, but is not liable
>> for any damage
>> you may sustain as a result of any virus in this e-mail. You should
>> carry out your
>> own virus checks before opening the e-mail or attachment. Infosys
>> reserves the
>> right to monitor and review the content of all messages sent to or
>> from this e-mail
>> address. Messages sent to or from this e-mail address may be stored
>> on the
>> Infosys e-mail system.
>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>
>

Date: Fri, 27 Feb 2009 09:29:48 +0530
From: Arvind Kumar <[email-masked]>
To: [email-masked], Arvind Kumar <[email-masked]>, [email-masked]
Subject: Re: [Sigtran] SCTP Abort

--001485ec101809540c0463de807b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello!
Thanks for your response.
If i am using some another machine, my SG with Softswitch is working fine,
adler32 works fine, but on this purticular machine even crc32 does not work.
I do not think it is issue at M3UA, like SG expecting reg req (I have
configured static registration both the side).

The problem is repeatable on this particular machine.

Thanks & Regards,
Arvind

On 2/26/09, Brian F. G. Bidulock <[email-masked]> wrote:
>
> Arvind,
>
> Your log file shows both implementations using
> Adler32 checksum.  The checksum was updated to
> CRC32c some years ago, why is it using Adler32?
>
> That is: a conforming SCTP configuration might
> be a better place to start...
>
> --brian
>
> Arvind Kumar wrote:                          (Thu, 26 Feb 2009 14:09:46)
>
> >
> >    Hello Sigtran Gurus!
> >    I am bringing Signaling Gateway Stack with Softswitch as follows:
> >               Signaling Gateway -------------          Softswitch
> >               192.168.103.160
> >    192.168.103.170
> >        Association is established then goes down, softswitch establishes
> >    the association (four way handshake), it brings up the association,
> >    but suddenly Signaling Gateway is aborting the association by sending
> >    SCTP ABORT. This is happening again and again.
> >    Surprising thing is that there is no reason in  ABORT msg.
> >    Could you please give me any clue regarding this.
> >    I have attached the log.
> >    Thanks & Regards,
> >    Arvind
>
>
>
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sigtran
>
>
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>

--001485ec101809540c0463de807b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello!<br>
Thanks for your response.<br>
If i am using some another machine, my SG with Softswitch is working
fine, adler32 works fine, but on this purticular machine even crc32
does not work.<br>
I do not think it is issue at M3UA, like SG expecting reg req (I have configured static registration both the side).<br>
<br>
The problem is repeatable on this particular machine.<br>
<br>
<br>
Thanks &amp; Regards,<br>
Arvind<br>
<br>
<br><br><div><span class="gmail_quote">On 2/26/09, <b class="gmail_sendername">Brian F. G. Bidulock</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Arvind,<br> <br> Your log file shows both implementations using<br> Adler32 checksum.��The checksum was updated to<br> CRC32c some years ago, why is it using Adler32?<br> <br> That is: a conforming SCTP configuration might<br>
 be a better place to start...<br> <br> --brian<br> <br>
Arvind Kumar
wrote:��������������������������(Thu,
26 Feb 2009 14:09:46)<br> <br>&gt;<br> &gt;����Hello Sigtran Gurus!<br> &gt;����I am bringing Signaling Gateway Stack with Softswitch as follows:<br>
&gt;��������������
Signaling Gateway
-------------����������Softswitch<br> &gt;�������������� 192.168.103.160<br> &gt;����192.168.103.170<br> &gt;��������Association is established then goes down, softswitch establishes<br> &gt;����the association (four way handshake), it brings up the association,<br>
 &gt;����but suddenly Signaling Gateway is aborting the association by sending<br> &gt;����SCTP ABORT. This is happening again and again.<br> &gt;����Surprising thing is that there is no reason in��ABORT msg.<br> &gt;����Could you please give me any clue regarding this.<br>
 &gt;����I have attached the log.<br> &gt;����Thanks &amp; Regards,<br> &gt;����Arvind<br> <br> <br> <br>&gt; _______________________________________________<br> &gt; Sigtran mailing list<br> &gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
 &gt; <a href="https://www.ietf.org/mailman/listinfo/sigtran">https://www.ietf.org/mailman/listinfo/sigtran</a><br> <br> <br> <br>--<br> Brian F. G. Bidulock<br> <a href="mailto:[email-masked]">[email-masked]</a><br>
 <a href="http://www.openss7.org/">http://www.openss7.org/</a><br> </blockquote></div><br>

--001485ec101809540c0463de807b--

From: Ashish_Soregaonkar <[email-masked]>
To: =?iso-8859-1?Q?Michael_T�xen?= <[email-masked]>
Date: Fri, 27 Feb 2009 09:53:11 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Sigtran] SCTP Abort

Apologies.. I got it completely wrong.

-----Original Message-----
From: Michael T�xen [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 11:11 PM
To: Ashish_Soregaonkar
Cc: [email-masked]
Subject: Re: [Sigtran] SCTP Abort

On Feb 26, 2009, at 5:07 PM, Ashish_Soregaonkar wrote:

> Oh yes. My bad. I should have said maintenance message ASPUP.
>
> You can look at the difference between packet 2 & 8 and similarity  
> between 8 & 11.
> 2- ASPUP - stream 1 - Abort
It is stream 0, stream sequence number 1.
I guess this is an M3UA level retransmission...
>
> 8- ASPUP - stream 0 - no abort
It is stream 0, stream sequence number 0.
>
> 11 - ASPAC - stream 1 - abort
It is stream 0, stream sequence number 1.

At least this is what Wireshark tells me...
>
>
> Thanks,
> _Ashish
>
> -----Original Message-----
> From: Michael T�xen [mailto:[email-masked]]
> Sent: Thursday, February 26, 2009 9:29 PM
> To: Ashish_Soregaonkar
> Cc: [email-masked]
> Subject: Re: [Sigtran] SCTP Abort
>
> Hi Ashish,
>
> I do not see any management messages sent on stream 1...
>
> The SCTP implementations are pretty outdated... The one
> of the softswitch includes a single IP address in the
> INIT chunk and it uses the Adler checksum. Not sure whether
> the SCTP stack of the SG just adopts to it.
>
> I'm not sure how good the SCTP stack of the SG is, but
> the T-bit is set in all ABORTs. If the stack is correct,
> it means that it has no state about the association.
>
> This would mean that it responds to an ASPUP with an
> ASPUP-ACK and removes the state at the M3UA and SCTP
> layer without notifying the peer. The ABORTs are in
> response to incoming packets when the state is already
> gone.
>
> Best regards
> Michael
>
> On Feb 26, 2009, at 4:34 PM, Ashish_Soregaonkar wrote:
>
>>
>> Arvind,
>>
>> Have you noticed that the SG is aborting the association in response
>> to management messages sent on stream 1. While for similar
>> management messages on stream 0 it replies with the expected
>> response. Though M3UA Error is expected here as per RFC 4333 & 3332.
>>
>> I agree with Brian. It would be better to check the conformance of
>> you SCTP implementation.
>>
>> HTH,
>> _Ashish
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Brian F. G. Bidulock
>> Sent: Thursday, February 26, 2009 8:50 PM
>> To: Arvind Kumar
>> Cc: [email-masked]
>> Subject: Re: [Sigtran] SCTP Abort
>>
>> Arvind,
>>
>> Your log file shows both implementations using
>> Adler32 checksum.  The checksum was updated to
>> CRC32c some years ago, why is it using Adler32?
>>
>> That is: a conforming SCTP configuration might
>> be a better place to start...
>>
>> --brian
>>
>> Arvind Kumar wrote:                          (Thu, 26 Feb 2009
>> 14:09:46)
>>>
>>>  Hello Sigtran Gurus!
>>>  I am bringing Signaling Gateway Stack with Softswitch as follows:
>>>             Signaling Gateway -------------          Softswitch
>>>             192.168.103.160
>>>  192.168.103.170
>>>      Association is established then goes down, softswitch
>>> establishes
>>>  the association (four way handshake), it brings up the association,
>>>  but suddenly Signaling Gateway is aborting the association by
>>> sending
>>>  SCTP ABORT. This is happening again and again.
>>>  Surprising thing is that there is no reason in  ABORT msg.
>>>  Could you please give me any clue regarding this.
>>>  I have attached the log.
>>>  Thanks & Regards,
>>>  Arvind
>>
>>
>>> _______________________________________________
>>> Sigtran mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>>
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>> **************** CAUTION - Disclaimer *****************
>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
>> intended solely
>> for the use of the addressee(s). If you are not the intended
>> recipient, please
>> notify the sender by e-mail and delete the original message.
>> Further, you are not
>> to copy, disclose, or distribute this e-mail or its contents to any
>> other person and
>> any such actions are unlawful. This e-mail may contain viruses.
>> Infosys has taken
>> every reasonable precaution to minimize this risk, but is not liable
>> for any damage
>> you may sustain as a result of any virus in this e-mail. You should
>> carry out your
>> own virus checks before opening the e-mail or attachment. Infosys
>> reserves the
>> right to monitor and review the content of all messages sent to or
>> from this e-mail
>> address. Messages sent to or from this e-mail address may be stored
>> on the
>> Infosys e-mail system.
>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>
>

Date: Thu, 26 Feb 2009 22:34:19 -0700
From: "Brian F. G. Bidulock" <[email-masked]>
To: Arvind Kumar <[email-masked]>
Mail-Followup-To: Arvind Kumar <[email-masked]>, [email-masked]
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sigtran] SCTP Abort
Reply-To: [email-masked]

Arvind,

If you have a firewall/router in between the boxes, or,
more likely, the box sending the SCTP ABORT is also
running a firewall, that could explain the SCTP ABORT
with the T-bit set.  The ABORT might be comming from the
firewall that allows the association to be established
but knocks down M3UA associations (PPI 3) from this
prohibited IP address/port on its first attempt to
transfer an M3UA message.

Could explain why other boxes work fine.

The one successful ASPUP can be explained by the speed
between the COOKIE_ACK and ASPUP in that exchanged
(a stateful firewall, or coordinated route pari, might
not have acheived state on the COOKIE_ACK before the
ASPUP arrived, allowing it to pass).

Nevertheless, check for SCTP-aware firewalls.

--brian

That would be one explanations

Arvind Kumar wrote:                          (Fri, 27 Feb 2009 09:29:48)
> 
>    Hello!
>    Thanks for your response.
>    If i am using some another machine, my SG with Softswitch is working
>    fine, adler32 works fine, but on this purticular machine even crc32
>    does not work.
>    I do not think it is issue at M3UA, like SG expecting reg req (I have
>    configured static registration both the side).
>    The problem is repeatable on this particular machine.
>    Thanks & Regards,
>    Arvind
> 
>    On 2/26/09, Brian F. G. Bidulock <[1][email-masked]> wrote:
> 
>      Arvind,
>      Your log file shows both implementations using
>      Adler32 checksum.  The checksum was updated to
>      CRC32c some years ago, why is it using Adler32?
>      That is: a conforming SCTP configuration might
>      be a better place to start...
>      --brian
>      Arvind Kumar wrote:                          (Thu, 26 Feb 2009
>      14:09:46)
>      >
>      >    Hello Sigtran Gurus!
>      >    I am bringing Signaling Gateway Stack with Softswitch as
>      follows:
>      >               Signaling Gateway -------------          Softswitch
>      >               192.168.103.160
>      >    192.168.103.170
>      >        Association is established then goes down, softswitch
>      establishes
>      >    the association (four way handshake), it brings up the
>      association,
>      >    but suddenly Signaling Gateway is aborting the association by
>      sending
>      >    SCTP ABORT. This is happening again and again.
>      >    Surprising thing is that there is no reason in  ABORT msg.
>      >    Could you please give me any clue regarding this.
>      >    I have attached the log.
>      >    Thanks & Regards,
>      >    Arvind
>      > _______________________________________________
>      > Sigtran mailing list
>      > [2][email-masked]
>      > [3]https://www.ietf.org/mailman/listinfo/sigtran
>      --
>      Brian F. G. Bidulock
>      [4][email-masked]
>      [5]http://www.openss7.org/
> 
> References
> 
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]
>    3. https://www.ietf.org/mailman/listinfo/sigtran
>    4. mailto:[email-masked]
>    5. http://www.openss7.org/

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