Re: [MEGACO] descriptors order and error descriptors

Hello Bruno,

As Kevin said it slipped under the radar. I always try to input an IG 
update contribution to each Q.3/16 meeting with items identified on the 
megaco list. I'll make sure it gets added to the next one.

Thanks.

Regards, Christian

[email protected] wrote:
> Hi Christian, Kevin,
>  
> I was looking for information on the order of descriptors in H.248 
> replies and found the email exchange below. Looking to the latest 
> H.248.1 version, it seems that nothing was added about this issue 
> since then. Is there any reason for that? Are there any plans to 
> address this in an Implementors Guide?
>  
> Best Regards
> Bruno
>  
>  
> ** 
> ** 
>
>
>   ------------------------------------------------------------------------
>
>     * /To/: Kevin Boyle <kboyle at nortelnetworks.com
>       <mailto:[email protected]>>
>     * /Subject/: Re: [Megaco] descriptor order and error descriptors
>     * /From/: Christian Groves <christian.groves at ericsson.com
>       <mailto:[email protected]>>
>     * /Date/: Fri, 03 Dec 2004 11:31:00 +1100
>     * /Cc/: megaco at ietf.org <mailto:[email protected]>, Troy
>       Cauble <troy at bell-labs.com <mailto:[email protected]>>
>     * /In-reply-to/:
>       <B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2
>       <http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html>>
>
>     * /List-help/: <mailto:[email protected]?subject=help>
>     * /List-id/: Media Gateway Control <megaco.ietf.org>
>     * /List-post/: <mailto:[email protected]>
>     * /List-subscribe/:
>       <https://www1.ietf.org/mailman/listinfo/megaco>,
>       <mailto:[email protected]?subject=subscribe>
>     * /List-unsubscribe/:
>       <https://www1.ietf.org/mailman/listinfo/megaco>,
>       <mailto:[email protected]?subject=unsubscribe>
>     * /References/: <B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2
>       <http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html>>
>
>     * /Sender/: megaco-bounces at ietf.org
>       <mailto:[email protected]>
>     * /User-agent/: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
>       rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
>
> ------------------------------------------------------------------------
> 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" }
>          }
>        }
>     }
>