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