Hello,
From: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org] On Behalf Of Karavelas Christos
Sent: Thursday, June 04, 2009 10:49 AM
To: megaco at ietf.org
Subject: [Megaco] Failed Reply to a command of an H.248 Transaction RequestA. 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.T=564{C=${A=al/1/1/25{M{O{MO=
When a problem occurs with the addition of the ephemeral termination,
the reply below is valid for the corresponding Transaction Request: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