Hello Karthik, UAC wanted to terminate the session but before its CANCEL request reached UAS , uas accepted the INVITE. This is a valid scenario and its handling purely depends on UAC's programming.
1. It can render this "call connect" to USER or 2. After receiving 200 Ok could generate BYE without notifying the user. According to me option two is better, as user already tried to disconnect the call. There is little role of proxies in this case. It is a race condition and have little probability is current IMS call flow, and also charging logs are not the actual bills. Regards, Sumit Jindal -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of karthik karthik Sent: Monday, December 22, 2008 1:17 PM To: [email protected] Subject: [Sip-implementors] CANCEL - 200 IINVITE crossover. Hello All, I request clarrification with this cancel - 200(invite) crossover. pcscf in this scenraio acts like a proxy and not a b2bua. step1 ue--invite-->pcscf--invite-->scscf--invite--> scscf doenst send 100 trying to pcscf. pcscf has sent 100 trying to ue. step2 ue--cancel-->pcscf ue<--200(cancel)--pcscf cancel is not forwarded by pcscf to scscf since 100 trying is not received. step3. meanwhile the callee has sent 200(invite) without 18x directly. ue<--200(invite)--pcscf<--200(invite)--scscf<--200(invite)-- ue--ack-->pcscf--ack-->scscf--ack--> ue sends an ack though it had already sent a cancel. what is the expected bahaviour at pcscf? pcscf knows it has sent 200(cancel) to ue. still it forwards answer 200(invite) to ue since it is not a b2bua. Now who should initiate the release? 1.should the ue release the call(send BYE), knowing that the user already went on hook(sent cancel)? 2.should pcscf make some decission as there exists a dialog at pcscf? for instance the ue doesnt send a bye, the ue is charged since it received an answer: 200(invite) Thanks, Karthik Prabhu _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
