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