Flowroute CallerID (out-bound)

[konextu]

Having a bit of an issue with flow route and outbound caller id. IN the mean time he had me manually override it with:

Code: Select all

exten => _91NXXNXXXXXX,2,SipAddHeader(P-Asserted-Identity: <SIP:1235555555@anonymous>)

with of course the 1235555555 being our real number. Any ideas as to why its not natively working?

He said the P-Asserted-Identity field contain some weird 8 digit number

[mflorell]

Outbound callerID is set in the campaign detail screen.

Is your carrier complaining about callerID?

[konextu]

Their saying their getting weird numbers in p-asserted-identity header.

[mflorell]

What carrier is this?

What kind of switch are they using?

[konextu]

the carieer is flow route.

[konextu]

Binfone show same problem, any resolution to date?

[williamconley]

Just for my information, can I get a version/build to reference this in case i have clients with the same issue?

[Op3r]

Been using flowroute and I havent experience any issues regarding caller ID.

But then again, Its only being used by a handlful of agents for secondary line.

[konextu]

VERSION: 2.2.0-212
BUILD: 90827-1552

The issue is the tracking data M123412341234 blah blah is being passed in the fromuser field and you have to use p-asserted-identity under sipaddheader to override it and add caller id info. I had both carieer's trap the info and lightyear wholesale sip is having the same problem. I really think its just an overall issue with vicidial and outgoing sip. I have not tried using unauthenticated sip yet though.

[mflorell]

We have not had this issue with most of the SIP carriers we use.

As for how this is a problem, unfortunately Asterisk gives no other way of tracking a call under all circumstances than using callerID info. Everything else resets at some point(uniqueid, channel variables, etc...) so we are left with CallerIDname which follow a call through all phases and all modules and is not changed, modified or reset in any way.

There is always the workaround of using the loopback-no-log context and the example dialplan to send whatever you want as the callerID name(even though it is actually ignored at the PSTN).

[williamconley]

i have only had two carriers, historically, who have had issues interacting with vicidial servers. one just plain flat out refuses to allow nat (resolved by removing the router or purchasing a sip-aware qos router) and one will not set callerid unless you are using ip auth and DONOT send ANY fromuser/user/auth of any sort (even if you aren't using it, if you send so much as ONE of those headers, their system will not set the callerid, which is REALLY freaky).

turns out that neither of these issues was vicidial related, just asterisk.

that being said, vicidial sets the calleridNAME and calleridNUM, but has no effect on fromuser or any of the other channel variables for sip authentication. i say this because i had to get deeply into what can and cannot be done for those two previously mentioned moments for clients. i can assure you that as of 2.0.5, there is no such issue. so ... i doubt that it was introduced in 2.2.0, and i wonder if you are simply having a sip configuration issue that is unrelated to vicidial.

have you experimented with these settings in your carrier settings and tried hand-made sip.conf entries to see what is "up"?

what setting is it exactly? (you mentioned fromuser, which is not a required variable for vicidial)

[cjonesmo]

I have the same issue with Aierspring and I believe that the actual problem is due to the LENGTH of the caller-id NAME field. The limit, according to the standard, is 15 characters.

This may be the problem with other carriers as well - perhaps there's an easy way to convert THIS particular value to HEX to shorten it?

[williamconley]

I have the same issue with Aierspring and I believe that the actual problem is due to the LENGTH of the caller-id NAME field. The limit, according to the standard, is 15 characters.

This may be the problem with other carriers as well - perhaps there's an easy way to convert THIS particular value to HEX to shorten it?

I cannot imagine why they would have ANY issue with the callerid name field, as it is ignored by all carriers anyway (the ones above the VOIPs). So if they have a problem with the calleridNAME, they are likely using it in a way similar to vicidial, which is not something I would expect of a carrier. In any case, I would be surprised if there was a problem with the length of the callerid name, but it is EASILY tested ... so test it and find out?

[mflorell]

We have not had any issues with this on PRI circuits here in the USA, including with Airespring.

As for SIP termination, there are all sorts of issues you can run into with them due to whatever rules the carrier has sin place.

[cjonesmo]

I'm back to troubleshooting this and will let you know what I find out - these are SIP trunks with Airespring. It seems that they work if I just make a call from an IP phone but don't when dialing from vici - which is why I suspected the caller-id name field, but will let you know what our debug turns up.

[williamconley]

what did you set your callerid(num) to for the campaign?

of course, you could always put a pure asterisk server between your vicibox and your provider to convert anything that needs converting. as a "last gasp" but quick solution.

[konextu]

What worked for us in the end was to work with the SIP Provider to remove the need for the "From user' field. What we did in the interium was a opensips server.