Weird Issue With Set(CALLERID(name)=string);

Home » Asterisk Users » Weird Issue With Set(CALLERID(name)=string);
Asterisk Users 12 Comments

Hi folks,

We’ve been having a weird issue… It is happening more often in the last few months…

Most inbound calls, we have in our dialplan before Queue():


So when the call rings a member, softphone will show this string ….

The issue is that sometimes the string showing in the softphone is not the same. Its a string from a past call, in the latest case I’ve seen, from about 40 days ago!!

User took a screenshot, I’ve searched for that uniqueid showing in softphone in cdr, and that string was valid for a different call 40 days ago!!

I searched full log, and Set() sets the correct string… I can’t figure why softphone shows a string from a past call !!


Any hints ?

12 thoughts on - Weird Issue With Set(CALLERID(name)=string);

  • I would leave tcpdump running capturing port 5060 so you can load it onto wireshark and have a look at the sip headers. That will tell you if the SIP is incorrect or if its a problem with the client.

  • You’re right, seems like a nice way to debug. Regarding that, how would the impact be affected running it on asterisk box? I guess only port 5060 is not too bad

  • Very little as the amount of data being captured is quite small. We have it running on our production servers which routinely handle a couple of hundred concurrent calls.

    This is the script we use to start off the capture. It uses rolling capture files so we will always have the last X number of capture logs. It works very well and we have a custom system which enables us to search for calls and request traces for them for when we have to diagnose problems.

    #!/bin/bash cd /var/lib/asterisk/siptraces DATE=`date +%Y%m%d%H%M%S`
    TRACEFILE=/var/lib/asterisk/siptraces/$DATE-siptrace.pcap nohup /usr/sbin/tcpdump -p -i eth0 -s 0 port 5060 -w $TRACEFILE -C 10 -W
    500 &

  • Second thought, that would only allow me to know if there is a problem on asterisk or softphone.

    Because the old callerid(name) that was presented on the softphone, belonged to a call made to a different peer, I doubt that it would be a softphone problem.

    Our softphones are fixed with the same peer/extension .. if the wrong callerid were originally called to the same peer.. I guess that would be worth it..

    even so, I will try and measure the impact on performance, however if asterisk did send the wrong string, how could I debug that??

  • The SIP trace will give you an idea is perhaps something is becoming corrupted. If you keep a log of the asterisk console output (asterisk
    -rvvv) then you will see what it attempts to set the callerid to and any errors.

    Another tip. When you have a look at the sip trace you will see the call-id. If you make a note of this and run the following replacing the call-id and the trace file with the appropriate values it will display the sip trace in a very nice human readable format. tshark comes with the wireshark pakage and ngrep is part of epel repository if you are running CentOS.

    tshark -t ad -r ‘$tracefile’ -R ‘sip.Call-ID contains $callID’ -w – |
    ngrep -I – -W byline -t

  • wrote on 01/16/2014 08:55:31 AM:

    500 &

    Not to derail the conversation, Gareth, but do you leave this running full time on your asterisk boxes or just turn it on when you are trying to track problems?

    On average, how far back can you go for looking at problems?

  • Hi,

    I transfered the capture to my local machine and opened it in wireshark, I
    can search from there:
    –> SIP Display info:

    but I will add your comment to my notes.

    I’ve already searched the asterisk FULL log, and seen the Set() line .. shows the correct string, that should have been displayed on softphone …

  • Its normally running full time so if someone reports a problem with a call we can look at the logs and find out exactly what happened. We keep asterisk verbose logs for 3 months, sip traces currently for about a month, and uk-isup traces for a couple of weeks.

    Most carriers will do something similar. BT for example keep all of their SS7 signalling for 48 hours.

    Regards Gareth

  • And we just figured that sound quality issues were not due to tcpdump .. anyway sorry to troll this feed, and thank you for your sugestion