Hi,
I do not dispute the fact that the transaction should not be created for
CANCEL. My question is why it should go all the way to TU for the
transaction to be created.
Let me outline a simle implementation
<implementation>
a CANCEL is received from the network,
the transport tries to match the transaction with the branch-id, typically a
search on a hash table. the result is one INVITE transaction. It tries to
check if the methods match, nope, it sends it to TU.
TU now queries the transaction (hash table!!) with the branch-id and grabs
the INVITE again, changes the method to INVITE and matches. This does
match. Then the TU proceeds to create a transaction and CANCELs the
transaction.
</implemenation>
This involves two transaction matches.
Why can't we take advantage of the fact that in the first match itself we
managed to grab the transaction to be CANCELLED.
Is it done so that the TU can validate the dialog parameters of the CANCEL
message?
Regards,
Prasanna
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 5:48 PM
To: Prasanna Venkatesh
Cc: Sip-Implementors (E-mail); [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Who should send a 200 for CANCEL
Hi,
Even if the CANCEL transaction affects another transaction (the one it
cancels) they
are still two separate transactions, and should be handled as such - ie the
consist of
both a request and response.
Regards,
Christer Holmberg
Ericsson Finland
Prasanna Venkatesh wrote:
> Hi,
> Is it required that the TU only sends the 200 for CANCEL requests,
even if
> they matched the original transaction? Since the branch-id shall match
the
> original transaction, but the transaction shall not match (as per 17.2.3
> (3261) - point 3) as the method is different. But the transaction has the
> handle of the original request, why it cannot generate the 200 by its own.
>
> thanks in advance,
> Regards,
> Prasanna
> Huawei Technologies
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
