Well, in the mean time, you can use the following workaround: let the phone register over tcp and perform authentication and for subsequent calls coming from the registered endpoint (tcp/IP/port) you don't need to authenticate the INVITE - just reuse the existing authenticated TCP connection. Like this there will be a single INVITE before the CANCEL.
Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 7:14 PM, Daniel Goepp <d...@goepp.net> wrote: > Thanks Ovidiu, > > Yeah, that is pretty much the conclusion we had come to regarding the > endpoint...we were just hoping I guess to have a fix and not have to wait > for the vendor to fix the phone, which will likely take quite some time. > > Oh well, that's life :( > > -dg > > > On Thu, Mar 31, 2011 at 3:22 PM, Ovidiu Sas <o...@voipembedded.com> wrote: >> >> 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 > > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
