I think that the right way to respond is to resend the last provisional response.
But it seems a slight hack to pretend you haven't received a response when you really have. And it's confusing. People looking at a trace might think, is it retransmitting because the client didn't receive the response? Or because it's trying to keep the pinhole open? Would it be better if UPDATE was used instead? Once you send the 18x, they send the PRACK and you OK the PRACK. Then, for refreshing the pinhole, they send UPDATE with a new CSeq. And you OK that. This has the advantages of: 1. They don't even have to enclose any SDP in the UPDATE. 2. it's not as confusing with the "fake" retransmissions because a new CSeq is used with each UPDATE Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Siddhartha Bhakta Sent: 11 December 2006 16:05 To: [email protected] Cc: [EMAIL PROTECTED] Subject: [Sip-implementors] Retransmitted INVITE after PRACK-200OK exchange Hi All, If retransmissted INVITE is received after exchanging PRACK-200 OK (but before 200 OK of INVITE), what should be the behavior? User A User B | | |INVITE F1 Cseq:1| |--------------->| | | |(100 Trying) F2 | |<---------------| | | | 180 Ringing F3 Cseq:1 |<---------------| | PRACK F4 Cseq:2 |--------------->| | | | 200 PRACK F5 Cseq:2 |<---------------| | | |INVITE F6 Cseq:1| |--------------->| | | | 180 Ringing F7 Cseq:1 |<---------------| ?????? | | | | | 500 F7 CSeq:1 |<---------------| ?????? | | The F6 in the above example is exactly copy of F1. What should UserB send in this case? 180 with (last provisional response) or 500 Server internal error as CSeq is less than last received Request i.e., PRACK. As per me, User B should send 180 provisional response even if PRACK and 200 OK of PRACK is exchnaged. I am refering sec 17.2.1 of RFC3261 "If a request retransmission is received while in the "Proceeding" state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission." Can anybody confirm the same? Some of the SIP vendors are using retransmissted INVITE like above as the tools to keep alive the signaling pinhole. I need to know whether this retransmitted INVITE shall be rejected by 500 or not. If not, then possibly those network vendors are doing anything wrong. Though, they are sending re-INVITE with updated Cseq after initial INVITE transction is over. My question is only for the time duration when INVITE transction is not over. Thanks in advance. Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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
