Subject: Re: [Sigtran] [M3UA] Action on Receipt of ERROR (Sporton, Simon, VF-Group)

From: mosbah abdelkader <[email-masked]>
Date: Wed, 16 Mar 2011 20:56:08 +0100

Hi Simon,

I have been playing with M3UA layer and SCTP for about one year and I want
to clarify you my point of view regarding your question.

We provide an M3UA layer integrated with LK-SCTP. It offers an M3UA API, an
ASP application and an SGP application.

We have integrated this layer with Dialogic SS7 stacks for a french customer
and it is deployed in a SIGTRAN connection with a very big mobile operator
in France.

We offer to the programmer of an M3UA USER, for example: an ASP or SGP or
IPSP, the possibility to handle all types of messages among them the ERROR
type.

The RFC4446 provides some cases where ERROR message have to be or must be
sent. For handling, it depends on the context and the reason of the ERROR
message. Some of the cases can be handled automatically by the stack and the
others can be provided to the user (ASP or SGP programmer) to handle them
properly.

If you are interested in our work, please send a private mail.

Thank you.

--
BR

Abdelkader Mosbah.

---

From: arif khan <[email-masked]>
Date: Thu, 17 Mar 2011 08:16:21 +0000

Hi All,

Error handling in the any software including sigtran or other telecom
stack/applications layers are not robust or correctly implemented and
thats the reason it is vendor dependent or we can categorise it as
implementation dependent.

But yes the RFC should have exact guidlines for the error msgs also to
avoid effort in investigation and troubleshooting the problems when it
comes into the live NW.

Poor error handling and missing guidlines in RFC both gives
programmers to put work-around and otherway solution.

Yes Simon....I understand your concern with VF legacy HLR some years
back....and I had gone through the similar chaos when VF node and othe
NW vendor interop happned.

Vendors are focusing more on feartures and performation but they
neverthing about how the crash,error ,memory and tracing are provided.

Regards
-arif

---

From: arif khan <[email-masked]>
Date: Thu, 17 Mar 2011 08:26:44 +0000

Hi Mosbah,,

Good error control is suggested to design the error handling keeping
in mind to" min downtime for the sigtran link connection and
congestion avoidance".

Protocols are in place but atleast any one endpoint should have quick
detection and ability to change thier state and it should also have an
algorthim to force the peer also to change their state to behave
correctly.
Error loging is also helpful for the further improvement on the basis
of past learning but please do not accept generic error loging or
tracing......its quite dangerous.

Regards
-arif

---

From: mosbah abdelkader <[email-masked]>
Date: Thu, 17 Mar 2011 09:41:49 +0100

Hi Arif,

Thank you for your reply.

Your comments are very interesting. I understand the need of a reliable
sigtran link.

The importance of our implementation is that: we have the full control of
the implementation so we can do customization depending on the situation.
Our stack (with SCTP) can be integrated easily in a distributed SS7 stack as
an independant process.

BR
Abdelkader Mosbah.

---

From: "Sporton, Simon, VF-Group" <[email-masked]>
Date: Thu, 17 Mar 2011 21:46:51 +0100

Hi Arif,

Thanks for your reply... as you will see in my previous mail to Michael,
it's the inconsistency of implementation that surprises me... In the
case we found there is a clear difference between SGP and ASP (not a
Vodafone HLR by the way)... the difference is so vast it would appear to
be a difference in error handling philosophy between the two vendors.

Any guidance the RFC could give for this may bring the implementation
closer together.

Regards

Simon

-----Original Message-----
From: arif khan [mailto:[email-masked]] 
Sent: 17 March 2011 09:16
To: mosbah abdelkader
Cc: Sporton, Simon, VF-Group; [email-masked]
Subject: Re: [Sigtran] [M3UA] Action on Receipt of ERROR (Sporton,
Simon, VF-Group)

Hi All,

Poor error handling and missing guidlines in RFC both gives programmers
to put work-around and otherway solution.

Regards
-arif

---

From: arif khan <[email-masked]>
Date: Thu, 17 Mar 2011 20:57:55 +0000

Hi Simon,

Yes...RFC should include error related management and clear definition
of the error scenarios and causes also....

Regards
-arif