Subject: Transaction ID NULL

From: J Ramachandra <[email-masked]>
Date: Thu, 13 Apr 2000 02:06:54 -0500

Hi,

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?

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?

- J K Ramachandra
  AXES TECHNOLOGIES.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 11:35:24 -0400

> 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.

> 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.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 17 Apr 2000 19:29:03 -0400

There is of course no way to reliably determine the offending command,
but in most practical cases it can be determined by holding commands
until other commands are acknowledged, and resending any missing commands
one at a time.

Of course, this kind of problem is either a symptom of a seriously broken
implementation, or a broken computer (checksums should find noisy network
problems).

Brian

> -----Original Message-----
> From: J Ramachandra [mailto:[email-masked]]
> Sent: Monday, April 17, 2000 2:39 AM
> To: [email-masked]
> Subject: Re: Transaction ID NULL
>
>
>  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
>
> 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
>