[asterisk-dev] [Code Review] Parsing of reg->username containing @domain

David Vossel dvossel at digium.com
Tue May 11 15:02:59 CDT 2010



> On 2010-05-10 11:28:50, David Vossel wrote:
> > trunk/channels/chan_sip.c, lines 11655-11704
> > <https://reviewboard.asterisk.org/r/628/diff/6/?file=9994#file9994line11655>
> >
> >     This patch changes the behavior of how the p->fromdomain is used, which is the original reason the first patch had to be reverted.
> >     
> >     Here is an example of the config that would break.
> >     
> >     -------------------------------
> >     register => user at peer_1
> >     
> >     [peer_1]
> >     fromdomain=10.10.10.10
> >     -------------------------------
> >     
> >     The expected behavior for that register line is that peer_1 will be found, and the fromdomain will take its place as the address.  This is no longer the behavior because the check for p->fromdomain is no longer done in transmit register the same way as it used to be done.
> >     
> >     The parsing code still looks great though, sorry I missed this during my last pass.
> 
> Nick Lewis wrote:
>     My apologies - I thought I had functionally tested your example but I must have been confused
> 
> David Vossel wrote:
>     You got the user at userdomain@hostdomain part right from the registry string, but this other part is the fromdomain configured in the peer definition.  I don't know how this got so complicated.  That functionality was never obvious to me until we took it out and it broke people's configs.
> 
> Nick Lewis wrote:
>     In my testing the fromdomain and tohost are being got successfully from the peer definition. Perhaps I am putting them in the wrong places. Can you please clarify the required content of the host part of the request-line, to-header and from-header in this example

This is the inconsistency I am seeing.

--------sip.conf---------------
register => user at userdomain@peer_definition

[peer_definition]
fromdomain=10.10.10.10:1111
-------------------------------

In this case we'd expect: "Request-Line: REGISTER sip:10.10.10.10:1111"
But we get:               "Request-Line: REGISTER sip:userdomain"

Also, I'm not sure if correct logic is used with the portno when p->fromdomain is used.  p->fromdomain will have the port number tacked on to the end of the string.  If the portno variable in the transmit function is anything but STANDARD_SIP_PORT it is possible two port numbers could be put onto the addr string when p->fromdomain is used.

Everything in the Message Header looks like it is consistent with previous behavior though.


- David


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


On 2010-05-06 04:21:36, Nick Lewis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/628/
> -----------------------------------------------------------
> 
> (Updated 2010-05-06 04:21:36)
> 
> 
> Review request for Asterisk Developers and David Vossel.
> 
> 
> Summary
> -------
> 
> reg->username is parsed for each registration refresh rather than once on sip reload. A previously committed change that addressed this was reverted because it did not cater for registration strings that contained a peer name in the host field. This change does. 
> 
> 
> This addresses bug 14331.
>     https://issues.asterisk.org/view.php?id=14331
> 
> 
> Diffs
> -----
> 
>   trunk/channels/sip/config_parser.c 258227 
>   trunk/channels/chan_sip.c 258227 
>   trunk/channels/sip/include/sip.h 258228 
>   trunk/main/app.c 258227 
> 
> Diff: https://reviewboard.asterisk.org/r/628/diff
> 
> 
> Testing
> -------
> 
> Passes a new unit test for parsing usernames containing domains. Passes existing unit tests. Passes peername functional test with sip.conf snippet
> 
> [general]
> register=nick at quirk
> [quirk]
> fromdomain=10.10.235.48
> 
> 
> Thanks,
> 
> Nick
> 
>




More information about the asterisk-dev mailing list