[asterisk-dev] [Code Review] Allow empty display name if callerid is set to an empty string. Take 2!

[rmudgett]

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

Ship it!


Looks ok by me.

- rmudgett


On Aug. 3, 2011, 1:42 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1341/
> -----------------------------------------------------------
> 
> (Updated Aug. 3, 2011, 1:42 p.m.)
> 
> 
> Review request for Asterisk Developers, David Vossel and rmudgett.
> 
> 
> Summary
> -------
> 
> This is basically what I was trying to do with the user submitted patch from yesterday.  After speaking with Richard, it became somewhat obvious that the approach to the patch had too much extra impact on the SIP messages when all that was really needed was specifically targeting the creation of the display name.
> 
> This approach checks strictly for a caller id name and if it isn't there, we skip the creation of the display name.  I think this should be safer in general than the previous approach.
> 
> 
> This addresses bug ASTERISK-16198.
>     https://issues.asterisk.org/jira/browse/ASTERISK-16198
> 
> 
> Diffs
> -----
> 
>   /trunk/CHANGES 330571 
>   /trunk/channels/chan_sip.c 330571 
> 
> Diff: https://reviewboard.asterisk.org/r/1341/diff
> 
> 
> Testing
> -------
> 
> Testing was similar to last time with focus on comparing the SIP messages between this branch and the normal trunk.  In this case, only the display name gets changed.
> 
> A few SIP tests from the test suite were also ran successfully.  I haven't ran the full test suite yet, but am preparing to do so.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110803/4cc82d19/attachment.htm>