Dale,
I agree with you that it is somewhat philosophical, but that does not make
it any less problematic.
Specifically, it's not the INVITE transaction that is retransmitting the 2xx
(that one is already terminated) but the UAS core.
And where a retransmitted BYE can be detected by matching the branch from
its top Via header against the set of ongoing transactions, this cannot be
done for the ACK that would quench the 2xx retransmission.
I am currently inclined to keep the dead dialog around to be able to match
an incoming ACK to its retransmission source. It's just a subtlety that I
did not see before
Thanks for your comments anyway,
Regards,
jeroen
----- Original Message -----
From: "Dale Worley" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, August 03, 2005 4:22 PM
Subject: RE: [Sip-implementors] Doubt on proper UAC/UAS behavior
From: Jeroen van Bemmel
My question is: how should this be handled? Should reception
of a BYE abort
retransmission of the 2xx, or should the dialog linger as
long as the INVITE
server transaction has not finished? RFC3261 recommends that the UAS
responds to any remaining requests with a 487 Request
terminated, but since
it has already responded with 2xx I don't think it should
change its mind
for that one
IMHO, it's sort of a philosophical point which is straightforward when
looked at correctly: Once the BYE is received, the *dialog* is
eradicated,
as both sides are in agreement that it has ended. But the *transaction*
for
the INVITE lives on (so it can retransmit the 200, and be quenched by
receiving the ACK). And the transaction for the BYE lives on (to
retransmit
the response to the BYE if the other end retransmits the BYE). There are
a
number of similar situations that have been discussed on these lists.
This probably isn't exactly the letter of RFC 3261, but it is clearly what
is intended.
Dale
_______________________________________________
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
