[asterisk-dev] [Code Review]: Truncate host:port when checking SIP domains and make the URI parsing API more explicit about returning host:port and not a domain

Simon Perreault reviewboard at asterisk.org
Wed Nov 9 07:03:13 CST 2011



> On Nov. 8, 2011, 8 p.m., Simon Perreault wrote:
> > Another thing: The term "domain" comes from the SIP RFC. It has a precise meaning. IMHO changing it to "hostport" is wrong and we should prefer using the SIP terms instead of defining our own equivalent terms.
> > 
> > Another reason I'm opposed to the name change is that it creates a lot of frivolous changes in the code which make svn blame|diff|merge|... harder to use.
> 
> Terry Wilson wrote:
>     > Another thing: The term "domain" comes from the SIP RFC. It has a precise meaning. IMHO changing it to "hostport" is wrong and we should prefer using the SIP terms instead of defining our own equivalent terms.
>     
>     Actually, as far as parsing is concerned, there is no such thing as a "domain". Please see the ABNF of RFC 3261. There is a "hostport" though, and it is exactly what parse_uri returns in what was labeled as "domain". There is a domainlabel which is potentially part of the hostname, which is potentially part of the host, which is potentially part of hostport. The "domain" in SIP should absolutely never contain a port (or a ':').
>     
>     > Another reason I'm opposed to the name change is that it creates a lot of frivolous changes in the code which make svn blame|diff|merge|... harder to use.
>     
>     I would rather svn blame be harder to use than for bugs to be introduced because someone actually thinks that a domain is being returned when it isn't due to poor labeling.

Wow. I was so wrong about that, it's embarrassing. Sorry about that. Please go ahead with the name change. Since the name is wrong, these would be bug fixes, not "frivolous changes".


- Simon


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1574/#review4741
-----------------------------------------------------------


On Nov. 9, 2011, 12:04 a.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1574/
> -----------------------------------------------------------
> 
> (Updated Nov. 9, 2011, 12:04 a.m.)
> 
> 
> Review request for Asterisk Developers and wdoekes.
> 
> 
> Summary
> -------
> 
> In reviewing https://reviewboard.asterisk.org/r/1533/ I noticed that going from 1.4 to 1.8, setting domain=x.x.x.x stopped matching when receiving a request to x.x.x.x. The reason is that the parse_uri function returns host:port in what was labeled the "domain" variable in 1.8 when in 1.4 the parsing was done in each individual function and the port truncated manually. For example, peer->fromdomain could be set to a host:port, even though it is specifically split into peer->fromdomain and peer->fromport other places in the code.
> 
> We can't change the parsing function because sometimes we actually use the host:port form of the result (as in when passing it to ast_sockaddr_resolve_first), so we need to do the truncation manually when appropriate. This patch does two things: 1) it renames the "domain" variables in the API functions to "hostport" to more accurately reflect what we are really returning and 2) implements a truncate_hostport function and uses it where appropriate.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 343673 
>   /branches/1.8/channels/sip/include/reqresp_parser.h 343673 
>   /branches/1.8/channels/sip/include/sip.h 343673 
>   /branches/1.8/channels/sip/reqresp_parser.c 343673 
> 
> Diff: https://reviewboard.asterisk.org/r/1574/diff
> 
> 
> Testing
> -------
> 
> Ran the SIP unit tests and SIP-related testsuite tests and saw no difference in behavior. Set domain=127.0.0.1 and verified register requests started working.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111109/473e84ca/attachment-0001.htm>


More information about the asterisk-dev mailing list