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 >