The sequence is totally broken. You can try to modify the Cseq and loop the CANCEL but the proper thing to do here is to get a fix from the SIP UA manufacturer or get rid of the phone and use a good one.
Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 4:10 PM, Daniel Goepp <d...@goepp.net> wrote: > My first response to this got rejected as I was just over the body size > limit for the forum. I'm posting as an attachment this time: > > You are exactly correct in your read back ;) Here is a trace, I think I > removed everything. 1.1.1.1 is my office, where both number 1111 and 2222 > are registered from. 2.2.2.2 is our proxy, and 3.3.3.3 is another openSIPS > server acting as a redirect server. > > Thanks > > -dg > > > On Thu, Mar 31, 2011 at 11:36 AM, Ovidiu Sas <o...@voipembedded.com> wrote: >> >> Are you saying that the caller is sending an INVITE with CSeq 1, get's >> challenged, sends back an authenticated INVITE with CSeq 2 and when >> the call is aborted, the client that generated the second INVITE with >> Cseq 2 is sending a CANCEL with CSeq 1? >> Can you post a trace of such scenario? >> You can remove all the sensitive info from the trace. >> >> >> Regards, >> Ovidiu Sas >> >> On Thu, Mar 31, 2011 at 2:19 PM, Daniel Goepp <d...@goepp.net> wrote: >> > It has more to do with what OpenSIPS is receiving, not sending. We get >> > the >> > first INVITE from the endpoint, challenge it, then get another INVITE >> > from >> > the endpoint, and it is incrementing the CSeq on the second INVITE. We >> > have >> > no control over what the endpoint does with Cseq, unfortunately. >> > >> > -dg >> > >> > >> > On Thu, Mar 31, 2011 at 10:53 AM, Ovidiu Sas <o...@voipembedded.com> >> > wrote: >> >> >> >> Based on how the problem was described here, the issue is with how >> >> opensips was configured: the second INVITE sent by opensips should >> >> have the same CSeq as the initial INVITE (assuming that you perform >> >> uac authentication in opensips). >> >> Are you performing uac authentication in opensips? >> >> >> >> >> >> Regards, >> >> Ovidiu Sas >> >> >> >> On Thu, Mar 31, 2011 at 1:49 PM, Daniel Goepp <d...@goepp.net> wrote: >> >> > Thanks for the feedback Ovidiu. >> >> > >> >> > The GW appears to handle the INVITEs fine, which is how the >> >> > transaction >> >> > CSeq >> >> > gets updated to 2. The problem occurs when we get the CANCEL, which >> >> > has >> >> > a >> >> > CSeq of 1, not 2. We will investigate some of the ideas you propose >> >> > here. >> >> > We have opened a ticket with the endpoint manufacture, but you know >> >> > what >> >> > that process is like I'm sure ;) >> >> > >> >> > -dg >> >> > >> >> > >> >> > On Thu, Mar 31, 2011 at 10:36 AM, Ovidiu Sas <o...@voipembedded.com> >> >> > wrote: >> >> >> >> >> >> I assume that this is a hack because the GW is not able to properly >> >> >> handle the second INVITE (with auth header) that has the same Cseq >> >> >> as >> >> >> the initial INVITE (despite the fact that those two INVITEs are on >> >> >> different branch-es). As a workaround, the CSeq was probably >> >> >> tempered >> >> >> in the local_route. >> >> >> >> >> >> You could try to intercept the CANCEL when it hits the main route, >> >> >> replace the CSeq and the forward the CANCEL back to yourself and it >> >> >> may work. This is ugly and it needs to be properly implemented as >> >> >> it >> >> >> may break good clients. >> >> >> >> >> >> >> >> >> The proper solution here would be to add a new server in front of >> >> >> the >> >> >> GW, a server that will be able to handle the two INVITEs (with and >> >> >> without auth header) with the same CSeq number. One solution would >> >> >> be >> >> >> an opensips server configured in b2b mode. This should give you a >> >> >> clean implementation and no hacks in the config. >> >> >> >> >> >> >> >> >> Regards, >> >> >> Ovidiu Sas >> >> >> >> >> >> On Thu, Mar 31, 2011 at 12:55 PM, Daniel Goepp <d...@goepp.net> >> >> >> wrote: >> >> >> > I don't mean to step on Cinthia's toe here, but I would like to >> >> >> > add a >> >> >> > little >> >> >> > to her comments / questions in response some follow ups here. The >> >> >> > problem >> >> >> > being presented has been acknowledged as a "bad" device, in >> >> >> > violation >> >> >> > of >> >> >> > the >> >> >> > RFC. And although it's not popular to work around issues, >> >> >> > sometimes >> >> >> > it >> >> >> > is >> >> >> > necessary, and one of the great things about OpenSIPS is how >> >> >> > flexible >> >> >> > and >> >> >> > powerful it is. The only problem here is the CANCEL, all other >> >> >> > signaling >> >> >> > including the BYE appear to work fine with this phone. Calls >> >> >> > complete >> >> >> > and >> >> >> > end just fine in all other cases. I agree that perhaps a proxy >> >> >> > shouldn't >> >> >> > have to do this, it is not an absolute in the real world that it >> >> >> > would >> >> >> > never >> >> >> > have to. So this comes back to the initial question, and >> >> >> > regardless >> >> >> > of >> >> >> > best >> >> >> > practice, is there a way when OpenSIPS receives a CANCEL to "help" >> >> >> > it >> >> >> > by >> >> >> > incrementing it's CSeq for it? >> >> >> > >> >> >> > Thanks >> >> >> > >> >> >> > -dg >> >> >> > >> >> >> > >> >> >> > On Thu, Mar 31, 2011 at 7:48 AM, Ovidiu Sas >> >> >> > <o...@voipembedded.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> On Thu, Mar 31, 2011 at 10:37 AM, Cindy Leung >> >> >> >> <cinthia...@gmail.com> >> >> >> >> wrote: >> >> >> >> > I guess I wasn't being clear enough in the call flow. I assume >> >> >> >> > the >> >> >> >> > CSeq >> >> >> >> > in the CANCEL has to be the same as the second INVITE. >> >> >> >> > >> >> >> >> > 1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone >> >> >> >> > ACK'd. >> >> >> >> > I believe the transaction is over at this point. >> >> >> >> > 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the >> >> >> >> > INVITE >> >> >> >> > and >> >> >> >> > send back 180. Phone now sends out a CANCEL, but the CSeq is >> >> >> >> > not >> >> >> >> > the >> >> >> >> > same >> >> >> >> > as INVITE #2. >> >> >> >> > >> >> >> >> > As far as I can tell, everything else (ruri, call-id...) is the >> >> >> >> > same >> >> >> >> > except for CSeq. >> >> >> >> >> >> >> >> Exactly! You broke the CSeq between caller and callee. A proxy >> >> >> >> should never do that! >> >> >> >> Even if you fix somehow your CANCEL issue, calls will never >> >> >> >> complete. >> >> >> >> The 200ok will have a different CSeq then the initial INVITE (for >> >> >> >> the >> >> >> >> caller) and it will be discarded (by the caller). >> >> >> >> Also, BYE will not work. >> >> >> >> You have bigger issues here then just a CANCEL. >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> Ovidiu Sas >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Users mailing list >> >> >> >> Users@lists.opensips.org >> >> >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Users mailing list >> >> >> > Users@lists.opensips.org >> >> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > >> >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Users mailing list >> >> > Users@lists.opensips.org >> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > >> >> > >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users@lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users