Re: [MEGACO] descriptors order and error descriptors

Hi Bruno!
 
I agree that something should be added, though I haven't been attending SG16
for the last couple of years.  I am sure the exclusion of this text is
merely an oversight, and is something that may be able to be added when SG16
meets in a few weeks.
 
Kevin


  _____  

From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, December 16, 2008 8:22 AM
To: [email protected]; [email protected]; [email protected]
Subject: [Megaco] [MEGACO] descriptors order and error descriptors


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 < <mailto:[email protected]> kboyle at
nortelnetworks.com> 

*	Subject: Re: [Megaco] descriptor order and error descriptors 

*	From: Christian Groves < <mailto:[email protected]>
christian.groves at ericsson.com> 

*	Date: Fri, 03 Dec 2004 11:31:00 +1100 

*	Cc:  <mailto:[email protected]> megaco at ietf.org, Troy Cauble <
<mailto:[email protected]> troy at bell-labs.com> 

*	In-reply-to: <
<http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html>
B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2> 

*	List-help: < <mailto:[email protected]?subject=help>
mailto:[email protected]?subject=help> 

*	List-id: Media Gateway Control <megaco.ietf.org> 

*	List-post: < <mailto:[email protected]> mailto:[email protected]> 

*	List-subscribe: < <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco>, <
<mailto:[email protected]?subject=subscribe>
mailto:[email protected]?subject=subscribe> 

*	List-unsubscribe: < <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco>, <
<mailto:[email protected]?subject=unsubscribe>
mailto:[email protected]?subject=unsubscribe> 

*	References: <
<http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html>
B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2> 

*	Sender:  <mailto:[email protected]> megaco-bounces at
ietf.org 

*	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>
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
[email protected]
https://www.ietf.org/mailman/listinfo/megaco