cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2695
Views
0
Helpful
5
Replies

Single Number Reach not working...

Help Desk
Level 1
Level 1

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

5 Replies 5

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

David Trad
VIP Alumni
VIP Alumni

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.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

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

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.

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: