Summary:ASTERISK-09489: Set(CALLERID(num)=xxx) on SIP trunk not working, but on IAX works fine
Reporter:John Babina (versimedia)Labels:
Date Opened:2007-05-22 11:59:02Date Closed:2007-06-06 08:37:58
Versions:Frequency of
Description:Provider: VoicePulse Connect

Situation, call comes in to Asterisk server, and I immediately Dial out to another number.

Before dialing, I do:


If dialing through IAX2, this works fine and I see 203-653-9999 on end call.  If dialing through SIP, I see the Caller ID info from the original caller.

The only thing I change between tests is changing "IAX2" to "SIP" in two outgoing lines.

If I do:


In SIP both the name and number appear as 203-653-9999.

I have contacted VoicePulse and they ran packet checks on the calls as they came in with different scenarios -- the data seems to be set on the "invite" packets,  so they say it is before they would make any changes.

It seems as if the Set(CALLERID(num)=) option is not changing the data in the SIP protocol for some reason but is under IAX2.  The other strange thing is if I set (name) to a number, both the number and name come up as the number set.

This is reproducible 100% of the time.

There are no other CALLERID or SetCallerID lines in the files, I scanned all under unix to confirm.


More info available here:


also here is a trace showing I am setting CALLERID(num), the data that comes through on the end phone is the source number and name, not the new set #.  Voicepulse said that they are seeing the source number come through to them and do not see any indication of the new number.


   -- Executing [12036531111@voicepulse-in:1] Answer("SIP/MUQ19HgW36-081cxxxx", "") in new stack
   -- Executing [12036531111@voicepulse-in:2] Dial("SIP/MUQ19HgW36-081cxxxx", "Local/12038384444@outgoing/n") in new stack
   -- Called 12038384444@outgoing/n
   -- Executing [12038384444@outgoing:1] NoOp("Local/12038384444@outgoing-3ab6,2", "") in new stack
   -- Executing [12038384444@outgoing:2] Set("Local/12038384444@outgoing-3ab6,2", "CALLERID(num)=2036539999") in new stack
   -- Executing [12038384444@outgoing:3] Goto("Local/12038384444@outgoing-3ab6,2", "outgoing2|12038384444|1") in new stack
   -- Goto (outgoing2,12038384444,1)
   -- Executing [12038384444@outgoing2:1] NoOp("Local/12038384444@outgoing-3ab6,2", "") in new stack
   -- Executing [12038384444@outgoing2:2] Dial("Local/12038384444@outgoing-3ab6,2", "SIP/12038384444@voicepulse03") in new s
   -- Called 12038384444@voicepulse03
   -- SIP/voicepulse03-081cd4f8 is making progress passing it to Local/12038384444@outgoing-3ab6,2
   -- Local/12038384444@outgoing-3ab6,1 is making progress passing it to SIP/MUQ19HgW36-081cxxxx
 == Spawn extension (voicepulse-in, 12036531111, 2) exited non-zero on 'SIP/MUQ19HgW36-081cxxxx'
 == Spawn extension (outgoing2, 12038384444, 2) exited non-zero on 'Local/12038384444@outgoing-3ab6,2'
Comments:By: John Babina (versimedia) 2007-05-22 15:52:17

Followup info:

I just setup service with AGN VOIP using SIP.  Calls go through fine, however no callerID info is passing through.  No matter what I set (name or number) it comes up unknown on the other end.

By: John Babina (versimedia) 2007-05-22 23:05:46

More debugging details for VoicePulse:

If CALLERID(name) is set to anything, then it is being used as the "number" regardless of what CALLERID(num) is set to.  If CALLERID(name) is set to a non-number, then the end user sees "Unavailable" or similar msg.  If CALLERID(num) is set to a number, then the end user sees that number.

If CALLERID(num) is set to a number and CALLERID(name) is set to nothing, then the end user sees the number.

Basically I am able to make it work by forcing CALLERID(name) to the empty string... (If I just set (num) and (name) still has info in it from the incoming caller or extension then it screws everything up, so i must force "name" to empty string).

For AGN VoIP service, I have been unable to set a caller ID number at all so far.

By: Curt Moore (jcmoore) 2007-05-23 13:57:26

Outbound CallerID name/number is sometimes tricky when using certain PSTN providers.  For me, it would be very helpful if I could see a SIP debug or a pcap trace of the call.  This information will really tell the tale because whatever is being sent in the SIP From header is going to be the information available to the far end to construct their CallerID information.   If we can see what is being set in the From header in each of your scenarios, it should be possible to see a bit better what is going on.

By: Terry Wilson (twilson) 2007-05-24 16:46:33

Also, I'm wondering what the reason for doing a Dial(Local/12038384444@outgoing/n) is instead of a Goto(outgoing|1203838444|1).  Using the local channel unneccesarily might be exposing this bug.  I'll try to lab this up and see what I get.

By: Terry Wilson (twilson) 2007-05-24 17:25:00

I'm guessing you have a fromuser in your sip.conf.  If this is the case, the only way to get callerid to work would be using sendrpid=yes and trustrpid=yes in sip.conf (techinically you don't need the trust one).  Hopefully voicepulse trusts the rpid.  Let me know if it works and I'll close out the bug.

By: Curt Moore (jcmoore) 2007-05-29 21:59:27

Hi Versimedia.  Have you had a chance to test with twilson's suggestions?  If so, did the sendrpid option help?  If you're still having the issue please update the bug so we can investigate further.  If the sendrpid option resolves your issue also please update the bug so we can mark the bug as resolved.  Thanks!

By: Arcadiy Ivanov (arcivanov) 2007-06-04 22:05:23

I'm having a problem with both SIP and IAX caller id with VoicePulse Connect. The same dialplan (differs only by connection string in Dial command) works with both Telphin and VoipJet, but no outgoing caller id is received when dialing same numbers (Cingular cell) through VoicePulse Connect. It might not be asterisk problem after all.

By: Arcadiy Ivanov (arcivanov) 2007-06-05 21:39:40

I'm withdrawing my last comment. Apparently Voicepulse does not support "+" to indicate international dialing in their caller id.

By: Joshua C. Colp (jcolp) 2007-06-06 08:37:58

Since there has been no response and I really suspect this was a configuration issue/provider interaction issue I'm closing this for now. If this is still an issue then please reopen.