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 can see 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: 0 From: "600"<sip:6...@192.168.2.100>; tag=34643261383432383133633401323439333333353539 Accept: 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;rport From: "600" <sip:6...@192.168.2.100>;tag=34643261383432383133633401323439333333353539 To: "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;rport From: "600" <sip:6...@192.168.2.100>;tag=34643261383432383133633401323439333333353539 User-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;rport From: "600" <sip:6...@192.168.2.100>;tag=34643261383432383133633401323439333333353539 To: "600" <sip:6...@192.168.2.100> Call-ID: 968610893062571398367193 CSeq: 1 ACK Content-Length: 0 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 PM Subject: Re: [Sip-implementors] Constructing an ACK request (non 2XX based) in a stateless case 2009/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 access > to 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 > message Ok > * The Cseq is modified according to the RFC ACK 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 444302 Wrong. 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. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
