According to specification, a name-addr is not allowed to have any white
space between the host and the parameter list like so:
<sip:alice@example.com; wrong=no_space_please>. However, this does occur
in the "wild" and just "looking" at the address, it is clear that those
parameters should belong to the URI. Therefore, those extra spaces
should really be allowed so the fix is essentially relaxing the rules a
bit.
Then, even if the old rules were more strict, we shouldn't end up in a
loop. It is unclear exactly what the customer who reported the issue ran
into but ultimately, due to the above poor parsing, we ended up with a
ParametersSupport that had "bad values" it couldn't parse and got stuck
in an endless loop.
So, there were several contributing issues (it seems).
Poor parsing of the address-spec, which then exposed
a bug in ParametersSupport that could cause an infinite loop
This fix addresses both. More robust (relaxed) parsing and fix in the
ParametersSupport to detect and bail out if we are not making any
progress.
According to specification, a name-addr is not allowed to have any white space between the host and the parameter list like so:
<sip:alice@example.com; wrong=no_space_please>. However, this does occur in the "wild" and just "looking" at the address, it is clear that those parameters should belong to the URI. Therefore, those extra spaces should really be allowed so the fix is essentially relaxing the rules a bit.Then, even if the old rules were more strict, we shouldn't end up in a loop. It is unclear exactly what the customer who reported the issue ran into but ultimately, due to the above poor parsing, we ended up with a ParametersSupport that had "bad values" it couldn't parse and got stuck in an endless loop.
So, there were several contributing issues (it seems).
This fix addresses both. More robust (relaxed) parsing and fix in the ParametersSupport to detect and bail out if we are not making any progress.