I've got a UC540W (latest CCA and Software Pack) and have both PSTN and SIP trunks. The SNR doesn't work when going out on a SIP trunk, but it works when going out on the PSTN trunk. When going out on the SIP trunk, the IP phone rings once and the the call gets disconnected.
The other problem is that even when the SNR works going out on the PSTN trunk it never pulls the call back to voicemail on the UC -- it just keeps ringing the moblie phone (SNR number).
SNR will not pull the call back to voicemail when using an FXO line. This is because of the way FXO lines work, and unfortunately there is not anything we can do about that.
I am not sure exactly why you SNR is failing over the SIP trunk, but my guess, without seeing your config, or some debugs would be that the SIP provider is rejecting the call because the Caller-ID on that call is from the original caller. The SIP provider will then reject the call, since they are only expecting to see outgoing calls coming from your assigned Caller-ID. To bypass that, you will need to translate the caller-id before sending the call out for SNR.
From CCA, you can manage the Caller ID as Darren suggests for your SIP trunk from Dial Plans > Outgoing > Caller ID. Change the main number for your SIP Trunk to match all caller numbers, not just internal extensions (which is the default). This means that all outgoing numbers (including call transfers and forwards) will have their number translated to your main number.
Yes, I have that already. All extensions have the number caller-id of the main company number. I do that in all my configs. I took it off to see if it would work and it doesn't. Any other ideas?
The extensions are not the problem, it is whether the caller-id from the external number is being translated to your main number. This is why Laura said that you can change the Caller-ID for all numbers, and not just internal extensions. If you have tried that, then we would need to see your config and the debugs to see what is happening, and why the call is failing.
Thanks, I do I understand that as well. For my ITSP I need the Caller-ID Main PSTN Number to be the main number of the SIP account, which isn't the same as the main company number. So if I changed that all calls would fail.
If I set the calling-info pstn-to-sip number I could get around it, but it would break my other dial plan whereby I have a different caller-id go out depending on the access code entered -- 9 for Company A, 6 for Company B. Plus when voicemail messages are emailed, they appear as the main company number, not the caller-id of the original caller.
I can't believe no one else has a problem with this stuff. It's so easy for it not to work. You would think there would be tons of "It doesn't work" postings. I can't have such a unique config that no one has come across it. How does it make it out of QA? Where's the documentation explaining what scenarios SNR works with and the ones it doesn't? Seems strange to me.
Any other ideas?
Without seeing the config, and possibly the debugs, I would just be guessing from here. My suggestion at this point would be to open a case with SBSC, or possibly posting you config here. If you do post your config, make sure you that remove all private info, like usernames and passwords..
Yes, I do have a case open already but I'm still waiting for a solution.
I think the Caller-ID of the incoming number being passed through is important because when the user gets the call, say, on their mobile phone, they want the caller-id of the incoming call, not the caller-id of their own company. It makes the caller-id lose its purpose. So I would want to correct this either with the UC or ITSP. Do you know how this could be accomplished? Has anyone else run into the same problem?
If it's impossible for that to be done, then what kind of translation rule could be put in place to convert the incoming caller-id to the main company number when SNR is evoked. I think that could be the solution. Do you know how this could be accomplished?
Rutabaga -- I figured it out. I created a separate access code (5) to dial out the SIP trunk, then created separate translation rules and a profile to take the incoming number and swap it out with the main company number. Then I populated the SNR on the phone with the newly created access code of 5 (rather than the usual 9). Now it works and I keep my other functionality that I wanted.
I decided to send out a different DID number to identify it as a SNR call that was coming in. Plus I changed the the name caller-id of Company A with "IncomingSNR" to also identify the call as a SNR call.