Re: descriptor order and error descriptors

Hello Troy and Kevin,

I had always assumed that you would reply back in the same descriptor order as 
what had been requested. I believe this is what we intended. As has been pointed 
out the ErrorDescriptor concept doesn't work without this assumption.

It seems this is another one of those "undocumented" working assumptions in 
H.248. I guess we should add something explicitely to Section 7.1 and fix the 
examples.

Regards, Christian

Kevin Boyle wrote:

> Wouldn't the command processing stop at the first error?
> 
> I believe the intent is to enforce order, since that is how the sender can
> align where errors occurred with the command.  Christian may be able to
> provide more detail on the history of how this was intended to work...
> 
> Whatever we decide, we should document the fix into the Implementors' Guides
> for V1 and V2, and fix the text in V3.
> 
> Kevin 
> 
> -----Original Message-----
> From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
> Troy Cauble
> Sent: Wednesday, December 01, 2004 12:46 PM
> To: megaco <at> ietf.org
> Subject: [Megaco] descriptor order and error descriptors
> 
> 
> Hi,
> 
> I recently ran into the exchange below.
> I think it points out a weakness in the protocol w.r.t. associating
> descriptor level errors with the appropriate descriptor.
> 
> I could find nothing in the docs that say a response's descriptors should be
> in the same order as the request's descriptors.
> 
> I could find nothing in the docs that say the AuditValue's response's
> descriptors should be in the same order as the request tokens.  In fact, the
> V2 doc has examples of AuditValue returning descriptors in an order other
> than the request tokens.
> 
> I didn't check to see if there are similar issues in the other lists that an
> errorDescriptor can be used in.  It seems likely though.
> 
> Forcing the order to be maintained and using that for context is ugly, IMO.
> But it's probably the minimal change solution.
> The real problem is lack of info in the errorDescriptor.
> (Relying on the text of the error descriptor field would also be a bad idea,
> IMO.)
> 
> -troy
> 
> 
> 
> 
> MEGACO/1 [135.112.125.109]:55555
>     Transaction = 50007 {
>        Context = - {AuditValue = aaln/2 {
>           Audit{ Packages, Statistics , DigitMap, Signals, Events, Media
>     }}}}
> 
> MEGACO/1 [135.112.125.214]
> Reply = 50007 {
>    Context = - {
>      AuditValue = aaln/2 {
>        Media {
>          TerminationState {
>            Buffer = OFF},
>          Stream = 1 {
>            LocalControl {
> 
>            }
>          }
>        },
>        Events = 2222 {
>          al/of
>        },
>        Error = 447 { "Descriptor not legal in this command" },
>        Error = 447 { "Descriptor not legal in this command" },
>        Packages {
>          g-1,
>          tonegen-1,
>          tonedet-1,
>          dg-1,
>          dd-1,
>          cg-1,
>          cd-1,
>          al-1,
>          ct-1,
>          rtp-1,
>          tdmc-1,
>          ftmd-1,
>          ctyp-1,
>          an-1,
>          bau-1,
>          aau-1,
>          xal-1
> 
>        },
>        Error = 501 { "Not implemented" }
>      }
>    }
> }
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>