Hi Jun,
Section 2.1 CANCEL crossover - describes when an UAS sends a final response to an INVITE, the INVITE transaction is not there on the UAS anymore. Consider these scenarios:
1. An UAS receives an INVITE, but response(s) sent to the UAC failed to be delivered, the UAS receives a retransmission of the INVITE which it 200ed. Instead of processing the INVITE retransmission in a new transaction, it makes more sense if the UAS keep the transaction around (until transaction timeout?) and retransmits the 200 upon receiving INVITE retransmission. In other words, when an dialog on UAS is in confirmed dialog state doesn't imply the INVITE transaction has gone away.
2. Suppose Alice is using a SIP phone, she calls Bob and hangs up. As the draft described, Alice's CANCEL crosses Bob's 200. The draft suggests Alice's INVITE succeeded and two way media path is established, but Alice's phone is hung up, how does it work?
Please consider these two alternatives:
1. When an UAS receives a CANCEL to an INVITE which it has 200ed, it should assume the 200 was dropped, then 200s the CANCEL and then 487s the initial INVITE. Accordingly, UAC should treat any follow-up provisional/final response to its INVITE as stray response, ignore it, once it CANCELed the INVITE or
2. When an UAC receives a 200 to an INVITE which it has CANCELed, both UAC and UAS proceed as the draft described. In addition, UAC sends a BYE immediately after ACKing the 200. As far as Alice (user of the UAC) is concerned, once she hangs up, all dialogs and all sessions created as a result of its INVITE are terminated, if any. However, UAC core and transaction layer should keep the contexts around to handle potential retransmissions. Perhaps this is implied in the draft, if so, I suggest making it explicit.
Ken Ho
Jun KOSHIKO(Private) wrote:
Folks,
We are now doing new examples work, as chairs announced on SIPPING WG meeting on Thursday morning.
The draft can be found at http://www.ietf.org/internet-drafts/draft-hasebe-sipping-semi-regular-examples-00.txt
This draft gives examples of SIP semi-regular call flows. We would like to clarify less ordinary call flows or corner cases, such as the call flow in which a BYE from UAC and UAS crosses each other.
Followings are our purposes: - To help implementation or testing of SIP, by describing the plain
examples about difficult parts of RFCs.
- Improvement in interconnectivity by minimizing the difference between
implementers to clarify the behaviors.
We would like to ask you followings: - Please review the draft - Send additional examples to authors - Better idea for title? (We think the title "Semi Regular examples" could be better.)
Five examples are included in 00 version. And we would like to accept additional examples. We also appreciate your comments to existing examples.
Any comments and thoughts are appreciate.
Regards, Jun Koshiko
_______________________________________________ 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
