[OpenSIPS-Users] Need ideas to tamper with CSeq

Ovidiu Sas osas at voipembedded.com
Fri Apr 1 00:22:48 CEST 2011


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



More information about the Users mailing list