Thanks for the feedback Ovidiu.<br><br>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 ;)<br>
<br>-dg<br><br><br><div class="gmail_quote">On Thu, Mar 31, 2011 at 10: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;">
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>
<font color="#888888">Ovidiu Sas<br>
</font><div><div></div><div class="h5"><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 little<br>
> to her comments / questions in response some follow ups here. The problem<br>
> being presented has been acknowledged as a "bad" device, in violation of the<br>
> RFC. And although it's not popular to work around issues, sometimes it is<br>
> necessary, and one of the great things about OpenSIPS is how flexible and<br>
> powerful it is. The only problem here is the CANCEL, all other signaling<br>
> including the BYE appear to work fine with this phone. Calls complete and<br>
> end just fine in all other cases. I agree that perhaps a proxy shouldn't<br>
> have to do this, it is not an absolute in the real world that it would never<br>
> have to. So this comes back to the initial question, and regardless of best<br>
> practice, is there a way when OpenSIPS receives a CANCEL to "help" it 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>> 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 the 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 ACK'd.<br>
>> > I believe the transaction is over at this point.<br>
>> > 2. Phone sends out INVITE #2 with auth, OpenSIPS accepts the INVITE and<br>
>> > send back 180. Phone now sends out a CANCEL, but the CSeq is not the same<br>
>> > as INVITE #2.<br>
>> ><br>
>> > As far as I can tell, everything else (ruri, call-id...) is the 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 complete.<br>
>> The 200ok will have a different CSeq then the initial INVITE (for 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>
</div></div></blockquote></div><br>