30 Apr
2010
30 Apr
'10
1:07 p.m.
2010/4/30 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
No, in RFC 3261 a INVTE transaction ends after a 200 is received,
there is no state to absorbe retransmissions.
In draft invfix the transaction is not inmediately removed upon
receipt of a 200, instead it gets into a new "Accepted" state which
allows absorbing ***INVITE*** retransmissions.
But anyway, if the INVITE has been replied with a 200 it makes no
sense at all to send a CANCEL so the proxy shouldn't reply 200 to the
CANCEL, but a 481.
I don't
agree. As per RFC 3261 when a proxy receives a 200 for an
INVITE the transaction is terminated so a CANCEL after the 200 should
not match such transaction. Then the proxy should reply 481 to the
CANCEL rather than a 200.
If the transaction
for the original request still exists, the behavior of the UAS on
receiving a CANCEL request depends on whether it has already sent a
final response for the original request.
This means that the transaction may still exists although the 200 OK was
already sent (to absorb retransmissions) Regardless of the method of the original request, as
long as the
CANCEL matched an existing transaction, the UAS answers the CANCEL
request itself with a 200 (OK) response.
So 200 OK is fine. If it makes sense is a different point.
Again, RFC 3261 states that the transaction MUST be terminated when
the 200 arrives so the CANCEL after it shouldn't match the
transaction.
In case of draft invfix, IMHO it has a bug in the specification (still
a draft) since it says nothing aobut the CANCEL. It doesn't make sense
that a proxy or UAS replies 200 to a CANCEL if the proxy or UAS
already sent a 200 for the INVITE.
draft invfix: http://tools.ietf.org/html/draft-ietf-sipcore-invfix-01
--
Iñaki Baz Castillo
<ibc(a)aliax.net>