NexVortex SIP trunk and UC500 default timeout settings?

Unanswered Question
Oct 19th, 2009

Hey guys,

I'm doing a little SIP trunk testing to determine a good provider for my customer base, and had some general questions as I can't seem to get outgoing or incoming phone calls to work at all.

To keep things simple, I'm using an 8user UC540W with 3 IP phones - a 525G, a 524G, and a 7937 conference phone.  I have a static IP on the UC540, have run through the telephony wizard and everything seems to be working on the LAN/PBX side of things.  The big difference, and the major variable that we are working with (I believe), is that we're working with Satellite internet connectivity rather than terrestrial Internet connectivity.  This is an Enterprise satellite connection, and we have run voice over the connection without problems, but this is our first attempts at SIP trunking from a UC500.  Due to the latency involved inherent in satellite (ping times around 550-700ms), I believe that either UC540 or NexVortex server/switch is timing out.  Is there any way to determine what the default setting is for a SIP acknowledgement on the UC540 and change this if it is too small?

Here is what I have found, if it is helpful:

Outgoing calls:

1. The SIP provider, NexVortex, says that they are seeing an invite from the UC540, but not on port 5060.  On the two calls that we tested, it first saw an invite on 63452, and then on 51677.  Is there any reason why this would not be sent out on 5060?

Incomign calls:

1. On incoming calls, Nexvortex is routing the calls to the proper IP, but is then receiving an "error 500 reason Q850" from the UC540.  What does this error mean?

I am also attaching my config in the event that it helps.  When I look at the SIP trunk status in CCA, it does not show that registration is working, so I assume that's a good place to start.

Lastly, the guys over at NexVortex don't seem to run across the UC500 very often.  If anybody has setup their UC500 to work with NexVortex and wouldn't mind posting a screenshot from CCA (feel free to remove usernames and passwords), I'd appreciate it.  I'm not certain that I have all of the information in the right places.

Thanks,

Seth

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven Smith Mon, 10/19/2009 - 15:55

Could you attach the config?  I do not see it.

Does the SIP trunk provider send calls from multiple IP's or just one?

On the SIP port, are they talking about the source port or the destination port?

sethschmautz Mon, 10/19/2009 - 16:08

Hi Steve,

As soon as I hit "submit", I realized that I had forgotten to attach the config.  You must have been reading it while I was pulling off the IPs, usernames, and passwords.  Anyway, it's on there now.

I'll take a look at the other suggestions also.

Thanks,

Seth

sethschmautz Mon, 10/19/2009 - 16:52

Hi Maulik,

I am a little unfamiliar with the proper way to use the "debug ccsip message", so I went ahead and used CCA to help generate SIP phone debugs for a failed incoming and a failed outgoing phone call.  These are attached.

In addition, I checked the ACLs (as you recommended) for the IP address that I am using for the SIP service.  It is a single IP, and the ACLs (sh run | s i access-list 2) show it as permitted.  I will try the recommendations about confining the SIP requests to port 5060 as the provider suggested to see if that helps.

Thanks for the suggestions, I'm sure we'll get it here soon.  If you have any other thoughts, let me know.

Seth

Maulik Shah Mon, 10/19/2009 - 22:06

Did you try the config to restrict source ports to 5060 and did that help for outbound calls?

For outbound calls - here is what I see:

UC500                nexvortex

   INVITE --->

      <--- 407 Proxy Auth Required

   INVITE with credentials --->

(UC500 retries once more then drops call)

Not sure why the Nexvortex is not responding with a 100 Trying message after the UC500 has sent the INVITE with credentials. Maybe the source port helps here but you need to check this with Nexvortex.

For inbound calls - did you use CCA to configure the inbound DIDs? I see something odd in the config and hence the question. A workaround to test (I know its CLI) maybe to try as below:

ephone-dn  10  dual-line
no number 201 secondary 14068906242 no-reg both

number 201 no-reg primary


ephone-dn  11  dual-line
no number 202 secondary 14068906243 no-reg both
number 202 no-reg primary

See if that helps any. If so I would need to check with the DID config CCA pushes down.

sethschmautz Tue, 10/20/2009 - 08:07

Hi maulik,

I tried to manually setting the port to 5060.  In CCA under monitoring>Reports>Telephony>Sip Trunk Status I get the following:

-----------  show sip-ua register status   -----------

Line          peer           expires(sec)  registered   P-Associated-URI
============  =============  ============  ===========  ================
14068906242                       20043       129           no

-----------  End CLI Output  -----------

Prior to this time, I didn't even get this in the status, so it's a move in the right direction.  I am performing these tests from a different static IP, which may be why it is not registering properly.  I will try again from the Satellite system today.

If that does not work, I'll try the recommendations that you gave in your email for checking the DID configuraiton.  I did configure them in CCA, and tried to keep things as simple as possible.  I know that there are SIP to H.323 translations that need to take place if forwarding to AA so I configured direct dialing to a specific extension (201) on the network.

Thanks again for your time.  I'll reply later today on my progress.

Thanks,

Seth

sethschmautz Tue, 10/20/2009 - 14:16

Alright, here's the latest update.  I have outgoing calls working now.  I think that it was a combination of needing to use port 5060 and making sure that the digest credentials were ALSO included as the user credentials.

Incoming calls are still not working.  The Provider says that they are getting the following error when incoming calls are attempted:

500 internal server error reason Q.850:127

In further communication with the Provider, it sounds as though incoming calls could come from a wide variety of IP addresses, so they asked that UDP 5060 be opened to permit all IP addresses.  I followed what I thought to be the correct instructions on the SIP Wiki that Maulik had referenced above, but in reverse to get the following result (specifically lines 90 and 100):

Extended IP access list 104
    10 deny ip 10.1.10.0 0.0.0.3 any
    20 deny ip 10.1.1.0 0.0.0.255 any
    30 deny ip 192.168.10.0 0.0.0.255 any
    40 permit udp host 216.236.126.230 eq domain any
    50 permit udp host 60.40.160.10 eq domain any
    60 permit icmp any host *public IP* echo-reply
    70 permit icmp any host *public IP* time-exceeded
    80 permit icmp any host *public IP* unreachable (3 matches)
    90 permit udp any eq 5060 any
    100 permit udp any any eq 5060
    110 permit udp host 192.168.10.1 eq 5060 any
    120 permit udp host 192.168.10.1 any eq 5060
    130 permit udp any any range 16384 32767 (25 matches)
    140 deny ip 10.0.0.0 0.255.255.255 any
    150 deny ip 172.16.0.0 0.15.255.255 any
    160 deny ip 192.168.0.0 0.0.255.255 any
    170 deny ip 127.0.0.0 0.255.255.255 any
    180 deny ip host 255.255.255.255 any
    190 deny ip host 0.0.0.0 any
    200 deny ip any any log (239 matches)

Has anybody either seen that same error message or have any other ideas why this wouldn't be working?  Attached is the latest incoming call debug from CCA.

Thanks in advance,

Seth

Maulik Shah Tue, 10/20/2009 - 15:08

For inbound calls - please do not open the firewall to allow for 5060 to be open - that is asking for toll fraud so you want to revert your changes that you made. If you need to add additional IP addresses - please get an exact list from NexVortex (generally they should always have a couple based on your geographical area) and you can add additional IP addresses on CCA 2.1 by going to Configure > Voice > Trunks > SIP Trunk > Advanced.

sethschmautz Wed, 10/21/2009 - 07:05

Hi Maulik,

This is not a long term solution, but was intended to see if there was a SIP server that was a partner of NexVortex that we might have been blocking.  As configured, did it look correct to allow any UDP traffic from any source IP address?  If so, and due to the fact that it still doesn't seem to work, it would seem logical to think that it isn't the ACLs that are blocking this traffic, correct?

Any idea what that error log might be from the UC540W?

thanks in advance,

Seth

Steven Smith Wed, 10/21/2009 - 12:56


Hi Seth,

When I look at the debugs, I don't see it matching dial-peer 3002 on the incoming call leg.  Can you try this?

dial-peer voice 3002 voip
incoming called-number 1406890624[2-3]$


Try adding the $ to the end of the pattern.  If it doesn't let you do that, try creating 2 dial peers both with the $ at the end.

sethschmautz Fri, 10/23/2009 - 11:31

hi Steve,

NexVortex assigned a third DID to the system because they were concerned that the other ones weren't working.  As a result, I have changed my incoming dial plan and dial-peer 3002 no longer exists.  Instead, dial-peer 3000 points to 14068906254 and directs inbound calling to extension 204, and dial-peer 3001 points to 1406890624[2-3] and directs inbound calling to extension 201 and 202.

I entered your commands as shown (but changed it to reflect dial-peer 3000 and 3001) and it didn't seem to change my config at all.  Maybe this change affects something else behind the scenes.  Either way, I continue to get a busy signal on inbound dialing.  Outbound works great.  Here is a cut and paste of my current config:

dial-peer voice 3000 voip
description IncomingSIP
translation-profile incoming IncomingSIP_Called_4
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number 14068906254
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad
!
dial-peer voice 3001 voip
description IncomingSIP2
translation-profile incoming IncomingSIP2_Called_5
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number 1406890624[2-3]
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad
!
!
no dial-peer outbound status-check pots
sip-ua
authentication username nomadgcs password 7 *removed*
no remote-party-id
retry invite 2
retry register 10
--More--                            timers connect 100
registrar ipv4:66.23.129.253:5060 expires 3600
sip-server ipv4:66.23.129.253:5060
connection-reuse
host-registrar
!

Besides rebuilding the site, would anything else help?  Attach a full config?  Phone debugs?

Thanks in advance,

Seth

Steven Smith Fri, 10/23/2009 - 11:55

On Dial peer 3000, can you make the number... 14068906254$

If that doesn't work...

On dial peer 1000, remove permission term.

sethschmautz Fri, 10/23/2009 - 13:55

Hi Steven,

Thanks for the continued help.

I was able to make the changes in the config.  Here are snapshots from the current config:

!
dial-peer voice 1000 voip
description ** Incoming call from SIP trunk (Generic SIP Trunk Provider) **
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number .%
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad
!

!
dial-peer voice 3000 voip
description IncomingSIP
translation-profile incoming IncomingSIP_Called_4
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number 14068906254$
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad
!
dial-peer voice 3001 voip
description IncomingSIP2
translation-profile incoming IncomingSIP2_Called_5
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number 1406890624[2-3]$
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad
!
dial-peer voice 3002 voip
incoming called-number 14068906254$
!
!
no dial-peer outbound status-check pots
sip-ua
authentication username nomadgcs password 7 *removed*
no remote-party-id
retry invite 2
retry register 10
timers connect 100
registrar ipv4:66.23.129.253:5060 expires 3600
sip-server ipv4:66.23.129.253:5060
connection-reuse
host-registrar
!

We are calling from within the 406 area code, so when we dial the number with the leading 406, we get a message saying "You don't need the area code" from the telephone company.  When we dial this from a cell, we get the following:

1. 4068906254 - "All circuits are busy, please try your call again..."

2. 8906254 - rings once, then no sound, then disconnects after about 10 seconds.

I don't know if this would factor in at all, but our NexVortex account is setup to deliver 14068906254 to the UC500, but would NexVortex deliver the entire string of characters if it is only receiving 4068906254 or 8906254?

Thanks,

Seth

Steven Smith Fri, 10/23/2009 - 14:00

They should be delivering the full 14068906254 to the UC500. 

Can you perform the tracing again?  I am interested to see if it is any different.

Maulik Shah Fri, 10/23/2009 - 15:29

Seth

  I did not see you try my suggestion given a few posts earlier - can you please try the below:

dial-peer voice 3000 voip
   incoming called-number 14068906254

!

no dial-peer voice 3002 voip

!

ephone-dn  14  dual-line
no number 204 secondary 14068906254 no-reg both

number 204 no-reg primary

!

ephone 2

  reset

Wait for the phone to reset and come back up - then call 4068906254 based on your local dialing rules.

How are you adding the DIDs in CCA?

sethschmautz Fri, 10/23/2009 - 16:09

Maulik,

Steven had recommended that I move the incoming number to be 14068906254$ and it seems like you're wanting me to remove the $.  Is that correct?

I'll run your commands and see if that makes any sort of a difference and we'll go from there.

As for adding DIDs in CCA. . . I'm only changing the incoming dial plan.  Adding in a number and pointing it (at this point) to a specific extension.

Is there another way/place to do this?

Thanks,

Seth

Steven Smith Fri, 10/23/2009 - 16:12

Go ahead and try Maulik's suggestion.

Also, you could try change the preference on ephone-dn 14 to 10 if you wanted to make just a one line change.

Let us know how it goes.

sethschmautz Fri, 10/23/2009 - 16:57

Steven and Maulik,

I made the changes that Maulik suggested, still with no apparent change.  Inbound calls are still not going through.  I'm going to save this config as is and then rebuild the site on Monday.  ephone-dn 14 current shows the following:

!
ephone-dn  14  dual-line
number 204 no-reg primary
!

There appears to be more info for the other phones.  I'm also not sure how to change the preference to 10 (unsure of the CLI to do this).

I can work on this throughout the weekend so if you have any other passing thoughts, let me know.  Should I try CCA 2.0 in addition to 2.1 to see if that might be a problem with the way that this is being setup?

Thanks for all of your time,

Seth

Maulik Shah Sun, 10/25/2009 - 21:54

I do not think this is a CCA 2.1 issue - if you have sometime Monday send me a private message (am on the west coast) and I would like to do a quick webex and check a few things out.

sethschmautz Mon, 10/26/2009 - 13:47

Hi Maulik,

I have tried to send you a couple of PMs but have not gotten a reply.  I went ahead and reset the UC540W to default settings and rebuilt the config from scratch.  After configuring the SIP Trunk and the incoming dial plan and saving the config, I reloaded the UC540W.  I am able to make outbound calls, but inbound calls are still getting stuck somewhere.  I did try something new - instead of pointing the SIP trunk to a specific extension, I setup a blast group including all of the phones on the network (525G, 524G, CIPC, 7937) and pointed the incoming trunk at that blast group.  Still no incoming calls.

I have attached the latest config and the SIP phone debug for your viewing.

I did purchase the Small Business Pro service contract, but I have not found any information for how to activate and/or use it.  Any info about this would be greatly appreciated.

Seth

Steven Smith Mon, 10/26/2009 - 13:54

Send me a PM with your phone number.  I will give you a call now if you can work on it.

Maulik Shah Thu, 10/22/2009 - 09:42

Seth

For the inbound calls - the ACL did not look right as the SIP traffic would not be sent to the 192.168.10.x IP address. As mentioned earlier - please revert teh ACL changes and add the IP addresses if any via CCA.

One other comment - try as below:

ephone-dn  10  dual-line
no number 201 secondary 14068906242 no-reg both

number 201 no-reg primary


ephone-dn  11  dual-line
no number 202 secondary 14068906243 no-reg both
number 202 no-reg primary

See if that helps any. If so I would need to check with the DID config CCA pushes down.

sethschmautz Thu, 10/22/2009 - 21:22

Hi Maulik,

I tried your suggestions, but so far, the incoming calls do not work.  There were 4 entries in my ACLs for ports 5060, two of which were pointing to the LAN IP of the UC540.  I removed all four and then added 2 back in for the static IP of NexVortex' server.

After speaking with a NexVortex tech today, it became clear that all SIP traffic will be coming from that one specific IP.  They were most concerned that the RTP traffic will be coming from other IPs and that the UC540 might not be allowing these sessions to open dynamically.  I would assume, since others have had success setting up their UC520s and UC540s to use the NexVortex service, that the UC500s ARE doing this automatically.

In addition, NexVortex set us up with a different DID from the ones that were listed here previously as there seemed to be problems with those DIDs.  I think I might try to rebuild the configuration on Monday when I get back into the office with this new information in hand and try it that way.

Thanks for your recommendations.  I sort of think that you are on the right track with the ideas about the dial plans.  When I walk through the Telephony Wizard in CCA 2.1, is it easier/better to create a blast or hunt group and point the incoming SIP trunk at this or instead point it at a specific extension.  I'm trying to remove as many variables as possible to get a very basic system working with the intention of adding complexity after I have established core functionality.

Thanks for your time,

Seth

I have NexVortex running at a couple sites, and have noticed the same problems you have.

The first thing you want to do is disable SIP registration (hopefully you have a static IP). Nexvortex should be configured to just send the calls directly to your static IP, so registration isn't needed. The port issue is that when the UC500 registers the number with nexvortex, it is using a random port, not 5050, as you noticed. Since it is using a random port to register the number, Nexvortex uses that port to send the calls to, which of course the UC500 isn't expecting, so the calls don't go through. Usually just disabling registration resolves this issue.

Take out this command, i don't have it on my nexvortex config..

sip
   outbound-proxy ipv4:66.23.129.253:5060

The second issue sounds like they are sending the call in, but you don't have a DID setup correctly to  answer it. I scanned your config briefly, and it looked like you did have a DID setup and an incoming dial-peer that should work. so i'm not sure on that one.

On a side note, next time you are saving your configuration to a text file, issue the command 'term length 0' at the enable prompt. This will make the entire show run output come out at once, so you don't have to keep hitting 'more, more more'

sethschmautz Mon, 10/19/2009 - 17:06

Cmonks,

I hate to admit it, but I'm learning CLI as I go here, and not very good at reading between the lines sometimes.  When you say "take out this command", what exactly is the command to remove that registration line?

Knowing that you have a few sites using NexVortex and that you have had similar problems is very encouraging (in that it sounds like you have found out how to overcome them).  Did you configure them in CCA or CLI?  If in CCA, I assume that you used the "Generic SIP Trunk Provider" template, is that correct?  I was told to fill out the primary Proxy Server and Outbound Proxy server, and to put my username and password in under Digest Authentication, but I haven't received any word about whether I need the same or different credentials in the "User Credentials" portion of CCA.  I have attached a screenshot of the Test site.

I'm currently using CCA 2.1 if that helps.

Thanks in advance.

Seth

I usually start my configs with CCA, then modify with CLI from there.  But most my SIP Trunk configs work well from within CCA, so i'm sure that is fine.

To disable SIP registration for your DID, do this:

Telnet to device, login. Then perform these commands:

config term

ephone-dn  296
number 14068906242 no-reg pri

That will setup this DID to NOT register with nexvortex. you will have to wait for the existing registration to expire, or call nexvortex and have them clear it. Then be sure that they are setup to send calls directly to your public IP, and you should be all set.

One other thing, make sure the number format is the same on their end and yours. If your system is expecting "14068906242" and they are sending "4068906242" it's not going to work. If i recall, nexvortex does default to include the '1', but double check to be sure.

sethschmautz Tue, 10/20/2009 - 07:48

Cmonks,

Thanks for the reply.  I will run those commands when I get back to the office today and put the equipment back on the satellite system.  I attempted to do the same thing here at home and ended up with the same problems, so I'm assuming that latency is not the problem here.

I have also checked the DID format, at least in the incoming dial plan, to ensure that the leading "1" is there and it is.  If there is another spot to check format, let me know as I haven't been able to find it yet.

Thanks,

Seth

sethschmautz Thu, 10/22/2009 - 21:13

Thanks,

That's helpful to see the screenshot and config.  Mine looks very similar.  Did you have to open any ports for RTP?  That was one of the questions that NexVortex asked.  Is your UC520 behind any other firewall type device (SR520, etc.)?

I have a hunch that my problem lies somewhere in the incoming dialplan, but can't figure out where that is exactly.  I think I might rebuild the site again on Monday of next week to try to sort out the problems from scratch.

Thanks again and if any of this reminds you of similar configuration problems, please let me know.

Thanks,

Seth

wintechllc Sat, 11/07/2009 - 14:45

All,

One possible - and simple - cause of this issue that I have just discovered is that the UC500 cannot process inbound SIP URIs with alpha characters from nexVortex, or any other ITSP. To resolve this, log in to your nexVortex account > My Account > Change Inbound Number Routing and change your Translated entry from nexvortex to your phone number.

I hope this helps,

Matt

bwilliams24 Fri, 04/01/2011 - 11:48

Although this original question was asked back in 2009, I wanted to post my fix to this problem in hopes that it will help others who run into the same issue with the UC500 product and nexVortex as an SIP Provider.  If you read through the numerous replies to this question it was stated that multiple IP addresses are requesting communication with the UC500 device on port 5060.  It was then suggested that you can visit the advanced tab in CCA and permit those additional IP address but that toll fraud could be an issue.  I repeatidly ran into this same problem site after site, but there is an easy fix.  After you set nexVortex up as the generic SIP provider in CCA by follow the directions provided in nexVortex's install document, you then need to go into CLI and delete the following commands.

config t

no voice source-group CCA_SIP_SOURCE_GROUP_CUE_CME

no voice source-group CCA_SIP_SOURCE_GROUP_EXTERNAL

I spent a few very painful days with Cisco TAC and nexVortex TAC working to find the fix for this issue.  The problem is, the UC500 product is designed with these commands as a default.  However, they conflict with the way nexVortex processes calls on their end.  Deleting these commands will also fix any IP to IP calling issues, in case you have customers who are both nexVortex subscribers, have a UC500 device, and do business together.  Since I have incorporated the removal of these two commands as part of my initial set-up process I have not had any issues.

Barbara

wintechllc Thu, 04/12/2012 - 08:49

Dearest Barbara,

I just recieved a Cisco forum update on this (another year later?) that has prompted me to send you the THANK YOU that you deserve. I would imagine that this post has saved jobs, contracts, and possibly lives. I'm not sure what, if any, other SIP providers this affects beyond nV, but this configuration is gol-den. We have considering having this tatooed (something tribal) in your honor.

The only thing I would add to this is that we have seen Service Packs re-add this configuration, so step 2 for us after upgrades is to check the config. Thank you sincerely for making this contribution. You have saved us a lot of pain!!!

Matt

Maulik Shah Mon, 10/19/2009 - 16:03

1. By default the source port for SIP messages that the UC500 sends is ephemeral or random which is per the spec. You can force this to always be UDP 5060 by looking at section 4.4.12 on guide below

https://supportforums.cisco.com/docs/DOC-9562

If the provider requires that SIP traffic always be sourced from the UC520 using TCP or UDP port 5060, this can be changed at a system level as below:

sip-ua
  connection-reuse

2. Need "deb ccsip message" for this to check the reason for the error. One possibility is mentioned here:

https://supportforums.cisco.com/docs/DOC-9830

Earlier posts on NexVortex:

https://supportforums.cisco.com/message/3089282

voganville Sat, 08/11/2012 - 15:20

There is an error in the NexVortex setup guide. Page 3 says to use a predefined template in https://supportforums.cisco.com/docs/DOC-21472. DO NOT USE THIS TEMPLATE.

They also say not to use any Cisco Templates, but the Blank Template is fine with the settings from the setup guide.

Sorry to say, but this template does not work, but a manual configuration according to the guide does!

The template deletes some of the needed settings.

So if you have CCP 3.2 just create a new SIP trunk and follow all the  steps in the UC500 NexVortex guide, but DO NOT IMPORT THIS TEMPLATE.

You can very easily use the blank UC540 template to input your own NexVortex settings.

Also extend the Connect Timer and the Keep Alive to 100 and 600.

Make sure you open ports 5060 for UDP traffic as well.

Actions

This Discussion

Related Content