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=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?
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
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?
Could you please reply to the above three questions as this is important for our design?
Regards,
Chris