Solved: SNR Takes 4-5 rings before mobile rings

Brikers12 · ‎07-10-2009

We would like to use the SNR feature on the UC520, but it takes way too many rings before the mobile gets its first ring, by that time the customer will have probably given up.

With SNR enabled I place a call from an external line. After a couple rings my handset starts ringing, but it takes another 2 rings before my mobile phone starts to ring.

David Harper · ‎07-14-2009

The additional time take between when the desk phone starts to ring and the mobile starts to ring is at least in part due to the delay parameter that is set on the snr command. The delay is exactly what it sounds like - the length of time between when the call is received at the UC500 (essentially when the desk phone starts ringing) and when the UC500 extends the call out to the mobile phone. It is set to a five seconds delay in your config, which, when added to the initial delay for the UC500 to detect CLID, works out to the five or six rings you are seeing.

Cheers,

Dave.

View solution in original post

David Harper · ‎07-14-2009

I take your point about the delay, and agree it is not ideal. Just to break it down a little so you can see where it is coming from:

1. Two rings to detect CLID before extending the call to the desk phone and SNR

2. Maybe a second to dial the phone number out the analog trunk

3. Setup time in the PSTN before the remote phone rings

#1 is specific to analog trunks, since we get CLID information in between the first and second ring. The use of a ditital line such as ISDN or SIP will eliminate this. There is also a CLI command that will make the desk phone ring immediately we detect the call, but you won't see CLID on the phone until a few seconds later once we have collected it from the PSTN. This can be confusing for some people, which is why we default to suppressing the call until we have the CLID.

#2 again is specific to analog trunks, but should not be more than a second depending on the number of digits to be dialled.

#3 is a bit unpredictable, but I'm surprised it is taking as long as it is when calling a land line. Can you capture the output of 'debug vpm signal' again, but make sure you enable timestamping of debug messages by first configuring 'service timestamps debug datetime msec localtime' before reproducing. But there may not be anything we can do about this. Once the trunk has been siezed and the number dialed, we are at the mercy of the PSTN.

Cheers,

Dave.

View solution in original post

David Trad · ‎07-10-2009

Hi Tervor,

With SNR enabled I place a call from an external line. After a couple
rings my handset starts ringing, but it takes another 2 rings before my
mobile phone starts to ring.

This could be because your carrier has long call setup times, if you are running PSTN can you do a VPM Signal debug, or if it is ISDN can you do a ISDN debug, it would be good to know how long it takes for your carrier to set the call up to a mobile was the message has been sent to them.

Also can you post your SNR config here just to see what settings you are using.

snr delay 4 timeout 10

The above is what i have used before, however you can adjust this and try to find the right setting, i am not sure though how much this will assist you if your carrier has longer call setup times when making calls to mobiles, you should see also how long it takes to set the call up to a Fixed line as well.

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 :) *

Brikers12 · ‎07-14-2009

thanks for the response! Here is the bit of the config

snr 96048356030 delay 5 timeout 30 cfwd-noan 299

I changed the SNR number to a residential land line to see if the time is shorter than to a mobile, it wasn't. The test I just did both took a whopping 6 rings before the SNR number rang, which makes it pretty much useless.

I think i did a VPM debug?

------------------------------------------------------------------------------

UC520#term mon
UC520#enable
UC520#debug vpm signal
Voice Port Module signaling debugging is enabled
UC520#
htsp_process_event: [0/1/0, FXOLS_ONHOOK, E_DSP_SIG_0000]fxols_onhook_ringing
htsp_timer - 125 msec
htsp_process_event: [0/1/0, FXOLS_WAIT_RING_MIN, E_HTSP_EVENT_TIMER]fxols_wait_ring_min_timer
htsp_timer - 10000 msec
htsp_timer3 - 5600 msec
[0/1/0] htsp_start_caller_id_rx:BELLCORE
htsp_start_caller_id_rx create dsp_stream_manager
[0/1/0] htsp_dsm_create_success returns 1
htsp_process_event: [0/1/0, FXOLS_RINGING, E_DSP_SIG_0100]
fxols_ringing_not
htsp_timer_stop
htsp_timer - 10000 msec
htsp_process_event: [50/0/9.1, EFXS_ONHOOK, E_DSP_SIG_1100]efxs_onhook_offhook htsp_setup_ind
[50/0/9.1] get_local_station_id calling num=BCD calling name= calling time=07/14 18:10 orig called=
htsp_process_event: [50/0/9.1, EFXS_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]efxs_check_auto_call
htsp_digit_ready(50/0/9.1): digit = A
htsp_digit_ready(50/0/9.1): digit = B
htsp_digit_ready(50/0/9.1): digit = C
htsp_process_event: [50/0/9.1, EFXS_OFFHOOK, E_HTSP_PROCEEDING]efxs_offhook_proceeding
[50/0/9.1] set signal state = 0x8 timestamp = 0
htsp_process_event: [50/0/9.1, EFXS_OFFHOOK, E_DSP_SIG_0100]efxs_offhook_onhook
htsp_timer - 10 msec
htsp_process_event: [50/0/9.1, EFXS_OFFHOOK, E_HTSP_EVENT_TIMER]efxs_offhook_timer
htsp_process_event: [50/0/9.1, EFXS_ONHOOK, E_HTSP_RELEASE_REQ]efxs_onhook_release
htsp_timer_stop
[50/0/9.1] set signal state = 0x4 timestamp = 0
htsp_process_event: [0/1/0, FXOLS_RINGING, E_HTSP_EVENT_TIMER3]fxols_snoop_clid_stop
htsp_timer_stop3
htsp_process_event: [0/1/0, FXOLS_RINGING, E_DSP_SIG_0000]
htsp_process_event: [0/1/0, FXOLS_RINGING, E_DSP_SIG_0100]
fxols_ringing_not
htsp_timer_stop
htsp_timer_stop3
[0/1/0] htsp_stop_caller_id_rx. message length 0htsp_setup_ind
[0/1/0] get_fxo_caller_id:Caller ID receive failed. parseCallerIDString:no data.
[0/1/0] get_local_station_id calling num= calling name= calling time=07/14 18:10 orig called=
htsp_process_event: [0/1/0, FXOLS_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]
fxols_wait_setup_ack:
htsp_timer - 6000 msec
htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_PROCEEDING]fxols_offhook_proc
[0/1/0] htsp_dsm_close_done
htsp_timer_stop3 htsp_setup_req
htsp_process_event: [50/0/13.1, EFXS_ONHOOK, E_HTSP_SETUP_REQ]efxs_onhook_setup
htsp_ephone_start_caller_id_tx calling num= calling name = called num=201 orig called num=204
[50/0/13.1] set signal state = 0x0 timestamp = 0
efxs_onhook_setup: local target is available
htsp_alerthtsp_alert_notify
htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_ALERT]fxols_offhook_alert
htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_DSP_SIG_0000]fxols_proceed_ring
htsp_timer_stop
htsp_timer_stop2
htsp_timer_stop3 htsp_setup_req
htsp_process_event: [0/1/1, FXOLS_ONHOOK, E_HTSP_SETUP_REQ]fxols_onhook_setup
[0/1/1] set signal state = 0xC timestamp = 0
htsp_timer - 1300 msec
htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_DSP_SIG_0100]fxols_proceed_clear
htsp_timer_stop2
htsp_timer - 6000 msec
htsp_process_event: [0/1/1, FXOLS_WAIT_DIAL_TONE, E_HTSP_EVENT_TIMER]fxols_wait_dial_timer htsp_dial
htsp_process_event: [0/1/1, FXOLS_WAIT_DIAL_DONE, E_DSP_DIALING_DONE]fxols_wait_dial_done htsp_alert
htsp_timer - 350 msec
htsp_call_bridged invoked
htsp_call_bridged invoked
htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_VOICE_CUT_THROUGH]fxols_proc_voice
htsp_process_event: [0/1/1, FXOLS_WAIT_CUT_THRU, E_HTSP_VOICE_CUT_THROUGH]fxols_handle_cut_thru
htsp_timer_stop
htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_CONNECT]fxols_offhook_connect
[0/1/0] set signal state = 0xC timestamp = 0
htsp_timer_stop
htsp_process_event: [50/0/9.1, EFXS_ONHOOK, E_DSP_SIG_1100]efxs_onhook_offhook htsp_setup_ind
[50/0/9.1] get_local_station_id calling num=BCD calling name= calling time=07/14 18:11 orig called=
htsp_process_event: [50/0/9.1, EFXS_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]efxs_check_auto_call
htsp_digit_ready(50/0/9.1): digit = A
htsp_digit_ready(50/0/9.1): digit = B
htsp_digit_ready(50/0/9.1): digit = C
htsp_process_event: [50/0/9.1, EFXS_OFFHOOK, E_HTSP_PROCEEDING]efxs_offhook_proceeding
[50/0/9.1] set signal state = 0x8 timestamp = 0
htsp_process_event: [50/0/9.1, EFXS_OFFHOOK, E_DSP_SIG_0100]efxs_offhook_onhook
htsp_timer - 10 msec
htsp_process_event: [50/0/9.1, EFXS_OFFHOOK, E_HTSP_EVENT_TIMER]efxs_offhook_timer
htsp_process_event: [50/0/9.1, EFXS_ONHOOK, E_HTSP_RELEASE_REQ]efxs_onhook_release
htsp_timer_stop
[50/0/9.1] set signal state = 0x4 timestamp = 0
htsp_process_event: [0/1/0, FXOLS_CONNECT, E_DSP_SIG_1100]fxols_offhook_disc
htsp_timer2 - 350 msec
htsp_process_event: [0/1/0, FXOLS_CONNECT, E_HTSP_EVENT_TIMER2]fxols_disc_confirm
htsp_timer_stop
htsp_timer_stop2
htsp_timer_stop3
htsp_timer_stop3
htsp_process_event: [50/0/13.1, EFXS_WAIT_OFFHOOK, E_HTSP_RELEASE_REQ]efxs_waitoff_release
[50/0/13.1] set signal state = 0x4 timestamp = 0
htsp_timer_stop3
htsp_timer_stop3
htsp_process_event: [0/1/0, FXOLS_REMOTE_RELEASE, E_HTSP_RELEASE_REQ]fxols_offhook_release
htsp_timer_stop
htsp_timer_stop2
htsp_timer_stop3
[0/1/0] set signal state = 0x4 timestamp = 0
htsp_timer - 2000 msec
htsp_process_event: [0/1/1, FXOLS_OFFHOOK, E_HTSP_RELEASE_REQ]fxols_offhook_release
htsp_timer_stop
htsp_timer_stop2
htsp_timer_stop3
[0/1/1] set signal state = 0x4 timestamp = 0
htsp_timer - 2000 msec
htsp_process_event: [0/1/0, FXOLS_GUARD_OUT, E_HTSP_EVENT_TIMER]fxols_guard_out_timeout
htsp_process_event: [0/1/1, FXOLS_GUARD_OUT, E_HTSP_EVENT_TIMER]fxols_guard_out_timeout
htsp_process_event: [0/1/0, FXOLS_ONHOOK, E_DSP_SIG_0100]
htsp_process_event: [0/1/1, FXOLS_ONHOOK, E_DSP_SIG_0100]

David Harper · ‎07-14-2009

The additional time take between when the desk phone starts to ring and the mobile starts to ring is at least in part due to the delay parameter that is set on the snr command. The delay is exactly what it sounds like - the length of time between when the call is received at the UC500 (essentially when the desk phone starts ringing) and when the UC500 extends the call out to the mobile phone. It is set to a five seconds delay in your config, which, when added to the initial delay for the UC500 to detect CLID, works out to the five or six rings you are seeing.

Cheers,

Dave.

Brikers12 · ‎07-14-2009

so can I set that delay to 0 seconds? There isn't any delay setting for call forwarding is there?

I'm also not entirely sure how to change that setting from the CLI, I assume it can't be done via the CCA.

Brikers12 · ‎07-14-2009

OK i think i've made the change to the config, it shows my change in "show running-config", is there anything else I need to do before a setting change like this is applied?

Doing another test it seems its a bit better, the mobile now rings after 4 rings.

Call started from external phone

ring 1

ring 2

Cisco IP-phone starts ringing...

ring 3

ring 4

Mobile phone set in SNR starts to ring...

David Harper · ‎07-14-2009

The additional two rings between the desk phone ringing and the mobile phone ringing is probably due to setup times in the PSTN. You could check this by placing a call from the desk phone to the mobile phone and see how long it takes before the mobile phone starts to ring. That will give you a baseline of the setup time for the mobile network. But two rings doesn't sound all that unreasonable. I'd expect it to be quicker going to a land line.

Cheers,

Dave.

Brikers12 · ‎07-14-2009

I just tested calling from one of the Cisco phones to an outside mobile and land line, there was no difference in time it took for the first ring, both were 2 rings. I've also tried with a residential line and a business line from the Telco, made no difference.

So if its 2 rings to make any connection, and this is reasonable, do people actualy use this SNR feature? 4 rings is a lot of time for a customer to be waiting on the line before even the first ring on my end, by the time I pickup the mobile phone it could be 2 more rings. If I were the one calling I would have hung up by then.

David Harper · ‎07-14-2009

I take your point about the delay, and agree it is not ideal. Just to break it down a little so you can see where it is coming from:

1. Two rings to detect CLID before extending the call to the desk phone and SNR

2. Maybe a second to dial the phone number out the analog trunk

3. Setup time in the PSTN before the remote phone rings

#1 is specific to analog trunks, since we get CLID information in between the first and second ring. The use of a ditital line such as ISDN or SIP will eliminate this. There is also a CLI command that will make the desk phone ring immediately we detect the call, but you won't see CLID on the phone until a few seconds later once we have collected it from the PSTN. This can be confusing for some people, which is why we default to suppressing the call until we have the CLID.

#2 again is specific to analog trunks, but should not be more than a second depending on the number of digits to be dialled.

#3 is a bit unpredictable, but I'm surprised it is taking as long as it is when calling a land line. Can you capture the output of 'debug vpm signal' again, but make sure you enable timestamping of debug messages by first configuring 'service timestamps debug datetime msec localtime' before reproducing. But there may not be anything we can do about this. Once the trunk has been siezed and the number dialed, we are at the mercy of the PSTN.

Cheers,

Dave.

Brikers12 · ‎07-14-2009

thanks again for the replies.

How can I configure this?

dharper wrote:

There is also a CLI command that will make the desk phone ring immediately we detect the call, but you won't see CLID on the phone until a few seconds later once we have collected it from the PSTN. This can be confusing for some people, which is why we default to suppressing the call until we have the CLID.

I don't mind not having the CallerID right away if it makes the SNR reach a bit faster.

Is there anything that could be changed on the Telco's PSTN side? Anything I can ask them about?

I will have to wait until tommorow to conduct another test, I assume you mean testing with the SNR number set to a land line and not a mobile.

David Harper · ‎07-14-2009

If you look under the voice-port configuration for your trunk lines, you will see a command similar to 'connection plar opx 200'. What you need to do is modify this with the immediate keyword: 'connection plar opx immediate 200'. This will extend the call out to the deskphone immediately.

As for the debugging, please do configure the snr destination to a land line for this test, as the land lines are more consistent than mobiles when it comes to call setup times.

Cheers,

Dave.

Marcos Hernandez · ‎07-15-2009

Don't forget to do a "shutdown," and then a "no shutdown" under the voice port after making this change.

Thanks,

Marcos

Brikers12 · ‎07-15-2009

do I type "shutdown" while still in "UC520(config-voiceport)#s" ?

I tried typing shutdown and no shutdown there and there was no feedback at all.. so i guess it worked?

I also tried running another debug, but i'm not sure how to enable "service timestamps debug datetime msec localtime". That isn`t a valid input at UC520#

Marcos Hernandez · ‎07-16-2009

Yes. "shutdown" followed by "no shutdown" under the voice port. Then type "exit" and enter the "service timestamps..." command. Save your config with "wr mem".

Thanks,

Marcos

David Harper · ‎07-14-2009

Yes, this can be set to zero using CLI, and no it cannot currently be changed using CCA. To change this using CLI, you would use something like the following:

ephone-dn 10

snr 00419123456 delay 0 timeout 30 cfwd-noan 299

And you are correct, there is no delay for call forwarding. The logic behind this is that it gives you a chance to answer the call when you are at your desk before the call gets extended out to the mobile phone.

Cheers,

Dave.