100rel module sending PRACK to wrong request URI during parallel forking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 11, 2008 at 10:29 AM, Ruud Klaver <ruud at ag-projects.com> wrote:

> > My solution is different though, I fixed this at the dialog level
> > rather than in the 100rel module. The reason is because if the
> > dialog record-routes, then setting the target alone in the PRACK
> > request URI is not sufficient, since the route set still uses the
> > route set of the other UAS. This might not be a big problem if
> > there's only one proxy involved, but nevertheless we should take
> > this into account.
> >
>
> Yeah I was afraid it may have been a bit of a hack. I see what you did
> there, but is there no danger in the target and route in the dialog
> struct being continually overwritten by incoming provisional
> responses? If not than this is definitely the way to go. ;)
>
>
Apart from increasing the memory usage slightly due to updating of target
URI and RR, it should be okay I think. And the updating only occurs when the
tag is different, so that should filter this out a bit.



> > I've also replace the assertion when unexpected PRACK is received
> > with responding it with 400. Btw you should always disable assertion
> > (with -DNDEBUG) in the release product, and in this case the PRACK
> > will just be ignored rather than terminating the app. So it's not a
> > crash. ;-)
> >
> That is true, but I am still very much debugging...
>
>
This might help: :)
 http://trac.pjsip.org/repos/wiki/FAQ#assert


Also, from RFC 3262:
>
>    If a PRACK request is received by the UA core that does not match
> any
>    unacknowledged reliable provisional response, the UAS MUST respond
> to
>    the PRACK with a 481 response.
>
> Not sure if it applies to this situation, but 481 may be a more
> appropriate response.
>

Could be. But 481 has a nasty side effect that terminates the dialog (in the
UAC), and since we don't actually fork the dialog in the UAC, that would
mean the whole call will be torn down. Or something in that effect, need to
experiment more to find out if this is the case.


> Oh and thanks for the fix.
>
>
Thanks for the report and patch in the first place!

Cheers
 Benny



> Ruud Klaver
> AG Projects
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080911/8f8fccba/attachment.html 


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux