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:<br><br>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.<br>
<br>Thanks<br clear="all"><br>-dg<br>
<br><br><div class="gmail_quote">On Thu, Mar 31, 2011 at 11:36 AM, 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;">
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>
<font color="#888888">Ovidiu Sas<br>
</font><div><div></div><div class="h5"><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 the<br>
> first INVITE from the endpoint, challenge it, then get another INVITE from<br>
> the endpoint, and it is incrementing the CSeq on the second INVITE. We 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>> 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 transaction<br>
>> > CSeq<br>
>> > gets updated to 2. The problem occurs when we get the CANCEL, which 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 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 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 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 it<br>
>> >> may break good clients.<br>
>> >><br>
>> >><br>
>> >> The proper solution here would be to add a new server in front of 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 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>> wrote:<br>
>> >> > I don't mean to step on Cinthia's toe here, but I would like to 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 violation<br>
>> >> > of<br>
>> >> > the<br>
>> >> > RFC. And although it's not popular to work around issues, sometimes<br>
>> >> > it<br>
>> >> > is<br>
>> >> > necessary, and one of the great things about OpenSIPS is how 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 regardless<br>
>> >> > of<br>
>> >> > best<br>
>> >> > practice, is there a way when OpenSIPS receives a CANCEL to "help" 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 <<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 <<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 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>
</div></div></blockquote></div><br>