Re: Failed Reply to a command of an H.248 Transaction Request

Comments inline. [KJBII]
 
Kevin


  _____  

From: [email protected] [mailto:[email protected]] On Behalf Of
Karavelas Christos
Sent: Thursday, June 04, 2009 10:49 AM
To: [email protected]
Subject: [Megaco] Failed Reply to a command of an H.248 Transaction Request


Hello, 

A. According to H.248.1 V1/2/3, RFC 3525 Chapter 8 “Transactions”:

“….

Transactions guarantee ordered Command processing.
That is, Commands within a Transaction are executed sequentially



.…
At the first failing Command in a Transaction,
processing of the remaining Commands in that Transaction stops.



…
A TransactionReply includes the results for all of the Commands in 
the corresponding TransactionRequest.  The TransactionReply includes



the return values for the Commands that were executed successfully,
and the Command and error descriptor for any Command that failed.”




and the Implementors Guide for H.248 V2 Chapter 6.32.1 “8 Transaction




which is mentioning the use of a wildcarded TerminationID in a
TransactionReply.





When a problem occurs with the addition of the ephemeral termination,
the reply below is valid for the corresponding Transaction Request:


T=564{C=${A=al/1/1/25{M{O{MO= 
SR,RV=OFF,RG=OFF}},E=353{al/on{strict=exact},al/of{strict=exact},al/fl},SG{}
},
                 A=${M{O{MO=IN,RV=OFF,RG=OFF},L{……..}, R{…….}}}}}

Reply=564{Context=52{Add=al/1/1/25,Add=${Error=500{"Error creating
Stream"}}}}

The reply above means that the addition of the physical termination is
successful resulting that the
created context is included in the reply and the addition of the ephemeral
termination by the Access Gateway
was unsuccessful due to for example lack of resources or to Access Gateway
internal error.

 Is that reply according to the above standards?
[KJBII] This is legal.   

B. It is noticed that some MGCs have a different behavior in relation to
accept the above reply

as described below:

B1. MGC does not support the “ADD=$” in the failed transaction command reply
from AGW to the above request:

MGC expects that the “ADD=$” must not be specified in the failed transaction
command reply, instead it expects:

Reply=564{Context=52{Add=al/1/1/25,Error=500{"Error creating Stream"}}}

 Is the above syntax of the reply valid and therefore acceptable?
[KJBII] This is acceptable, though MGCs ought to accept the message in A as
well. Some MGCs do message validation as they parse.  In this case, those
MGCs might mark the message in A as a failure, because MGs are not supposed
to send CHOOSE.  Either way, the ephemeral Add Command shows up as an error
in the MGC, either due to erroneous message handling or because the MGC
actually processes the message in A correctly.  I would see this as a minor
issue, and it certainly shouldn't affect operation of the MGC.  The worst
that would happen is that the MGC would incorrectly log that the MG is
sending malformed messages.  The easy fix is for the MGC not to mark the
message as malformed until it gets through the rest of the command.  If it
finds an Error Descriptor, then it can ignore the earlier "error" as being
correct.

B2. MGC expects “Context=-“ in the failed transaction reply from AGW to the
above request

MGC expects “Context=-“ in the failed transaction reply from AGW assuming
also that the physical termination
was not added to a context as a result of the ephemeral termination addition
failure: 

Reply=564{Context=-{Add=al/1/1/25,Error=500{"Error creating Stream"}}}


Is the above assumption by MGC and the syntax of the Transaction Reply valid
and therefore acceptable?
[KJBII] This is NOT acceptable.  There are many problems here: 1)
Terminations cannot be added to NULL, so returning NULL to an Add Command is
a violation of protocol; 2) Assuming the Add of the physical termination is
faulty logic and is incorrect -- all commands that receive non-error
responses prior to an error in a message are valid commands, and are
executed; 3) Because the Add Command for the physical succeeded, the MGC
needs to know what context it was placed in so that it can execute further
commands on it if necessary. The MG must never return the NULL Context in a
reply to an Add Command.



Could you please reply to the above three questions as this is important for
our design?

Regards,

Chris

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco