Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IP Office 11.1.3.1 with IP Flex - Sending caller ID

TN94z

Technical User
Apr 15, 2010
103
US
I have a customer that has an IP Flex and she wants to send out her extension as her caller ID instead of the main office number. In the ARS, the main number is setup as the telephone number for all codes, as I would expect. Typically, on PRIs, we simply use the NSxxxxxxxxxx with the 9N code to set this up. How do I do this with the flex, as our typical way does not work. Is there a feature missing from the circuit? Or is it because the ARS is overriding?
 
It's the IP flex not allowing you to control outbound caller ID. Its forcing the main number to show. You need to put a ticket in with AT&T to allow you to control it.
 
1979 could definitely be right, but not being familiar with IP Flex I have to ask... IS it a PRI? If it's not, and it's a SIP trunk, you could control it from the user's SIP tab assuming the SIP URI is set to use internal data.
 
It's the IP flex not allowing you to control outbound caller ID. Its forcing the main number to show. You need to put a ticket in with AT&T to allow you to control it.

I was wondering if that could be the issue.
1979 could definitely be right, but not being familiar with IP Flex I have to ask... IS it a PRI? If it's not, and it's a SIP trunk, you could control it from the user's SIP tab assuming the SIP URI is set to use internal data.

It is SIP.
 
First step Check in monitor to see what you are sending then you will know if you need to look at the system or carrier.

Odd that your customer wants to send a caller ID that can't be called back but I guess each to their own. In my experience it's only the lower quality carriers that allow you to send an invalid caller id. But hey they are not hard to find.
 
First step Check in monitor to see what you are sending then you will know if you need to look at the system or carrier.

Odd that your customer wants to send a caller ID that can't be called back but I guess each to their own. In my experience it's only the lower quality carriers that allow you to send an invalid caller id. But hey they are not hard to find.

The customer doesn't want to send a caller ID that can't be called back. The customer wants to have the option of either sending out their main office number (which can be called back) or sending out the individual's DID number (which can be called back as well).
 
OK I guess I got confused when you said "wants to send out her extension"

My advice still stands you need to first check what you are sending if you think the system is configured correctly.
How you configure the system also depends on what the carrier is expecting.

At a basic level you can either use "Internal data" which is the number under the SIP tab of the user or you configure the outbound caller ID on the SIP URI under the SIP line Call details TAB.

Or a combination of both depending on your requirements. If you have a hight percentage of users that want to display, their DID as the outbound callID then Internal data is best.

Set the required number under the User SIP tab and then setup the SIP line Call Details to allow this to work.

What I do is create two entrees Under the Call Detail tab, the first is for incoming calls with the incoming Group as 1 and the outgoing as 99 (It not used). This will be used by the system to accept all incoming calls and process them as per the incoming call route

1730492998575.png

Ill then load a second entree fir outbound call to use the "Internal data" of the user SIP tab for the outgoing call. This example also has the settings our default carrier requires for A party on twinned calls.

1730493151960.png

ARS is then set like this. (We don't use 9 for an outside call)

1730493312009.png



This is how we config system by default you might want to do things different depending on customer requirements, e.g if you have a high number of users and most display the main number and just a few want to display their DID then I would do this differently with two ARS tables. One to use a set number in place of "Internal data" and the other as above. This would save the time in loading the main number in all of the users SIP tabs.

Or another option, if your carrier has the option to replace an invalid outbound caller ID with your desired number (main number) then you could set as above and just load the DID in the users that want this. All others would use the extension number which would be replaced by the carrier.

There are number if options and different ways of doing this it really depends on your preference and the carrier. What I have detailed works very well for us and it's what we use most of the time.
 
OK I guess I got confused when you said "wants to send out her extension"

My advice still stands you need to first check what you are sending if you think the system is configured correctly.
How you configure the system also depends on what the carrier is expecting.

At a basic level you can either use "Internal data" which is the number under the SIP tab of the user or you configure the outbound caller ID on the SIP URI under the SIP line Call details TAB.

Or a combination of both depending on your requirements. If you have a hight percentage of users that want to display, their DID as the outbound callID then Internal data is best.

Set the required number under the User SIP tab and then setup the SIP line Call Details to allow this to work.

What I do is create two entrees Under the Call Detail tab, the first is for incoming calls with the incoming Group as 1 and the outgoing as 99 (It not used). This will be used by the system to accept all incoming calls and process them as per the incoming call route

View attachment 862

Ill then load a second entree fir outbound call to use the "Internal data" of the user SIP tab for the outgoing call. This example also has the settings our default carrier requires for A party on twinned calls.

View attachment 863

ARS is then set like this. (We don't use 9 for an outside call)

View attachment 864



This is how we config system by default you might want to do things different depending on customer requirements, e.g if you have a high number of users and most display the main number and just a few want to display their DID then I would do this differently with two ARS tables. One to use a set number in place of "Internal data" and the other as above. This would save the time in loading the main number in all of the users SIP tabs.

Or another option, if your carrier has the option to replace an invalid outbound caller ID with your desired number (main number) then you could set as above and just load the DID in the users that want this. All others would use the extension number which would be replaced by the carrier.

There are number if options and different ways of doing this it really depends on your preference and the carrier. What I have detailed works very well for us and it's what we use most of the time.

I guess that is easy to do. We just know that extensions can be either DIDs or non-DIDs and if we are talking about sending out a caller ID, we just know that we wouldn't send out a non-DID as caller ID. But I can see how that would confuse some
 
Last edited:

Part and Inventory Search

Sponsor

Back
Top