05-11-2011 11:47 AM - edited 03-21-2019 04:04 AM
Hi,
I have enabled Single Number Reach for our users, but when we test it the calls do not transfer. The CLI looks like the following:
ephone-dn 582 octo-line
number x1234 secondary ********** no-reg both
label x1234
description User Name
name User Name
mobility
snr 91********** delay 5 timeout 30 cfwd-noan 3099
call-forward busy 3099
call-forward noan 3099 timeout 20
translation-profile incoming CallBlocking
I have tested several times and rebooted phones to ensure to eliminate every variable, but without any luck.
All SIP Lines running on Cisco UC560 & Software Pack 8.1. All phones are 7975's.
Thank you
05-11-2011 12:26 PM
So are the calls not reaching out to the SNR number or are they not being pulled back to the UC500 for VM?
You might want to try removing and adding the SNR config on the DN. If the calls arent going out at all I would run a SIP debug to see if the system is attempting to send the call out.
Please post the output from the following debug:
debug ccsip message
Thanks,
Cole
05-11-2011 10:26 PM
Hi Help Desk,
Not good to see you having these issues, lets hope we can all help out a little with resolving it.
Firstly: Have you logged a support case on this yet? Or do you want to try out the community first and see if that yields you a result?? If it is mission critical that this works as it should from the get go, the logging a support case should be first priority and the community used as a measure to speed the process up
Secondly: Is the SNR number the same as you would dial a normal number from the handset? Looking at your posted config I would assume so but I don't work with USA configuration so maybe not??
Thirdly: What is not working exactly? Is it not dialing out at all?? Is the setup times potentially taking too long before the far end is dialing??? Try and reduce the delay down to 1 or 2 to give some headroom for the call setup time to take place, and make sure to increase your NOAN timer to equal that of your SNR just whilst you are testing it out, if this is lower then potentially things like call setup times could be impacting on this working properly.
As the previous poster pointed out you should also do some debugging, if you are not familiar with the CLI then you can use CCA to do the debugging for you, this is a really cool way of capturing information but is from what I have seen so far a little less in breadth to the CLI itself.
Capture as much information as you can on every single call attempt where you are attempting SNR and post it up here for us all to look at and see what is going on
Good luck and don't forget to ask for more help if you get stuck with capturing the data.
Cheers,
David.
05-12-2011 07:31 AM
The configuration you have entered does look correct. I do have a "thought" on what may be causing the issue, but we really need to see some debugs to see what is happening with the call to see where and why it is failing.
If possible, can you run the following debugs and post them here?
debug ccsip messages
debug voice ccapi inout
This can be done in CCA, or CLI.
When testing SNR, were you calling from an internal extension, or coming in over the SIP trunk?
My "thought" is that you were testing this coming in over the SIP trunk to a DID. If that is the case, you may need to add a translation to change the caller-id on the call. Most SIP providers will reject that call because the call is presented to them from a caller-id that is not one they will accept. Most SIP providers are expecting the caller-id to be one of your registered DID's and if not, will reject the call. The debugs would show us this information. (If you tested this, calling from an internal extension to "1234", and it still failed. Then this is not the issue.)
Thank you,
Darren
05-12-2011 08:45 AM
As Darren said, if you enable SNR to an internal external the SNR feature will work correctly, however if you enable SNR to an external number, the call drops. The From field in the SIP header is using the incoming caller’s number which caused your SIP provider to reject the call.
Debug Example Bellow:
Incoming Number: 222-222-2222
SNR: 333-333-333
DID: 444-444-444
The SIP providers expects the FROM address to be your DID 444-444-444.
009938: May 5 13:33:42.679: //8293/9F18ADB2A06C/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.75.2:5060;branch=z9hG4bK37171582
From: "PRIVATE NAME" <sip:2222222222@sipprovider.ca>;tag=57030774-772
To: <sip:333-333-3333@sipprovider.ca>;tag=aprqngfrt-1qu7hd20000a6
Call-ID: A7DB1CC6-767411A0-A075DDA3D-C596746F@sipprovider.ca
CSeq: 101 INVITE
Timestamp: 1304616822
One option would be to add the following command under the ephone-dn:
snr calling-number local
This will strip the incoming number and change it to your DID. The issue with this command is when mobility is enabled, the number that is displayed on your mobile device is your DID.
Question for Darren, would the translation rule, resolve the issue I described with the snr calling-number local command. I am curious as it would be nice to see the original callers number and not the DID.
05-12-2011 09:39 AM
Ryan,
Normally, I would tanslate the caller-id with a translation rule so that I do not have to modified multiple ephone-dn's.
Unfortantely, I have not found a way to preserve the orignial callers info for the outgoing "SNR" call. Since the provider will reject the call if the Caller-ID is not one of the registered DID's.
Thank you,
Darren
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide