Summary:ASTERISK-16198: [patch] SIP display-name needed to be empty for Avaya IP500
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2010-06-03 03:46:24Date Closed:2011-08-10 10:49:25
Versions:Frequency of
Environment:Attachments:( 0) ast1628-empty-display-name.patch
( 1) astsvn-empty-display-name.patch
( 2) issue17451_empty_sip_cliname-

a customer of ours has a customer which uses the Avaya IP500. It
features some kind of "directory service" -- a phone book. This
phone book also has the feature that it only does lookups if no
name is already present:

(yes, you need a login, I don't have it either)

> Name matching is not performed when a name is supplied with the
> incoming call, for example QSIG trunks.

This means that for SIP calls, the name matching is not performed
when the "display-name" part of the From-header is set.

Unfortunately, chan_sip does not allow the CALLERID(name) to be empty.
If it's empty, it sets it to the CALLERID(num), so you get:

From: "0123456789" <sip:0123456789@server>

Quick ABNF refresher:

From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
display-name   =  *(token LWS)/ quoted-string
addr-spec =  SIP-URI / SIPS-URI / absoluteURI

For my purposes I would need one of these From headers:

(1) From: sip:0123456789@server <-- no display name
(2) From: <sip:0123456789@server> <-- empty display name
(3) From: "" <sip:0123456789@server> <-- empty display name

I've tested option (2) on the Avaya IP500 and it fixes so name matching
works: the phone book does what it's supposed to.

I chose option (2) over (1) and (3) because:
(1) Might cause incompatibilities with bad SIP parsers.
(3) Is overly explicit that the name is empty when we actually mean
   that the name is not set.

The supplied patches do just this:
* Allow CALLERID(name) to be empty.
* If CALLERID(name) is empty, send the From-header as (2).

The only drawback I see is that some people that expect the display-name
to be automatically set to CALLERID(num) would be disappointed. This is
usually fixed by a simple dialplan change though.

Walter Doekes
Comments:By: Paul Belanger (pabelanger) 2010-06-03 08:26:15

I'd suggest posting this to reviewboard or asterisk-dev (mailing list or channel) to get feedback on this.  Ideally we don't want to break existing functionality.

By: Leif Madsen (lmadsen) 2010-06-03 10:42:37

Russell, John, and I agree that this seems like this is the way chan_sip should be working.

But as this is a significant change in behaviour for chan_sip, this change will only go into trunk.

Thanks for the patch! I've updated this to Ready for Testing.

By: Walter Doekes (wdoekes) 2010-09-23 13:31:13

There's a bug in both patches: when pedanticsipchecking is on, n is not expected to be NULL. You'll need a if (!ast_strlen_zero(n)) {} around ast_uri_encode(n, tmp_n, sizeof(tmp_n), 0); and n = tmp_n;

By: Walter Doekes (wdoekes) 2011-01-06 04:35:08.000-0600

I've updated the patch for (Not that it would go in 1.6, but it includes the fix that I missed initially.)

By: Walter Doekes (wdoekes) 2011-04-28 02:00:57

Would "trunk" be 1.10 or 1.12 now? ;)

By: dtryba (dtryba) 2011-06-16 05:21:34.856-0500

Thanks Walter, this patch works fine and fixes this weird behavior. Since the Avaya KB01093704 has the following workaround "solution", including this in * is a must IMHO:

*Problem Fix/Workaround/Solution*

Working as per design.

*Resolution Plan*

Working as per design. If user needs this feature to be included they need to raise a New Feature Request with AVAYA

By: Jonathan Rose (jrose) 2011-08-10 10:49:25.193-0500

r331371 | jrose | 2011-08-10 10:45:57 -0500 (Wed, 10 Aug 2011) | 14 lines

SIP display-name needed to be empty for Avaya IP500

In order to address a compatability issue with certain features on certain devices
which rely on display name content to change behavior, initreqprep in chan_sip.c
has been changed to no longer substitute cid_number into the display name when
cid_name isn't present.  Instead, it will send no display name in that case.

(closes issue ASTERISK-16198)
Reported by: Walter Doekes

Review: https://reviewboard.asterisk.org/r/1341/