[asterisk-dev] [Code Review]: Allow empty display name if callerid is set to an empty string.
amorsen
reviewboard at asterisk.org
Wed Aug 3 04:50:36 CDT 2011
> On Aug. 2, 2011, 3:15 p.m., jrose wrote:
> > I'm taking this one back to the drawing board. I have a feeling the changes this patch makes are taking the long road to a much more simple solution.
I am sorry to hear that. The changes seemed comparatively small and the patch solved a problem for us.
- amorsen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1340/#review3975
-----------------------------------------------------------
On Aug. 2, 2011, 2:30 p.m., jrose wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1340/
> -----------------------------------------------------------
>
> (Updated Aug. 2, 2011, 2:30 p.m.)
>
>
> Review request for Asterisk Developers and David Vossel.
>
>
> Summary
> -------
>
> This patch addresses an issue where Avaya IP500 requires SIP invites not to include the callerid information in quotes in the from header.
> The patch was provided by the reporter, but required some minor changes to meet coding standards and to be in line with the way things are done in trunk.
>
> Note: Ignore added verb statements. They are being pulled.
>
>
> 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/1340/diff
>
>
> Testing
> -------
>
> As far as I could tell, with this patch the only way to get an empty caller id string was to manually set it with dialplan to set caller ID. This is fine for trunking and peerage I think.
>
> Test Scenario 1:
>
> SIP Peers:
> Steve - just a regular realtime sip peer with no remarkable qualities
> Jitsi - no caller id manually set, goes through as Jitsi
>
> [jitsi]
> type=peer
> context=sipphones
> host=dynamic
> disallow=all
> secret=secret
> allow=gsm
> allow=h264
>
> SIP Jitsi to Steve call:
> exten => 2008,1,NoOp(Set CallerID)
> exten => 2008,n,NoOp(CallerID = ${CALLERID(name)})
> exten => 2008,n,Dial(SIP/Steve,120)
>
> In this case, the callerid was set to "Jitsi" and the From header included "Jitsi" in the display name, presumably forced by the Jitsi client.
>
> Test scenario 2:
>
> Sip peer - Steve (as above)
> Dahdi peer - caller id "Oerst Oernymann" (but with umlauted 'O's instead of 'Oe's)
>
> exten => 2008,1,NoOp(Set CallerID)
> exten => 2008,n,NoOp(CallerID = ${CALLERID(name)})
> exten => 2008,n,Dial(SIP/Steve,120)
>
> In this case, the callerid was set to "asterisk" and the from header followed suit.
>
>
> Test Scenario 3 and 4:
> as above, except...
>
>
> exten => 2008,1,NoOp(Set CallerID)
> exten => 2008,n,Set(CALLERID(name)=)
> exten => 2008,n,NoOp(CallerID = ${CALLERID(name)})
> exten => 2008,n,Dial(SIP/Steve,120)
>
> And in both of these cases, Jitsi receives no from name for the invite and no "Display-name" is included until after the invite has been responded to.
>
>
> So all in all, this patch appears to do what it claimed to with comparably minimal impact.
>
>
> Thanks,
>
> jrose
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110803/eab1d01e/attachment.htm>
More information about the asterisk-dev
mailing list