Subject: [Megaco] Megaco v3 wildcarding question

From: "Nic Larkin" <[email-masked]>
Date: Tue, 26 Sep 2006 12:35:54 +0100

Hi,

Can anyone help me with a question on multi-command wildcard
transactions in Megaco v3?

When working through a wildcard transaction, does the media gateway a)
loop through each context one at a time, applying all commands?  Or does
it b) loop through each command one at a time, applying it to all
contexts?  This is relevant because it affects the final state when an
error is encountered.

Below are two snippets from the Recommendation which seem to favor
different looping models.

The first snippet, from section 6.3, seems emphatic that a) is the
correct approach.
"
When executing a transaction that contains wildcarded contexts and
optionally wildcarded terminations, all commands in the transaction are
executed in order for a particular instance of ContextID before moving
to a subsequent ContextID instance. 
"

However, the second snippet, from section 6.3.4, seems to rely on method
b).
"
When a wildcarded response is requested all instances (as specified
above) of the command shall be executed even if one or more result in
errors, but later commands in the transaction will not be executed
(unless optional was specified).
"

To give a concrete example of the apparent conflict, suppose an MG
exists with state:

context 1
  termination A/1
  termination A/2
context 2
  termination B/3
  termination B/4
context 3
  termination C/5
  termination C/6

The MG receives the transaction request

context = * { 
 w-modify = * { media { terminationstate { servicestates = inservice } }
},
 w-modify = * { media { terminationstate { buffer = off } } }
}
...and suppose the attempt to modify the service state of termination
B/3 is doomed to failure.

The outcome after applying method a) is that 
-  A/1, A/2, C/5, C/6 have service state and buffer control properties
updated.
-  B/3, B/4 are untouched (because the action failed atomically when
applied to context 2).

The outcome after applying method b) is that
-  A/1, A/2, B/4 (?), C/5, C/6 have service state updated.
-  No terminations have buffer control updated.

In conclusion,

-  Is it in fact the case that media gateways must operate a different
looping model depending on whether a wildcard response is requested?

-  Or is there an interpretation of the two snippets above that makes
the error cases more consistent?  It seems that one resolution might be
to replace the two instances of "command" in the 6.3.4 snippet with
"action".  

Thanks,

Nic Larkin
Network Protocols Division
Data Connection Ltd (DCL)
Web: http://www.dataconnection.com
Email: mailto:nic.larkin@dataconnection.

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 26 Sep 2006 13:06:59 -0400

The two options you list do not exist in separate vacuums.  You must
apply both.  Further, remember that execution halts at the detection of
an error.
 
Therefore, the methodology is to loop over the contexts one at a time
and apply all commands.  Within each command, loop over all terminations
that match within that context.  If an error is detected, complete
execution of that wildcarded command, then halt.
 
In the example you gave, and selecting contexts in numerical order:
 
A/1 has both SI and BF updated.
A/2 has both SI and BF updated.
B/3 causes the failure and is NOT updated.
B/4 has SI updated, but not BF.
C/5 and C/6 are not updated.
 
The response would be:
 
C=*{MF=*,MF=*},C=2{MF=*,MF=B/3{ER=errorCode{"etc"}}}
 
>From this you can see that only the first command was executed on
Context 2, and it resulted in an error on termination B/3.  B/4 had its
SI updated due to section 6.3.4.  A/1 and A/2 have both properties
updated and C/5 and C/6 are not updated, due to section 6.3 -- the
commands are executed entirely for a single context before moving on to
a new context.
 
You state in your example that the action "fails atomically".  Note that
this is not possible -- commands are the atomic construct of H.248, not
actions.  You get failures at the action level when the MG can determine
that the ContextID provided causes some failure.  For example, if there
were NO contexts at the time of your scenario, then the error would be
at the action level, since the wildcarded ContextID would not match any
contexts in the MG.
 
Kevin

________________________________

From: Nic Larkin [mailto:[email-masked]] 
Sent: Tuesday, September 26, 2006 7:36 AM
To: [email-masked]
Subject: [Megaco] Megaco v3 wildcarding question

Hi, 

" 

" 

context 1 
  termination A/1 
  termination A/2 
context 2 
  termination B/3 
  termination B/4 
context 3 
  termination C/5 
  termination C/6 

context = * { 

In conclusion, 

Thanks, 

Nic Larkin 
Network Protocols Division 
Data Connection Ltd (DCL) 
Web: http://www.dataconnection.com <http://www.dataconnection.com>  
Email: mailto:nic.larkin@dataconnection
<mailto:nic.larkin@dataconnection> .