[OpenSIPS-Users] Need ideas to tamper with CSeq

[Daniel Goepp]

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110331/1007e5be/attachment.htm>