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!

SIP Outbound Caller ID 1

Status
Not open for further replies.
Mar 27, 2008
30
US
I'm having issues sending the DID of the extension as our outbound caller ID and was hoping someone could point me in the right direction or tell me what I'm doing wrong. I've read some of the posts on short codes and caller ID and used that information to derive the short codes below.

We're using SIP for inbound and outbound calling. I have two separate short codes setup and neither of them yield the correct result. We stopped using ARS after we converted from PRI to SIP.

The first one is (this one actually dials):
Code: 8N;
Feature: Dial
Telephone Number: N"@A.B.C.D"
Line Group ID: 9

The second one is (this one won't dial at all):
Code: 9N;
Feature: Dial
Telephone Number: NS469555E"@A.B.C.D"
Line Group ID: 9

Since the second one doesn't work at all we've been using 8 to dial out. When dialing out the Caller ID appears as 40031911 which happens to be all the numerical values of our SIP username with the alphabetical characters stripped off.

I've already talked to the SIP provider and he removed his override masking. When we originally converted from PRI to SIP we had them mask/override all outbound caller ID to our 800 number. This has since been removed.

Anyone else running into this issue or know what to do? Any help would be much appreciated.

Thanks,

Mike
 
In the Manager Goto;

Line > Sip Line > Sip Uri tab >

Put "Local URI", "Contact" and "Display Name" on Use User Data

Then goto;

User > Sip Tab > at Sip Display Name and Contact fill in the number you want to sent.



y1pzZTEUdok1vrI5cLb3FdPX4PgTPlSONkb5WPjz0x50etSujaMSmhdRCbOx9vASnrRNzzXv0IxNQA

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________
 
As bas123 advises you must use the specifc SIP settings. The outgoing caller ID is part of authentication with the SIP provider, so none of the other IP Office features for manipulating CLI (eg. short codes) are supported on calls going to SIP.

There are RFC's for SIP packets to contain alternate CLI's when calls are forwarded or redirected by IP Office doesn't support those to the best of my knowledge.
 
Eww eww eww. The URI information under the SIP Trunk should only be used for DID routing to hunt groups or auto attendants and not for users. Creating a separate URI for each DID under the line is inefficient. Not to mention that if you program the URI on the Lines tab you will have to reboot.

Instead create a generic URI of:
Local URI: Use User Data
Contact: Use User Data
Display: Use User Data
....
Incoming Grp: 0 (or whatever)
Outgoing Grp: 0 (again whatever)

Then under the now available SIP tab on the user enter the URI (DID/Caller ID information) for the Local/Contact/Display information. Point your ARS to the 0 group (or whatever you used above).

On outbound calls the system will use the information provided in the user's URI entries as their CLI. Inbound calls will validate the 100 TRYING against the Line URI entries first then the user URI entries. Once you have your 200 OK you can still re-route these calls using your Incoming Call Route entries. You can also use the same URI information for multiple users (e.g. handing out the main number for generic extensions).


Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me
 
OK.

bas1234 -> thanks, I'll give this a try. Do you know what the difference between the SIP Name, SIP Display Name (Alias) and Contact are in terms of which one I should put the DID in?

sizbut -> thanks, I was unaware that the short codes had no affect on SIP and were only for PRI/ISDN.

kholladay -> We actually have 59 SIP URI entries, one for each DID, and two more for the username on primary and secondary registration. Are you saying I should delete them all, create just one entry for "Use User Data" (not even have one for the username?), and then use ARS to point my outbound calls to line group 9 (which is what we use for SIP)? What would the ARS look like? Right now we're not using ARS so nothing is really setup in there. Also, please refer to my question to bas1234 regarding which fields I should actually use for the DID.

Thanks again!
 
Sip name is mostly your registration name
Sip Display is the name/number you want to sent
Contact is also the name/number where people can contact you.

The ipo is still not able to do sip users only sip trunking!!


create new ARS;

fill in route name, add code;

code; N;
TelN; N"@sipprovider.com"
Feature; Dial
Linegrp; Line group id

create Shortcode;

Code; 9N
Feature; Dial
TelN; N
LineID; NEW ARS


User short code;
Code; 9N
Feature; Dial
TelN; N
LineID; NEW ARS

Greetzzz...Bas





y1pzZTEUdok1vrI5cLb3FdPX4PgTPlSONkb5WPjz0x50etSujaMSmhdRCbOx9vASnrRNzzXv0IxNQA

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________
 
If you fill in at contact the word " Anonymous " then it will sent no CLID

y1pzZTEUdok1vrI5cLb3FdPX4PgTPlSONkb5WPjz0x50etSujaMSmhdRCbOx9vASnrRNzzXv0IxNQA

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________
 
aiosolutions> "We actually have 59 SIP URI entries, one for each DID, and two more for the username on primary and secondary registration. Are you saying I should delete them all, create just one entry for "Use User Data" (not even have one for the username?), and then use ARS to point my outbound calls to line group 9 (which is what we use for SIP)? What would the ARS look like? Right now we're not using ARS so nothing is really setup in there. Also, please refer to my question to bas1234 regarding which fields I should actually use for the DID."

The URI is only needed in 1 location for the 100 TRYING to validate. If this is a DID for a user the most logical place would be to place it on the user's SIP tab. If the DID is generic or used for a hunt group or AA then you have no choice other than to place it under the line's URI table. So for each DID that can not be associated to 1 more more users you would create a URI entry in the line table. For each DID that is associated with 1 or more users place that number in all 3 fields (only 1 is needed but I'm to lazy to figure out which although I would assume it is SIP Name).

Example:
-----------------------------------------------------
SIP Line
Local URI: Use User Data
Contact: Use User Data
Display: Use User Data
In Group: 0
Out Group: 0
-----------------------------------------------------
Incoming Call Route:
Line: 0
Number: 5555551111
Destination Sales Hunt Group

Line: 0
Number: 5555551112
Destination DID Guy
-----------------------------------------------------
User ("Generic Sales Guy1" Extension 200)
SIP Name: 5555551111
SIP Disp: 5555551111
Contact: 5555551111

User ("Generic Sales Guy2" Extension 201)
SIP Name: 5555551111
SIP Disp: 5555551111
Contact: 5555551111

User ("DID Guy" Extension 202)
SIP Name: 5555551112
SIP Disp: 5555551112
Contact: 5555551112
-----------------------------------------------------
ARS:
SC: N;
Feature: Dial
Telephone: N"@my.sip.itsp.com"
Line: 0
-----------------------------------------------------
Result. When user either "Generic Sales Guy" dials out it will display 5555551111 but when "DID Guy" on 202 dials out it will show 5555551112.

This would be the "proper" way to program a URI that belongs to a user or users.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me
 
of course all above assuming that your sip provider has the numbers as valid on their network and allows you to determine if you can send your own clip. many, many, many don't!

 
Well it should go without saying that you can't just send any old number you want. The URI must be valid with the ITSP. It would be exceptionally rare that a provider outside of a traditional T1/PRI would allow you to transmit a number that wasn't on the circuit in question.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me
 
of course kyle, but mike states that he has gone from a pri to sip. i just hope the sip provider has taken all of his ddi range
 
Well I was always told I could hope in one hand and crap in the other and see which would fill up first.

In the US at least if I rely on hope with any telephone company I'd be left with noting in one and a mess in the other.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me
 
You guys are awesome!

That works much better than doing it the other way we had it with the 59 URIs.

Now this poses one last question. In my URI setup I have my DIDs that don't go to a specific user but go to hunt groups listed in random order (there are 13 of them down from 59), and the last URI is the "User Data" URI. When we call out it uses the first DID on the URI list (i.e. Channel 1's information).

Should I move the URIs around so that the "User Data" URI is first? Should there be more than one "User Data" URI since they relate to channels? For example if two people call out will the second caller use whatever Channel 2s information is? And lastly, would changing the URIs with "DIDs" to Secondary Registrations have any affect on anything?

Thanks for all your help.
 
The following rules are used when short code matching is performed for user dialing:

• A short code is used immediately an exact match is found unless followed by a ;.

• If no match is found but partial matches exist, the user can continue dialing.

• If no match or partial matches are found, incompatible is returned.

• The following precedence is used to determine which short codes are used:

• Extension number matches override all short codes.

• User short codes override user rights and system short codes.

• User Rights short code matches override system short codes.

• When multiple exact matches occur,

• The match with the most specified digits rather than wildcards is used.

• If there are still more than one match, the match with the most exact length is used. This means X wildcards will override N when both match.



Greetzzz...Bas


y1pzZTEUdok1vrI5cLb3FdPX4PgTPlSONkb5WPjz0x50etSujaMSmhdRCbOx9vASnrRNzzXv0IxNQA

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________
 
The outbound call will use any URI in the outbound line ID. If you have 1 URI that has "Use User Data" with 4 channels and another in that same outbound line ID that has "5555551111" the 5th outbound call will send 5555551111 not the information in the user's URI although I am not sure that was Avaya's intention and I don't know if it will change.

The order in which the URI are listed is irrelevant. The URI. If you have 2 DID that each have 4 channels but you want to use "Use User Data" for both then just list 1 URI with 8 channels.
If your hunt group members are going to transmit the hunt group DID instead of a personal DID for outbound calls then just use the hunt group URI for all of those user’s and skip creating a line side URI. This would be typical for service departments where you don’t want an individual customer service agent phone number handed out or in fact they don’t have a DID.



Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me
 
I removed all the URIs and added them back into the system so that Channel 1 was the "Use User Data" and the next 15 Channels were numbers/DIDs.

We only have 6 SIP Trunks and since the Channel 1 was set for 10 Calls Max per channel, every call uses the User Data.

The rest of the 15 Channels are in random order and aren't used.

Needless to say the system is setup exactly the way I need it.

I appreciate all your help.
 
Good deal. Always glad to help.


Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top