Hi Teodor, I think Dale's earlier response is key, and here's why. The first 408 response you get back doesn't have a tag on the To header. Because of this, the ACK that you have contructed doesn't have one either.
The ACK that you send back is perfectly constructed, except for the fact that there is to tag on the To header. You have followed the rule in 3261 17.1.1.3: The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. But the response you got was essentially malformed. Note the following from 3261 8.2.6.2: However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The ACK that you sent without a To tag would be recognized as a "root" transaction, not associated with anything. From the trace though, it appears that the ACK is sort-of being recognized as a resend of the original INVITE and it is re-sending the final response code for that. This would suggest that the UAS you are contacting isn't using the method as part of the identifier for the transaction (note the matching rules in 3261 17.2.3). There is definitely a problem with the UAS (since it isn't sending the To tag) and it _may_ be by design that your UAC doesn't send an ACK for a malformed response. I would start by trying to figure out why your UAS(s) don't send that To tag in the final response. David On Tue, Sep 29, 2009 at 10:26:49AM +0300, 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 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 > > !DSPAM:4ac1b738242657079271252! > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
