[OpenSIPS-Users] Need ideas to tamper with CSeq

[Ovidiu Sas]

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