[reSIProcate] bad responses in TransactionState pedantic stack

[Derek MacDonald]

Looking at LazyParser::checkParsed parse failures are not idempotent.

basically, if an element cannot be parsed the LazyParser transitions to
Malformed. However, accessors in subclasses of lazyparser only call
checkparsed which is a null-op in the MALFORMED state. This could cause
unpredictable behavior.

Personally, I would want an exception to be thrown if I access an invalid
part of a message even if it has been parsed already...if there is a place
where SIP or a body requires that a string be present there is not going to
be client code that checks for an empty string.

What I really want to avoid his having to write that use PEDANTIC_STACK
differently from those that don't...

-Derek



On Wed, Mar 10, 2010 at 4:28 PM, Jason Fischl <jason.fischl at gmail.com>wrote:

> If resip is acting as a UAC in pedantic stack mode and we receive a
> response that can't be parsed, what should the stack do? For NITs,
> there isn't really a problem if you drop it on the floor since the
> stack will timeout and send a 408. For Invite transactions the
> solution is not so clear.
>
> I can think of a few options:
> 1) drop the response on the floor but do NOT continue processing -
> this may have cleanup issues since the app will never know to end the
> session.
> 2) notify the TU through an event that the session is borked. e.g. we
> could generate a dummy response and pass it to the TU
> 3) pedantic stack considered harmful - just don't do it.
>
> Note: I think the stack currently passes the partially parsed response
> up to the TU. This seems really bad!
>
> --
> Jason
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100310/6c84f367/attachment.htm>