Subject: RE: [Megaco] Conformance tests question

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 27 May 2005 13:49:01 -0400

In most cases, the MG knows it cannot allocate a context at the time the
request is detected -- that is, once the action is parsed.  If the MG
detects a problem, why would it continue to parse?  The error descriptor
ought to be placed at the action level, so there would not be a context
indicated of any kind, let alone a CHOOSE wildcard.

Remember, error detection occurs at the earliest possible time with the
error descriptor occurring at the level of detection.  If the MG was not
able to detect that it was unable to allocate a context until the command or
descriptor level, then the error descriptor would go at the lower level.

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
B Venkat S.R Swamy
Sent: Thursday, May 26, 2005 8:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Megaco] Conformance tests question

Hi

IMO it is perfectly valid to specify CHOOSE for contextID in response to the
test cases you have mentioned below.  As far as the protocol text you have
mentioned it applies mostly to those scenario where you a valid context
Id(includes wildcard also) or Null context. Where MG has never been able to
create a context why should it return any other value.

Even the ABNF and ASN grammar in Appendix does not put any limitation on the
set of values that can be used in the Reply messages.

I however do agree that the relevant text should be modified to clarify
these scenario and request authors to take this in IG or upcoming V3
document.

regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone:  +91-124-2455555 Extn 3620
Fax: +91-124-2455345
web: www.hssworld.com

             Seraya.Miletzki@e                                             
             citele.com                                                    
             Sent by:                                                   To 
             megaco-bounces@ie         [email-masked]                     
             tf.org                                                     cc 
                                                                           
                                                                   Subject 
             05/26/2005 05:17          [Megaco] Conformance tests question 
             PM                                                            

Hello all

I was performing conformance tests for the MEGACO according ETSI TS 101
889-2 v1.1.1 (2002-08).
I have a question regarding some of the expected results appeared on this
tests:
On error tests (BI type) there are several tests that send request with
ContextID set to CHOOSE ($).
The expected results on the tests contain action reply with ContextID set to
CHOOSE.
Here is an example for this tests :

TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause 7.2.1
Selection criteria: ROOT termination implemented Initial condition: any
Ensure that the IUT, on receipt of a Transaction Request containing
      * Action request with
            o CID set to CHOOSE
            o ADD Command request wi
sends a Transaction Reply containing
      * Action reply with
            o CID set to CHOOSE
            o ADD Command reply wi
RO

The H.248.1 v1 spec mandate that transaction reply may only contain a
specific ContextID, ALL (*), or NULL (-).

Here's the relevant text from the H.248.1 v1 spec:
8.2.2     TransactionReply
...
The ContextID parameter must specify a value to pertain to all Responses for
the action. The ContextID may be specific, all or null.

The following 19 items are the test cases with this requirement.

1.    TP/MG/AD/BI-01
2.    TP/MG/AC/BI-01
3.    TP/MG/AC/BI-02
4.    TP/MG/AC/BI-03
5.    TP/MG/AC/BI-04
6.    TP/MG/AV/BI-01
7.    TP/MG/AV/BI-02
8.    TP/MG/AV/BI-03
9.    TP/MG/AV/BI-04
10.   TP/MG/MD/BI-01
11.   TP/MG/MD/BI-02
12.   TP/MG/MD/BI-03
13.   TP/MG/MD/BI-09
14.   TP/MG/SU/BI-01
15.   TP/MG/SU/BI-02
16.   TP/MG/SU/BI-03
17.   TP/MG/SU/BI-04
18.   TP/MG/MV/BI-01
19.   TP/MG/MV/BI-02

Please help me to clear this issue.

Thanks

Seraya_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

***********************  FSS-Restricted   ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and should
not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the individual to whom
it is addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in  error, please notify the
originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing the
contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted by this email
including damage from virus."

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 29 May 2005 08:27:52 +0200

In the general case, if the MG detects an error at the command level, it
does need to continue to parse.  If the command is optional, it should
proceed to the next command.

Raphael Tryster

 -----Original Message-----
From: 	Kevin Boyle [mailto:[email-masked]] 
Sent:	Friday, May 27, 2005 7:49 PM
To:	B Venkat S.R Swamy; [email-masked]
Cc:	[email-masked]
Subject:	RE: [Megaco] Conformance tests question

Kevin 

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

Hi

regards
B Venkat S.R Swamy
Senior Technical Leader

             Seraya.Miletzki@e                                             
             citele.com                                                    
             Sent by:                                                   To 
                                                                           
                                                                   Subject 

Hello all

1.    TP/MG/AD/BI-01
2.    TP/MG/AC/BI-01
3.    TP/MG/AC/BI-02
4.    TP/MG/AC/BI-03
5.    TP/MG/AC/BI-04
6.    TP/MG/AV/BI-01
7.    TP/MG/AV/BI-02
8.    TP/MG/AV/BI-03
9.    TP/MG/AV/BI-04
10.   TP/MG/MD/BI-01
11.   TP/MG/MD/BI-02
12.   TP/MG/MD/BI-03
13.   TP/MG/MD/BI-09
14.   TP/MG/SU/BI-01
15.   TP/MG/SU/BI-02
16.   TP/MG/SU/BI-03
17.   TP/MG/SU/BI-04
18.   TP/MG/MV/BI-01
19.   TP/MG/MV/BI-02

Thanks

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 31 May 2005 09:57:01 -0400

But if the error is at the ACTION level, why would it even get to the
command level?  Similarly, if the error is at the TRANSACTION level, the
parse will never get to the command level.
 
Because the problem is with the allocation of a context -- signified by the
$ at the action level -- the MG will know it has a problem before it even
gets to the command.  Any commands in this action are doomed to fail, as the
context will not exist.  At best, the MG can only go on to the next action.
But note that actions cannot be optional -- only commands can be optional.
So the assertion holds that the MG can halt parsing of the transaction at
the failure to allocate a context upon parse of the C=$.
 
Kevin

  _____  

From: Raphael Tryster [mailto:[email-masked]] 
Sent: Sunday, May 29, 2005 2:28 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; B Venkat S.R Swamy;
[email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Conformance tests question

Raphael Tryster 

 -----Original Message----- 
From:   Kevin Boyle [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent:   Friday, May 27, 2005 7:49 PM 
To:     B Venkat S.R Swamy; [email-masked] 
Cc:     [email-masked] 
Subject:        RE: [Megaco] Conformance tests question 

Kevin 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of 
B Venkat S.R Swamy 
Sent: Thursday, May 26, 2005 8:25 AM 
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: [Megaco] Conformance tests question 

Hi 

regards 
B Venkat S.R Swamy 
Senior Technical Leader 

             Seraya.Miletzki@e                                             
             citele.com                                                    
             Sent by:                                                   To 
                                                                           
                                                                   Subject 

Hello all 

CHOOSE. 

1.    TP/MG/AD/BI-01 
2.    TP/MG/AC/BI-01 
3.    TP/MG/AC/BI-02 
4.    TP/MG/AC/BI-03 
5.    TP/MG/AC/BI-04 
6.    TP/MG/AV/BI-01 
7.    TP/MG/AV/BI-02 
8.    TP/MG/AV/BI-03 
9.    TP/MG/AV/BI-04 
10.   TP/MG/MD/BI-01 
11.   TP/MG/MD/BI-02 
12.   TP/MG/MD/BI-03 
13.   TP/MG/MD/BI-09 
14.   TP/MG/SU/BI-01 
15.   TP/MG/SU/BI-02 
16.   TP/MG/SU/BI-03 
17.   TP/MG/SU/BI-04 
18.   TP/MG/MV/BI-01 
19.   TP/MG/MV/BI-02 

Thanks 

Seraya_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  

_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>

---

From: "Jon Rowland" <[email-masked]>
Date: Tue, 31 May 2005 15:54:53 +0100

Just to pick up on the point of non-optional actions...
 
Surely if an action contains only optional commands, then it is
implicitly optional?
 
This is required to construct transactions like the following:
T=1 {
C=* {O-AV=Term}
C=- {AV=Term}
}
which are useful in MGC/MG resync processing where it's not known for
certain if the termination is in a context. To have to send two separate
transactions for this because the * wildcard does not include the NULL
context seems very tedious.
 
This does feel slightly orthongonal to the below discussion, as I cannot
see how to construct such a useful transaction involving a CHOOSE
wildcard - it does indeed feel reasonable to fail the transaction on the
action-error in that case.
 
Jon.

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kevin Boyle
	Sent: 31 May 2005 14:57
	To: Raphael Tryster; B Venkat S.R Swamy;
[email-masked]
	Cc: [email-masked]
	Subject: RE: [Megaco] Conformance tests question

	But if the error is at the ACTION level, why would it even get
to the command level?  Similarly, if the error is at the TRANSACTION
level, the parse will never get to the command level.
	 
	Because the problem is with the allocation of a context --
signified by the $ at the action level -- the MG will know it has a
problem before it even gets to the command.  Any commands in this action
are doomed to fail, as the context will not exist.  At best, the MG can
only go on to the next action.  But note that actions cannot be optional
-- only commands can be optional.  So the assertion holds that the MG
can halt parsing of the transaction at the failure to allocate a context
upon parse of the C=$.
	 
	Kevin

________________________________

		In the general case, if the MG detects an error at the
command level, it does need to continue to parse.  If the command is
optional, it should proceed to the next command.

		Raphael Tryster 

		 -----Original Message----- 
		From:   Kevin Boyle [mailto:[email-masked]] 
		Sent:   Friday, May 27, 2005 7:49 PM 
		To:     B Venkat S.R Swamy; [email-masked] 
		Cc:     [email-masked] 
		Subject:        RE: [Megaco] Conformance tests question 

		In most cases, the MG knows it cannot allocate a context
at the time the 
		request is detected -- that is, once the action is
parsed.  If the MG 
		detects a problem, why would it continue to parse?  The
error descriptor 
		ought to be placed at the action level, so there would
not be a context 
		indicated of any kind, let alone a CHOOSE wildcard. 

		Remember, error detection occurs at the earliest
possible time with the 
		error descriptor occurring at the level of detection.
If the MG was not 
		able to detect that it was unable to allocate a context
until the command or 
		descriptor level, then the error descriptor would go at
the lower level. 

		Kevin 

		-----Original Message----- 
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of 
		B Venkat S.R Swamy 
		Sent: Thursday, May 26, 2005 8:25 AM 
		To: [email-masked] 
		Cc: [email-masked] 
		Subject: Re: [Megaco] Conformance tests question 

		Hi 

		IMO it is perfectly valid to specify CHOOSE for
contextID in response to the 
		test cases you have mentioned below.  As far as the
protocol text you have 
		mentioned it applies mostly to those scenario where you
a valid context 
		Id(includes wildcard also) or Null context. Where MG has
never been able to 
		create a context why should it return any other value. 

		Even the ABNF and ASN grammar in Appendix does not put
any limitation on the 
		set of values that can be used in the Reply messages. 

		I however do agree that the relevant text should be
modified to clarify 
		these scenario and request authors to take this in IG or
upcoming V3 
		document. 

		regards 
		B Venkat S.R Swamy 
		Senior Technical Leader 

		             Seraya.Miletzki@e

		             citele.com

		             Sent by:
To 

		             tf.org
cc 

Subject 
		             05/26/2005 05:17          [Megaco]
Conformance tests question 
		             PM

	

		Hello all 

		I was performing conformance tests for the MEGACO
according ETSI TS 101 
		889-2 v1.1.1 (2002-08). 
		I have a question regarding some of the expected results
appeared on this 
		tests: 
		On error tests (BI type) there are several tests that
send request with 
		ContextID set to CHOOSE ($). 
		The expected results on the tests contain action reply
with ContextID set to 
		CHOOSE. 
		Here is an example for this tests : 

		TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1
[3] clause 7.2.1 
		Selection criteria: ROOT termination implemented Initial
condition: any 
		Ensure that the IUT, on receipt of a Transaction Request
containing 
		      * Action request with 
		            o CID set to CHOOSE 
		            o ADD Command request wi 
		sends a Transaction Reply containing 
		      * Action reply with 
		            o CID set to CHOOSE 
		            o ADD Command reply wi 
		RO 

		The H.248.1 v1 spec mandate that transaction reply may
only contain a 
		specific ContextID, ALL (*), or NULL (-). 

		Here's the relevant text from the H.248.1 v1 spec: 
		8.2.2     TransactionReply 
		... 
		The ContextID parameter must specify a value to pertain
to all Responses for 
		the action. The ContextID may be specific, all or null. 

		The following 19 items are the test cases with this
requirement. 

		1.    TP/MG/AD/BI-01 
		2.    TP/MG/AC/BI-01 
		3.    TP/MG/AC/BI-02 
		4.    TP/MG/AC/BI-03 
		5.    TP/MG/AC/BI-04 
		6.    TP/MG/AV/BI-01 
		7.    TP/MG/AV/BI-02 
		8.    TP/MG/AV/BI-03 
		9.    TP/MG/AV/BI-04 
		10.   TP/MG/MD/BI-01 
		11.   TP/MG/MD/BI-02 
		12.   TP/MG/MD/BI-03 
		13.   TP/MG/MD/BI-09 
		14.   TP/MG/SU/BI-01 
		15.   TP/MG/SU/BI-02 
		16.   TP/MG/SU/BI-03 
		17.   TP/MG/SU/BI-04 
		18.   TP/MG/MV/BI-01 
		19.   TP/MG/MV/BI-02 

		Thanks 

		***********************  FSS-Restricted
*********************** 
		"DISCLAIMER: This message is proprietary to Hughes
Software Systems Limited 
		(HSS) and is intended solely for the use of the
individual to whom it is 
		addressed. It may contain  privileged or confidential
information and should 
		not be circulated or used for any purpose other than for
what it is 
		intended. If you have received this message in error,
please notify the 
		originator immediately. If you are not the intended
recipient, you are 
		notified that you are strictly prohibited from using,
copying, altering, or 
		disclosing the contents of this message. HSS accepts no
responsibility for 
		loss or damage arising from the use of the information
transmitted by this 
		email including damage from virus." 
		"DISCLAIMER: This message is proprietary to Flextronics
Software Systems 
		Limited (FSS) and is intended solely for the use of the
individual to whom 
		it is addressed. It may contain  privileged or
confidential information and 
		should not be circulated or used for any purpose other
than for what it is 
		intended. If you have received this message in  error,
please notify the 
		originator immediately. 
		If you are not the intended recipient, you are notified
that you are 
		strictly  prohibited  from  using, copying, altering, or
disclosing the 
		contents of this message.  FSS  accepts no
responsibility  for loss or 
		damage arising from the use of  the information
transmitted by this email 
		including damage from virus."

---

From: Raphael Tryster <[email-masked]>
Date: Tue, 31 May 2005 18:13:28 +0200

An action containing only optional commands is not implicitly optional.  If
any of the commands in it fails, it will proceed to the next command, and to
the next action when all the commands in that action are completed.  But if
it fails at the action level, it will not proceed to the next action.
 
I accept what Kevin says that “MG can halt parsing”.  I just want to verify
that it’s “can” and not “must”.  That is, Megaco doesn’t get into the
implementation detail of whether transaction execution should be interleaved
with parsing, or begin after parsing is completed, as long as the rules of
when to stop execution are followed.
 
Raphael Tryster

-----Original Message-----
From: Jon Rowland [mailto:[email-masked]]
Sent: Tuesday, May 31, 2005 4:55 PM
To: Kevin Boyle; Raphael Tryster; B Venkat S.R Swamy;

Surely if an action contains only optional commands, then it is implicitly
optional?

This does feel slightly orthongonal to the below discussion, as I cannot see
how to construct such a useful transaction involving a CHOOSE wildcard - it
does indeed feel reasonable to fail the transaction on the action-error in
that case.
 
Jon.
 
  _____  

Kevin Boyle
To: Raphael Tryster; B Venkat S.R Swamy; [email-masked]

Kevin
 
  _____

---

From: [email-masked]
Date: Tue, 31 May 2005 10:56:04 -0700

All,
 
This is in reference to MGC/MG resync process. 
 
I would like to know if there is a way for MG to request MGC/MG re-sync for a particular Termination (Physical or Ephemeral or both) ?? 
This would apply in case where MGC does not periodically audit terminations on MG or if the period between
2 audit's is very long.
 
Thank you,
 
Jerry Patel.

From: [email-masked] on behalf of Jon Rowland
Sent: Tue 5/31/2005 7:54 AM
To: Kevin Boyle; Raphael Tryster; B Venkat S.R Swamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] Conformance tests question

Surely if an action contains only optional commands, then it is implicitly optional?
 
This is required to construct transactions like the following:
T=1 {
C=* {O-AV=Term}
C=- {AV=Term}
}
which are useful in MGC/MG resync processing where it's not known for certain if the termination is in a context. To have to send two separate transactions for this because the * wildcard does not include the NULL context seems very tedious.
 
This does feel slightly orthongonal to the below discussion, as I cannot see how to construct such a useful transaction involving a CHOOSE wildcard - it does indeed feel reasonable to fail the transaction on the action-error in that case.
 
Jon.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Boyle
	Sent: 31 May 2005 14:57
	To: Raphael Tryster; B Venkat S.R Swamy; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Megaco] Conformance tests question

	But if the error is at the ACTION level, why would it even get to the command level?  Similarly, if the error is at the TRANSACTION level, the parse will never get to the command level.
	 
	Because the problem is with the allocation of a context -- signified by the $ at the action level -- the MG will know it has a problem before it even gets to the command.  Any commands in this action are doomed to fail, as the context will not exist.  At best, the MG can only go on to the next action.  But note that actions cannot be optional -- only commands can be optional.  So the assertion holds that the MG can halt parsing of the transaction at the failure to allocate a context upon parse of the C=$.
	 
	Kevin

		From: Raphael Tryster [mailto:[email-masked]] 
		Sent: Sunday, May 29, 2005 2:28 AM
		To: Boyle, Kevin [NCRTP:3Z40:EXCH]; B Venkat S.R Swamy; [email-masked]
		Cc: [email-masked]
		Subject: RE: [Megaco] Conformance tests question

		In the general case, if the MG detects an error at the command level, it does need to continue to parse.  If the command is optional, it should proceed to the next command.

		Raphael Tryster 

		 -----Original Message----- 
		From:   Kevin Boyle [mailto:[email-masked]] 
		Sent:   Friday, May 27, 2005 7:49 PM 
		To:     B Venkat S.R Swamy; [email-masked] 
		Cc:     [email-masked] 
		Subject:        RE: [Megaco] Conformance tests question 

		Kevin 

		-----Original Message----- 
		From: [email-masked] [mailto:[email-masked]] On Behalf Of 
		B Venkat S.R Swamy 
		Sent: Thursday, May 26, 2005 8:25 AM 
		To: [email-masked] 
		Cc: [email-masked] 
		Subject: Re: [Megaco] Conformance tests question 

		Hi 

		regards 
		B Venkat S.R Swamy 
		Senior Technical Leader 

		             Seraya.Miletzki@e                                             
		             citele.com                                                    
		             Sent by:                                                   To 
		                                                                           
		                                                                   Subject 

		Hello all 

		1.    TP/MG/AD/BI-01 
		2.    TP/MG/AC/BI-01 
		3.    TP/MG/AC/BI-02 
		4.    TP/MG/AC/BI-03 
		5.    TP/MG/AC/BI-04 
		6.    TP/MG/AV/BI-01 
		7.    TP/MG/AV/BI-02 
		8.    TP/MG/AV/BI-03 
		9.    TP/MG/AV/BI-04 
		10.   TP/MG/MD/BI-01 
		11.   TP/MG/MD/BI-02 
		12.   TP/MG/MD/BI-03 
		13.   TP/MG/MD/BI-09 
		14.   TP/MG/SU/BI-01 
		15.   TP/MG/SU/BI-02 
		16.   TP/MG/SU/BI-03 
		17.   TP/MG/SU/BI-04 
		18.   TP/MG/MV/BI-01 
		19.   TP/MG/MV/BI-02 

		Thanks