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