[OpenSIPS-Users] Need ideas to tamper with CSeq

[Ovidiu Sas]

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
>
>