Shouldn't the CSeq in last 408 be 1 INVITE instead of 1 ACK?
Dushyant P S Dhalia Teodor Georgiev wrote:
Well,Under "modifying the Cseq" I mean that I take the one from the [3456]XX reply and put ACK as a method as you cansee in the provided by me example: CSeq: 1 ACK I am not incrementing the CSeq value at all. Indeed, here is once again the entire dialog dumped: INVITE sip:300...@192.168.2.40 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.100:5060;branch=z9hG4bK-660326804;rport Content-Length: 0From: "600"<sip:6...@192.168.2.100>; tag=34643261383432383133633401323439333333353539Accept: application/sdp User-Agent: tgSIP To: "600"<sip:6...@192.168.2.100> Contact: sip:300...@192.168.2.100:5060 CSeq: 1 INVITE Call-ID: 968610893062571398367193 Max-Forwards: 70 SIP/2.0 408 Request Timeout Via: SIP/2.0/UDP 192.168.2.100:5060;branch=z9hG4bK-660326804;rportFrom: "600" <sip:6...@192.168.2.100>;tag=34643261383432383133633401323439333333353539To: "600" <sip:6...@192.168.2.100> Call-ID: 968610893062571398367193 CSeq: 1 INVITE Content-Length: 0 ACK sip:300...@192.168.2.40 SIP/2.0 Content-Length: 0 Via: SIP/2.0/UDP 192.168.2.100:5060;branch=z9hG4bK-660326804;rportFrom: "600" <sip:6...@192.168.2.100>;tag=34643261383432383133633401323439333333353539User-Agent: tgSIP To: "600" <sip:6...@192.168.2.100> CSeq: 1 ACK Call-ID: 968610893062571398367193 SIP/2.0 408 Request Timeout Via: SIP/2.0/UDP 192.168.2.100:5060;branch=z9hG4bK-660326804;rportFrom: "600" <sip:6...@192.168.2.100>;tag=34643261383432383133633401323439333333353539To: "600" <sip:6...@192.168.2.100> Call-ID: 968610893062571398367193 CSeq: 1 ACK Content-Length: 0
Shouldn't the CSeq be 1 INVITE instead of 1 ACK.
What kind of darn errors am I making?----- Original Message ----- From: "Iñaki Baz Castillo" <i...@aliax.net>To: "Teodor Georgiev" <teo...@visp.net.lb> Cc: <sip-implementors@lists.cs.columbia.edu> Sent: Monday, September 28, 2009 4:12 PMSubject: Re: [Sip-implementors] Constructing an ACK request (non 2XX based) in a stateless case2009/9/28 Teodor Georgiev <teo...@visp.net.lb>:Hi list,I am trying to implement something a little bit odd and against the RFC, but hope will get some help anyways :)There is a SIP UAC (used for events notification) written by a person who has left the project and will not fix it. That SIP UAC has a really silly bug - it doesn't send back ACKs to 4XX//5XX responses. I do not have accessto the source of his code so I can't fix the trouble there.Instead I am writing my own mini SIP stack that would send back the ACK on behalf of the buggy UAC. I have put my app on the way as a transparent SIP stateless proxy. The issue here also is that I do not keep a copy of the original INVITE, so I am trying to construct my ACK based on the received 4XX message:* I keep the From, To, Call-ID, From and VIA fields as-it-is from the 4XX messageOk* The Cseq is modified according to the RFCACK for a [3456]XX response is part of the INVITE transaction so CSeq is not incremented. ACK for 2XX response is a new transaction, however CSeq is not incremented.This is, CSeq value in ACK for any response MUST match CSeq value in the INVITE.* The Request URI - I am constructing it by myself, I know that the called number is always 444302Wrong. The RURI in an ACK for a [3456]XX response MUST match the RURI of the INVITE. The RURI only changes after establishing a dialog so UAC knows the exact location of UAS (by inspecting the "Contact" in the 2XX response. If an INVITE is rejected ([3456]XX response) then a dialog hasn't take place so the RURI in the ACK doesn't change.However the other devices (Cisco 7960 SIP phones and SJPhone softphones) keep resending me the "Request Timeout" messages (or "NOT FOUND", if I configure them in a way to not accept 444302 calls)Yes, it makes sense as you did two errors.
<<attachment: dushyant_dhalia.vcf>>
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
