Thanks everyone for the responses to my query. I really appreciate it. So the Cseq value would remain the same in the 2nd and the 3rd BYEs here.
And the 3rd BYE will get the 200OK from the P-CSCF since P-CSCF maintains the information for that transaction until 64*T1. And after 64*T1 if P-CSCF gets the BYE, it'll respond with 481. Thanks, Vivek. ________________________________ From: "WORLEY, Dale R (Dale)" <[email protected]> To: Vivek Singla <[email protected]>; "[email protected]" <[email protected]> Sent: Thu, June 17, 2010 8:26:35 AM Subject: RE: [Sip-implementors] Retransmission of BYE ________________________________________ From: [email protected] [[email protected]] On Behalf Of Vivek Singla [[email protected]] I have a scenario here in the lab : eMTA P-CSCF Invite--------------------> <----------------------------180 <---------------------------200OK ACK----------------------------> BYE------------------------------> <--------------------------------407 BYE-----------------------------> <---------------------------------200OK BYE---------------------------------> <------------------------------------200OK In this scenario the second BYE ( after 407 ) gets the 200OK but after 500ms and therefore sends the third BYE ( retransmission ). 1) The CSeq in second and third BYEs are same ( CSeq: 3 BYE ). Is this correct? 2) The P-CSCF after its gets the 3rd BYE ( retransmission ), sends the 200OK back. Shouldn't it send 4xx saying that no transaction exist? I am thinking since P-CSCF has already sent 200OK for 2nd BYE, it has terminated the transaction and Dialog on its side. So any retransmissions of BYE from UAC should be responded back with 4xx. _______________________________________________ The 3rd BYE has the same CSeq (and branch value) as the 2nd because it is a retransmission of the 2nd BYE, that is, a duplicate copy. (Note that the network is permitted to deliver more than once a packet that has been sent, so the UAS (P-CSCF in this case) must be prepared to receive duplicate copies.) When the UAS receives a duplicate of a request that it has already responded to, it does not re-process the request, but rather retransmits the response that it sent to the first copy of the request. This is all detailed in RFC 3261. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
