Subject: Re: Transaction ID NULL

From: J Ramachandra <[email-masked]>
Date: Mon, 17 Apr 2000 01:38:50 -0500

Brian,

Thanks for the first part, but I have some difficulties with the 2nd
part.
See my comments marked as JK> below.

- J K Ramachandra

-----Original Message-----
From: Rosen, Brian
To: 'J Ramachandra'; [email-masked]
Sent: 4/14/00 10:35 AM
Subject: RE: Transaction ID NULL

> Section 8.2.2 Transaction Reply, specifies
> "If the receiver encounters an error such that it cannot determine a
> legal Transaction, it will return a TransactionReply with a null
> TransactionID and a single error descriptor (403 Syntax Error in
> Transaction)".
>
> What is null TransactionID?
> Is it 0 ?  e.g. Reply=0 {Error=403{error string} }
> OR is it like Reply= {Error=403{error string}}?
> As per ABNF, second one results in syntax error.
>
> If it is 0, one is not expected to use transaction ID 0 for a valid
> transaction request? (MGCP Implementation Guide by International
> Softswitch Consortium suggests this for MGCP). If one uses it, how to
> identify whether it is the Reply received for transaction Request 0
> or an error response for one of your requests?
I think we SHOULD do what MGCP does, reserve 0, and use it for this
purpose.  I would prefer NOT to change the ABNF to allow an omitted
TransactionID -- I would prefer the scanner generate an error for this.

> Finally,what purpose it serves to receive a reply like this, when you
> can not determine for which transaction this reply is? Why not ignore
> such a transaction Request, instead of sending an error Reply?
Because the entity that sent the request is looking for a reply.
When it gets no reply, it will retry.  After it retries a number of
times, it might believe the link is down, or the other side is broken.
An error message is a much better answer.

JK> How the receiving entity associates this Reply with its Request?
    Say, there are 'n' number of transaction Request sent towards the
    same destination, how the receiver will decide to which Request (of
    n transaction requests)it should associate this with? The only way
    you can correlate is through the TransactionID which is missing
    (or to be precise, not same) in this error message.

Brian

---

From: Naoto MAKINAE <[email-masked]>
Date: Mon, 17 Apr 2000 22:50:43 +0900

Hi,  JK and Brian.

>     (or to be precise, not same) in this error message.

Returning a TransactionReply with a null TransactionID on receipt of an
illegal transaction seems to cause problems.

Because, an illegal transaction may turn out to be a TransactionReply.

Consider the following scenario:

(STEP 1) A MG sends a legal TransactionRequest to a MGC and
         starts a retransmission timer.

(STEP 2) The MGC responds with several TransactionPendings and a
         TransactionReply, which happens to be illegal in the format.

(STEP 3) The MG receives the message which contains the illegal
         TransactionReply and responds with a TransactionReply with a null
         TransactionID.

(STEP 4) If the MGC has no unanswered Transaction, it would simply ignore
         the TransactionReply. If it has any, it would resend them just in
         case.

(STEP 5) After a while, the retransmission timer of the MG expires.
         The MG resends the TransactionReqeust.

(STEP 6) The MGC processes the request again.

If the original TransactionRequest can be processed twice without
any side-effects, there would be no problem.

But, duplicated Notifications likely to cause side-effects.
If you introduce the policy which restricts the reuse of
recently-relinquished TransactionIDs in order to avoid the side-effects,
the STEP 5 or STEP 6 would fail and the MG would never know the response.

Moreover, let's consider another scenario, in which the roles of MG and MGC
are interchanged from the original scenario.

I'll write down the second scenario for clarity:

(STEP 1) A MGC sends a legal TransactionRequest to a MG and
         starts a retransmission timer.

(STEP 2) The MG responds with several TransactionPendings and a
         TransactionReply, which happens to be illegal in the format.

(STEP 3) The MGC receives the message which contains the illegal
         TransactionReply and responds with a TransactionReply with a null
         TransactionID.

(STEP 4) If the MG has no unanswered Transaction, it would simply ignore
         the TransactionReply. If it has any, it would resend them just in
         case.

(STEP 5) After a while, the retransmission timer of the MGC expires.
         The MGC resends the TransactionReqeust.

(STEP 6) The MG processes the request again.

The MGC issues commands, like Add, Modify, Subtract, or Move, which are more
likely to cause side-effects if the contain wildcards. So, they should not be resent.

How do you think?

One alternative for returning the null TransactionID is to reject the message
which contains the illegal transaction. This apparently requires the message-
level acknowledgement scheme.

Naoto
--
Naoto MAKINAE
Information Sharing Platform Laboratories
Nippon Telegram and Telephone Corporation
Email:[email-masked]

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 18 Apr 2000 13:59:29 -0400

There seems to be a misunderstanding here on handling such errors.
Firstly, MEGACO grammar specifies the proper way of doing media
transactions. If MGC/MG abuses the grammar then it must suffer the
consequences of being disconnected and even banned of participating
in talking to the peer device. This is obviously an implementation and
a vendor decision which is beyond the scope of the protocol.

Secondly, if MGC/MG parser decides to be syntax-error friendly,
then it can perform some diagnostic operations to figure out what
is missing and report the error back using error message at either the
message or the transaction levels and report its diagnosis on the
cause of error. Again, this is an implementation issue.

The bottom line is that if MGC/MG generates syntax errors, IMO
if MGC/MG generates many null transactions then it should not
be even out in there, then a high level error message should be
enough to pin point the error but it is up to the implementer to
figure it out and fix it and not the parser who generates no errors.

Reserving TID 0 for such cases as Brian indicated, is a matter of
flexibility for recovery and should be enough to handle all such
cases.

Abdallah