Subject: [Megaco] [MEGACO] descriptors order and error descriptors

From: <[email-masked]>
Date: Tue, 16 Dec 2008 14:21:49 +0100

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-masked]> > 
*	Subject: Re: [Megaco] descriptor order and error descriptors 
*	From: Christian Groves <christian.groves at ericsson.com
<mailto:[email-masked]> > 
*	Date: Fri, 03 Dec 2004 11:31:00 +1100 
*	Cc: megaco at ietf.org <mailto:[email-masked]> , Troy
Cauble <troy at bell-labs.com <mailto:[email-masked]> > 
*	In-reply-to: <B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2
<http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html> > 
*	List-help: <mailto:[email-masked]?subject=help
<mailto:[email-masked]?subject=help> > 
*	List-id: Media Gateway Control <megaco.ietf.org> 
*	List-post: <mailto:[email-masked] <mailto:[email-masked]> > 
*	List-subscribe: <https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> >,
<mailto:[email-masked]?subject=subscribe
<mailto:[email-masked]?subject=subscribe> > 
*	List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> >,
<mailto:[email-masked]?subject=unsubscribe
<mailto:[email-masked]?subject=unsubscribe> > 
*	References: <B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2
<http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html> > 
*	Sender: megaco-bounces at ietf.org
<mailto:[email-masked]>  
*	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-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: Kevin Boyle <[email-masked]>
Date: Tue, 16 Dec 2008 09:22:41 -0500

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-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, December 16, 2008 8:22 AM
To: [email-masked]; [email-masked]; [email-masked]
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-masked]> kboyle at
nortelnetworks.com> 

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

*	Cc:  <mailto:[email-masked]> megaco at ietf.org, Troy Cauble <
<mailto:[email-masked]> 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-masked]?subject=help>
mailto:[email-masked]?subject=help> 

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

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

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

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

*	Sender:  <mailto:[email-masked]> 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:

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

Kevin 

-----Original Message-----

From: megaco-bounces at ietf.org [ <mailto:megaco-bounces>
mailto:megaco-bounces at ietf.org] On Behalf Of

Troy Cauble

To: megaco at ietf.org

Hi,

I think it points out a weakness in the protocol w.r.t. associating

I could find nothing in the docs that say a response's descriptors should be

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

Forcing the order to be maintained and using that for context is ugly, IMO.

(Relying on the text of the error descriptor field would also be a bad idea,

IMO.)

-troy

    Transaction = 50007 {

          Audit{ Packages, Statistics , DigitMap, Signals, Events, Media

    }}}}

Reply = 50007 {

   Context = - {

     AuditValue = aaln/2 {

       Media {

         TerminationState {

           Buffer = OFF},

         Stream = 1 {

           LocalControl {

           }

         }

       },

       Events = 2222 {

         al/of

       },

       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

       },

     }

   }

}

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Dec 2008 09:42:13 +1100

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-masked] wrote:
> 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-masked]>>
>     * /Subject/: Re: [Megaco] descriptor order and error descriptors
>     * /From/: Christian Groves <christian.groves at ericsson.com
>       <mailto:[email-masked]>>
>     * /Date/: Fri, 03 Dec 2004 11:31:00 +1100
>     * /Cc/: megaco at ietf.org <mailto:[email-masked]>, Troy
>       Cauble <troy at bell-labs.com <mailto:[email-masked]>>
>     * /In-reply-to/:
>       <B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2
>       <http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html>>
>
>     * /List-help/: <mailto:[email-masked]?subject=help>
>     * /List-id/: Media Gateway Control <megaco.ietf.org>
>     * /List-post/: <mailto:[email-masked]>
>     * /List-subscribe/:
>       <https://www1.ietf.org/mailman/listinfo/megaco>,
>     * /List-unsubscribe/:
>       <https://www1.ietf.org/mailman/listinfo/megaco>,
>     * /References/: <B258A372CEA20246A363BB86753DB536010B1B28@zrtphxm2
>       <http://www.ietf.org/mail-archive/web/megaco/current/msg05442.html>>
>
>     * /Sender/: megaco-bounces at ietf.org
>     * /User-agent/: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
> ------------------------------------------------------------------------
> Hello Troy and Kevin,
>
> 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:
>
>     From: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org] On Behalf Of
>     Troy Cauble