Re: [M3UA] Action on Receipt of ERROR

Michael Tüxen <[email protected]> Thu, 17 Mar 2011 22:29:28 +0100
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
On Mar 17, 2011, at 9:54 PM, Sporton, Simon, VF-Group wrote:

> Hi David,
> 
> In our case the SGP included diagnostic information in it ERROR, so the
> ASP could have determined that the problem was related to a DAUD it had
> previously sent, but unfortunately the ASP doesn't look at diagnostic
> info! 
... which is hard to do since the diagnostic information is not defined
in a way that it can be processed automatically...

Best regards
Michael
> 
> To be honest, your pragmatic solution would probably be good enough...
> it's the logic that each node needs to determine there is a miss-match
> in the state machines and re-connect to get them in sync again.
> 
> Simon
> 
> -----Original Message-----
> From: David Laight [mailto:[email protected]] 
> Sent: 17 March 2011 10:21
> To: Sporton, Simon, VF-Group; [email protected]
> Subject: RE: [Sigtran] [M3UA] Action on Receipt of ERROR
> 
> 
>> We have been looking at various vendors implementation of M3UA and 
>> seen a significant divergence in the handling of M3UA ERROR 
>> messages.....
> 
> The problem I had with the M3UA MGMT ERROR messages is that they are
> completely 'out of band' with any requests.
> We have code to detect 'Mangement blocking' as a reponse to an activate
> request (an explicit negative ack to the activate would be much better),
> but otherwise assume the MGMT errors are likely to be the result of M3UA
> protocol mismatches. However we can't be certain of this so take no
> immediate action.
> If the remote system has rejected an important message then a guard
> timer expires and we disconnect - since the far end clearly is very
> confused - then retry later.
> 
> This may be a rather pragmatic solution....
> 
> 	David
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran
>