Re: [Sip-implementors] Cancelling an INVITE which did not got provisional response yet
AXE MSC writes: > After 4 minutes, handset replies back with TCP ACK. PCSCF then re-transmits > INVITE and and gets 183 back from handset. However, because calling party > side call was already cleared at 15th second, this is causing a ghost call > for B party after 4 minutes of the original call. It is true that the called party sees a ghost call. But immediately after PCSCF receives the 183, it should send the CANCEL for the call. So if the delay was in the propagation of the INVITE to the handset, the ghost call will be canceled quickly (from the point of the view of the called party). > Can PCSCF destroy the transaction at 15th second without sending the Cancel > to handset? Later if handset comes with provisional response then PCSCF > can just reply back with SIP 481(transaction does not exist). Depending on exactly how PCSCF generates the INVITE it sends, it may be able to avoid keeping state information for the call after it is canceled. But it is still required to send a CANCEL to the called handset as soon as it receives a provisional response. However, it may be able to know that it should send the CANCEL, and be able to construct and send the CANCEL, without having kept state information about the INVITE. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Cancelling an INVITE which did not got provisional response yet
On 3/13/19 5:45 PM, AXE MSC wrote: Hi, PCSCF has two realms. One is facing Core network and another is facing Access network. I have a scenario where PCSCF sends the INVITE to the handset facing Access realm. But no TCP ACK or SIP provisional response received from the handset. After 15 seconds wait time SCSCF asks PCSCF core realm to clear the call by sending a Cancel. PCSCF replies back with 200 Ok for the Cancel. But PCSCF kept the transaction alive for the handset due to RFC 3261, Section 9.1: "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." Is the PCSCF acting as a proxy or B2BUA? After 4 minutes, handset replies back with TCP ACK. PCSCF then re-transmits INVITE and and gets 183 back from handset. However, because calling party side call was already cleared at 15th second, this is causing a ghost call for B party after 4 minutes of the original call. Can PCSCF destroy the transaction at 15th second without sending the Cancel to handset? Later if handset comes with provisional response then PCSCF can just reply back with SIP 481(transaction does not exist). To be correct you need to maintain the transaction until you get something back or it times out. If PCSCF is acting as proxy, then the SCSCP should be retransmitting the INVITE (according to timers) until something comes back or the transaction times out. Sending CANCEL and receiving a 200 to it doesn't mean you can avoid this. If the CANCEL succeeds then a 487 should be received for the INVITE, ending the transaction. OTOH, if the PCSCF is acting as a B2BUA, then the PCSCF *may* send a 487 to the INVITE when it gets the CANCEL. It will then have to handle the transaction to the handset itself. It will still need to do all the above on its own. If that then results in the handset accepting the call it can send a BYE to terminate it. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Cancelling an INVITE which did not got provisional response yet
Hi, PCSCF has two realms. One is facing Core network and another is facing Access network. I have a scenario where PCSCF sends the INVITE to the handset facing Access realm. But no TCP ACK or SIP provisional response received from the handset. After 15 seconds wait time SCSCF asks PCSCF core realm to clear the call by sending a Cancel. PCSCF replies back with 200 Ok for the Cancel. But PCSCF kept the transaction alive for the handset due to RFC 3261, Section 9.1: "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." After 4 minutes, handset replies back with TCP ACK. PCSCF then re-transmits INVITE and and gets 183 back from handset. However, because calling party side call was already cleared at 15th second, this is causing a ghost call for B party after 4 minutes of the original call. Can PCSCF destroy the transaction at 15th second without sending the Cancel to handset? Later if handset comes with provisional response then PCSCF can just reply back with SIP 481(transaction does not exist). Any thoughts? Thanks ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
