Re: [reSIProcate] bad responses in TransactionState pedantic stack
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel