[Home]

Summary:ASTERISK-17102: 1.4.38 does not write external callerID number into SIP From: header
Reporter:David Brillert (aragon)Labels:
Date Opened:2010-12-13 14:16:51.000-0600Date Closed:2011-06-07 14:05:32
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ANIdebug.txt
Description:Outgoing number in CALLERID(all) field is not sent to ITSP
Asterisk 1.4.38

****** ADDITIONAL INFORMATION ******

Tested an outgoing call with agi debug and SIP debug enabled and in the CLI output both name and number are set with "[2010-12-01 11:48:51]   -- Executing [s@all-outgoing-checkcid:58] Set("SIP/6010-00000060", "CALLERID(all)="John Smith" <4165552234>") in new stack" flag:
[2010-12-01 11:48:51]   -- Executing [s@all-outgoing-checkcid:58] Set("SIP/6010-00000060", "CALLERID(all)="John Smith" <4165552234>") in new stack

But the number is not sent to ITSP in the From: header
From: "John Smith" <sip:0762*100@sip.itsp.com>;tag=as21a88bd9

Full console output attached
Comments:By: David Woolley (davidw) 2010-12-14 07:53:47.000-0600

You need to provide your sip.conf.  However, this looks like a support issue at the moment.  You may want to investigate RPID.
By: David Brillert (aragon) 2010-12-14 07:56:46.000-0600

[general]
context         =  default-incoming-guest
callevents      =  yes
alwaysauthreject =  yes
jbenable        =  no
t38pt_udptl     =  yes
progressinband  =  never
externip        =  216.235.14.204
localnet        =  192.168.0.0/255.255.0.0
localnet        =  10.0.0.0/255.0.0.0
localnet        =  172.16.0.0/12
localnet        =  169.254.0.0/255.255.0.0
bindport        =  5060
bindaddr        =  0.0.0.0
rtpkeepalive    =  0
limitonpeers    =  yes
notifyringing   =  yes
notifyhold      =  yes
realm           =  asterisk
useragent       =  Asterisk PBX
maxexpirey      =  3600
defaultexpirey  =  120
recordhistory   =  no
autocreatepeers =  no
srvlookup       =  yes
videosupport    =  yes
directrtpsetup  =  no
disallow        =  all
allow           =  ulaw
allow           =  alaw
allow           =  g722
allow           =  g726
allow           =  g723
allow           =  gsm
allow           =  g729
allow           =  slin
allow           =  ilbc
allow           =  lpc10
allow           =  speex
allow           =  adpcm
allow           =  h261
allow           =  h263
allow           =  h263p
allow           =  h264
tos_sip         =  CS0
tos_audio       =  ef
tos_video       =  CS0
pedantic        =  no
allowexternaldomains =  no
allowexternalinvites =  no
autodomain      =  no
relaxdtmf       =  no
trustrpid       =  no
sendrpid        =  yes
promiscredir    =  no
usereqphone     =  yes
compactheaders  =  no
#include "sip-register.conf"
#include "default/sip.conf"
#include "default/sip-extras.conf"
#include "test/sip.conf"
#include "test/sip-extras.conf"
#include "sip-extras.conf"

I don't think this is a support issue since the name and number is correctly set on an external PRI circuit.  The outgoing number only fails on SIP trunk calls.
By: David Brillert (aragon) 2010-12-14 08:02:48.000-0600

[0762*100]
type            =  friend
username        =  0762*100
fromuser        =  0762*100
fromdomain      =  sip.itsp.com
secret          =  scrubbed
host            =  sip.itsp.com
dtmfmode        =  auto
rfc2833compensate =  no
nat             =  no
canreinvite     =  no
insecure        =  port,invite
qualify         =  yes
disallow        =  all
allow           =  ulaw
allow           =  gsm
callerid        =  "John Smith" <5555551234>
accountcode     =  0762*100
amaflags        =  default
trustrpid       =  no
sendrpid        =  no
context         =  default-0762*100-incoming
By: David Woolley (davidw) 2010-12-14 08:04:22.000-0600

You've set fromuser.  It is behaving correctly.  This is a support issue.

Drafted before your update:

You need to provide the contents of the includes.

Some SIP trunk providers rely on the From: header to indentify the customer.  Even if yours doesn't, you may have configured as though they did.

Remote Party ID headers were designed to allow caller-ID to be communicated in such circumstances, but they are not enabled by default.

Also, of course, PSTN gateways shouldn't normally trust caller IDs that don't match a number they know for the immediate caller.
By: David Brillert (aragon) 2010-12-14 08:06:09.000-0600

ahh

-sendrpid = no
+sendrpid = yes

Does fix the ANI problem
thanks Davidw
By: David Brillert (aragon) 2010-12-14 08:07:55.000-0600

This can be closed out