[reSIProcate] [resiprocate] Ignore trailing null bytes in SIP keepalives (#38)

[Scott Godin]

We don't process Stun packets today on the TCP transports (not really sure if we ever would - RFC5626 forbids it), but the first byte of a stun request is a NULL, this logic could end up eating the first byte of a stun request.  We could always fix the logic up if we add STUN add a future date.  

I'm a little hesitant to merge this change - it seems to me the right thing to do, would be to fix Asterisks / PJSIP keepalives to not have a trailing null.  RFC5626 section 4.4.1 defines CRLF and CRLFCRLF only - no trailing nulls.  I'm also good with making us more forgiving on the receiving side, as long as we are not making compromises.   Anyone else have thoughts on this?

---
Reply to this email directly or view it on GitHub:
https://github.com/resiprocate/resiprocate/pull/38#issuecomment-188846241
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20160225/8d775e9d/attachment.htm>