How many Error-Descriptors in TerminationAudit?
Wed Jul 21 14:47:09 CEST 2004
The comment is from RFC2885 (megaco 0.8) and is not valid anymore.
It will be removed in the next release.
Stefan Fritzsche writes:
> Hello Mailing-List,
> In the YECC-Definition of the Megaco-Parser is a comment stating that
> a TerminationAudit might contain more than one Error-Descriptors.
> > terminationAudit -> auditReturnParameter auditReturnParameterList
> > ...
> > %% at-most-once except errorDescriptor
> > auditReturnParameter -> mediaDescriptor
> > auditReturnParameter -> modemDescriptor
> > auditReturnParameter -> muxDescriptor
> > auditReturnParameter -> eventsDescriptor
> > auditReturnParameter -> signalsDescriptor
> > auditReturnParameter -> digitMapDescriptor
> > auditReturnParameter -> observedEventsDescriptor
> > auditReturnParameter -> eventBufferDescriptor
> > auditReturnParameter -> statisticsDescriptor
> > auditReturnParameter -> packagesDescriptor
> > auditReturnParameter -> errorDescriptor
> > auditReturnParameter -> auditReturnItem
> I did not find this "at-most ..."-comment in the RFC nor in
> the H.248-v2-Draft. I didn't even find an explanation why a
> TerminationAudit might contain more than one Error-Descriptor.
> Does this really make a difference in processing a Command-Reply?
> If there can be more than one, am I right that the order of
> Error-Descriptors is important to associate each Error to
> the Command-Parameter that generated the Error?
> Can anybody give an example (-call-flow), where this can
> Thanks in advance,
> Stefan Fritzsche
This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited.
If you believe this message has been sent to you in error, please notify
the sender by replying to this transmission and delete the message without
disclosing it. Thank you.
E-mail including attachments is susceptible to data corruption, interruption,
unauthorized amendment, tampering and viruses, and we only send and receive
e-mails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences thereof.
More information about the erlang-questions