[OpenSIPS-Users] Need ideas to tamper with CSeq

Cindy Leung cinthia721 at gmail.com
Mon Apr 4 20:49:36 CEST 2011 

I have used what you suggested below and is working great for us.  Thank you!


On Mar 31, 2011, at 7:40 PM, Ovidiu Sas wrote:

> Well, in the mean time, you can use the following workaround: let the
> phone register over tcp and perform authentication and for subsequent
> calls coming from the registered endpoint (tcp/IP/port) you don't need
> to authenticate the INVITE - just reuse the existing authenticated TCP
> connection.  Like this there will be a single INVITE before the
> CANCEL.
> 
> 
> Regards,
> Ovidiu Sas
> 
> On Thu, Mar 31, 2011 at 7:14 PM, Daniel Goepp <dan at goepp.net> wrote:
>> Thanks Ovidiu,
>> 
>> 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.
>> 
>> Oh well, that's life :(
>> 
>> -dg
>> 
>> 
>> On Thu, Mar 31, 2011 at 3:22 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>>> 
>>> The sequence is totally broken.
>>> You can try to modify the Cseq and loop the CANCEL but the proper
>>> thing to do here is to get a fix from the SIP UA manufacturer or get
>>> rid of the phone and use a good one.
>>> 
>>> 
>>> Regards,
>>> Ovidiu Sas
>>> 
>>> On Thu, Mar 31, 2011 at 4:10 PM, Daniel Goepp <dan at goepp.net> wrote:
>>>> 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:
>>>> 
>>>> 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.
>>>> 
>>>> Thanks
>>>> 
>>>> -dg
>>>> 
>>>> 
>>>> On Thu, Mar 31, 2011 at 11:36 AM, Ovidiu Sas <osas at voipembedded.com>
>>>> wrote:
>>>>> 
>>>>> 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 <dan at 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 <osas at 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 <dan at 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
>>>>>>>> <osas at 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 <dan at 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
>>>>>>>>>> <osas at voipembedded.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Mar 31, 2011 at 10:37 AM, Cindy Leung
>>>>>>>>>>> <cinthia721 at 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 at lists.opensips.org
>>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Users mailing list
>>>>>>>>>> Users at lists.opensips.org
>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> 
>>>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

More information about the Users mailing list