| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
Re: [reSIProcate] [resiprocate] Ignore trailing null bytes in SIP keepalives (#38)
- From: Scott Godin <notifications@xxxxxxxxxx>
- Date: Thu, 25 Feb 2016 07:40:25 -0800
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.
- References:
- Prev by Date: Re: [reSIProcate] [resiprocate] Corrected call to ErrLog macro on MacOS/iOS (#33)
- Next by Date: Re: [reSIProcate] [resiprocate] Ignore trailing null bytes in SIP keepalives (#38)
- Previous by thread: [reSIProcate] [resiprocate] Ignore trailing null bytes in SIP keepalives (#38)
- Next by thread: Re: [reSIProcate] [resiprocate] Ignore trailing null bytes in SIP keepalives (#38)
- Index(es):