[OpenSIPS-Users] Need ideas to tamper with CSeq

[Daniel Goepp]

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