[asterisk-dev] [Code Review] Stop trying to uri_encode the display name for the caller ID

[jrose]

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

(Updated 2011-06-03 10:39:36.356588)


Review request for Asterisk Developers, Russell Bryant, Matthew Nicholson, and David Vossel.


Changes
-------

Adding mnicholson on account of this newest version is stolen from his changes to trunk... which it turns out have addressed this already.


Summary
-------

Under SIP pedantic mode, this function was encoding strings meant for the display name into into a URI safe format when this was not specified in the SIP RFCs.  I also took the liberty of adding a little commentary.

pedantic mode was the default in Asterisk 1.8+


This addresses bug 18298.
    https://issues.asterisk.org/view.php?id=18298


Diffs (updated)
-----

  /branches/1.8/channels/chan_sip.c 321727 
  /branches/1.8/include/asterisk/utils.h 321727 
  /branches/1.8/main/utils.c 321727 

Diff: https://reviewboard.asterisk.org/r/1235/diff


Testing
-------

A number of different calls with user names including more interesting UTF-8 characters from a variety of characters from a variety of sources including trema (like German umlaut characters), Kanji (Japanese pictographic characters), Sanskrit (phonetic characters for one of India's languages), and Cyrillic (Russian).  Whether or not they'll display properly depends on the receiving phone... My Grandstream phone doesn't like the higher end UTF-8 characters, but all of my soft phones read them fine.

Testing involved a manually set DAHDI channel to have odd caller ID and an incoming call from another Asterisk Box sending SIP from a phone set to also have a display name with high UTF-8 chars.


Thanks,

jrose

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