INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

SIP sudden 503 and call problems

SIP sudden 503 and call problems

2
(OP)
If anyone with an IPO configured with SIP trunks is suddenly having problems with calls being denied, but their trunks are registered listen up.  Skip to the fix at the bottom if you don't want to read the background.

The SIP carrier for many of my clients had multiple IPOs stop accepting calls last night 10/25/2010.  When a call was routed to go directly to an AA the IPO would receive the Invite wait roughly 5-7 seconds before responding with a "100 trying" message.  This was tripping a timer on the carrier causing them to cancel the call.  If routing to a phone/HG the IPO would receive an invite initiate ringing and then it seems when the call was answered by VM or a person it would send a 503 to the carrier dropping the call.

After some troubleshooting it appears that the STUN server address preconfigured in the IPO (69.90.168.13) is accepting connections.  However it is not responding to any requests other than allowing the IPO to initiate a client connection.  I'm not sure if it is even a STUN server to begin with or if its just a firewall/server accepting that particular port.  Either way it is not working and causing problems.

The IPO would receive the invite, initiate a connection to the STUN address and attempt to resolve IP/port for traversal of media through NAT.  It does not receive a response from the server and attempts for roughly 5 seconds.  This is causing the long delay for the "100 Trying" message when going to AA.  This also is the cause for the system to send a "503 unavailable" when a person answers the phone.  You can verify if this is your problem by turning on the STUN filter in your monitor.

The Fix:  Open Manager and IPO > Lines > {select your sip trunk/s} > change "Use Network Topology Info" from LAN1 / LAN2 to None.

The carrier we use runs a SBC (Session Border Controller) so there is no need for STUN.  I believe most carriers are running SBCs now anyway.

Hopefully this helps anyone banging their head against the wall.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

Why "None"?

If you use "None" the Avaya uses the "IP route" connected to a gateway address....smile


___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________

RE: SIP sudden 503 and call problems

Thanks, no more banging my head.

Great job on figuring that one out, I was stumped!

Star for you.

 

RE: SIP sudden 503 and call problems

Duffman,

Your solution worked for me on a 4.2 system.

I have a 6.0(14) system with the problem too, using the same VOIP provider as the 4.2 system.  When I change the LAN setting to "None", the IPO won't register.  As I said it is the same provider as the 4.2 system so I don't think there is a need for STUN.

Any pointers on where to look?

RE: SIP sudden 503 and call problems

See my pointer.....check the IP route.

You might need to make a route from you sip providers ip address to the internet GW address.


___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________

RE: SIP sudden 503 and call problems

3
(OP)
@Bas1234 I think I'm misunderstanding what you're saying, but the IPO always uses the IP Route to find its way out.  The difference is it will not try to perform the STUN lookup.  Most carrier's run SBCs so STUN isn't needed in most cases anyway.  Just one more thing to break.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

(OP)
I agree with @Bas1234.  Check the basics.

IP Route (static or gateway route)
Registration Required - checked (If its a registered trunk)
In Service checked
Primary Auth / Password
URI...
I would also make sure you have the appropriate ports opened.

attach SIP stack monitor trace and I can take a look at the registration for you.  Enable SIP RX/TX and sip events in the monitor.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

Had similar problems reported on the 26/10/10 myself
I dont suppose you would care to name the sip provider so i can see if it is the same one telling our customer they have not changed anything smile  

I do not Have A.D.D. im just easily, Hey look a Squirrel!

RE: SIP sudden 503 and call problems

(OP)
I use Broadvox.  It's not the provider/carrier but instead an open internet STUN server that IP Office has pre-programed into the config.

An Avaya engineer's response was, "it is an Open STUN server on the internet that we have no control over".  In my opinion it has no place in the configuration as a default STUN server.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

When I set [Use Network Topology:LAN1] then it registers but I can't make calls and incoming calls ring but disconnect as soon as I go off-hook.

Since it registers when Lan1 is set then we know authntication is correct.  Also trace shows packets received which would indicate routing is correct.

When I set [Use Network Topology:None] then it will not register.  Trace shows the following error "SIP/2.0 407 Proxy Authentication Required".

Here are my register traces.

**********************************************
[Use Network Topology:None]

     42407mS SIP Tx: UDP 192.168.63.190:5060 -> 204.11.192.39:5060
                    REGISTER sip:callcentric.com SIP/2.0
                    Via: SIP/2.0/UDP 192.168.63.190:5060;rport;branch=z9hG4bKecff21d4d3b769292237ef3050c1dd23
                    From: <sip:17772957815@callcentric.com>;tag=61c0c7c01662e3bb
                    To: <sip:1777295XXXX@callcentric.com>
                    Call-ID: 7c923fa6ba30e1a130cbf45851cd320a@192.168.63.190
                    CSeq: 537119876 REGISTER
                    Contact: "Unknown" <sip:17772957815@192.168.63.190:5060;transport=udp>
                    Expires: 3600
                    Max-Forwards: 70
                    User-Agent: IP Office 6.0 (14)
                    Supported: timer
                    Content-Length: 0
                    
     42467mS SIP Rx: UDP 204.11.192.39:5060 -> 192.168.63.190:5060
                    SIP/2.0 407 Proxy Authentication Required
                    v: SIP/2.0/UDP 192.168.63.190:5060;rport=55012;branch=z9hG4bKecff21d4d3b769292237ef3050c1dd23
                    f: <sip:17772957815@callcentric.com>;tag=61c0c7c01662e3bb
                    t: <sip:1777295XXXX@callcentric.com>
                    i: 7c923fa6ba30e1a130cbf45851cd320a@76.235.232.154
                    CSeq: 537119876 REGISTER
                    Proxy-Authenticate: Digest realm="callcentric.com", domain="sip:callcentric.com", nonce="a8e1fa6d7e42a0520db8e431feab179b", opaque="", stale=TRUE, algorithm=MD5
                    l: 0
                    
     42470mS PRN: MZ stubs sip_cbk_fetchTxn  no element found     
**********************************************

[Use Network Topology:LAN1]

     58576mS SIP Tx: UDP 192.168.63.190:5060 -> 204.11.192.39:5060
                    REGISTER sip:callcentric.com SIP/2.0
                    Via: SIP/2.0/UDP 99.149.121.142:5060;rport;branch=z9hG4bK85deedb11736436b942e488d0f4dfa3a
                    From: <sip:17772957815@callcentric.com>;tag=42db341e54e68316
                    To: <sip:1777295XXXX@callcentric.com>
                    Call-ID: 76ad993581008fd09c07d64a431afc24@99.149.121.142
                    CSeq: 1315452378 REGISTER
                    Contact: "Unknown" <sip:17772957815@99.149.121.142:5060;transport=udp>
                    Expires: 60
                    Max-Forwards: 70
                    User-Agent: IP Office 6.0 (14)
                    Supported: timer
                    Content-Length: 0
                    
     58638mS SIP Rx: UDP 204.11.192.39:5060 -> 192.168.63.190:5060
                    SIP/2.0 200 Ok
                    v: SIP/2.0/UDP 99.149.121.142:5060;rport=55012;branch=z9hG4bK85deedb11736436b942e488d0f4dfa3a;received=76.235.232.154
                    f: <sip:17772957815@callcentric.com>;tag=42db341e54e68316
                    t: <sip:1777295XXXX@callcentric.com>
                    i: 76ad993581008fd09c07d64a431afc24@99.149.121.142
                    CSeq: 1315452378 REGISTER
                    m: "Unknown" <sip:17772957815@99.149.121.142:5060;transport=udp>;expires=61
                    l: 0
                    
     58641mS Sip: SIP Line (9) parameter 1777295XXXX registered, expires in 30 seconds (interval 61)
 

RE: SIP sudden 503 and call problems

I always set it to None.
I never used lan1 or lan2.
 

Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

RE: SIP sudden 503 and call problems

(OP)
Me too.  I made the mistake of not changing it on one of my systems which is how I found this out.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

(OP)
@voipp

Perhaps your provider isn't running a SBC and you need to run STUN.  I would give them a call and work with the engineer to see why they are not accepting/receiving your authentication.

Another thing to check is see if your firewall is running a SIP ALG.  That can get in the way too.

Are the 4.2 and 6.0 systems pointing to the same address at the provider?

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

What does STUN have to do with the provider having an SBC?

It's my understanding that STUN is there to ensure that the IP Office correctly builds the SIP packets in the event that your firewall does not have a SIP ALG to get around the NAT problem.
If you don't have an ALG, then you use STUN.  You don't need both.  Either way, you are sending the correct information in the packet for the other end to respond to correctly.

In other words the source address is changed by NAT to that of the external address of the firewall.  But, the SIP headers in the packet still reference the private NATed address of the IP Office.  If the IP Office is using STUN then it can discover what the firewall's external IP address is.  If the firewall has an ALG then it rewrites the packets.  I actually did this yesterday and compared what the IPO sent vs what left the firewall.  x.x.x.x internal ip address became y.y.y.y external address.   

RE: SIP sudden 503 and call problems

(OP)
It is my understanding that if the carrier is running a Session Border Controller it can handle the nat traversal and protocol manipulation.  However it depends on how they have it configured.

For instance, my carrier will handle the packets with internal addresses, but only on their registered trunks.  If I want to run a trunk non registered I have to run the SIP ALG which has been like Russian roulette.

It's pretty much a firewall for SIP and other Voip protocols.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

My problem must have had something to do with the router as bith IPO's are using the same provider but are using different routers.  I changed the STUN server address and have [Use Network Topology] set to Lan1.  It is working now.

RE: SIP sudden 503 and call problems

So as I now understand this the STUN server avaya chose as default has changed something, correct?

Quote:


An Avaya engineer's response was, "it is an Open STUN server on the internet that we have no control over".  In my opinion it has no place in the configuration as a default STUN server.
I could not agree with this more!
defaults should only be placed in the config if it is something avaya have 100% controll over.
 

I do not Have A.D.D. im just easily, Hey look a Squirrel!

RE: SIP sudden 503 and call problems

(OP)
That's right.  Either a change was made or it just wasn't working right.

Chris
ACA- Implement IP Office
 

RE: SIP sudden 503 and call problems

Hahaha
I had problems for the last few days with my two SIP lines and after troubleshooting for 2 hours last night changing router and modem on the system, creating routes in the firewall that I never needed before I found that the STUN server doesn't respond and changed it from the default 69.90.186.13 to a new one it worked right away again.
I thought I put that into a thread so that people will know when I looked and found this one here.
Been just to busy lately to be a lot on here and missed the best things.
i just thought I comment on here to bump this from page 2 back to the first page as I am sure more people are fighting with the SIP STUN problem soon.

Joe W.

FHandw., ACSS

insanity is just a state of mind

RE: SIP sudden 503 and call problems

We're still needing STUN a lot depending on the router, the ALG on some cheaper routers can't be relied on.
Have proven this out with third party software clients or ATA's where the router has been suspect to show the client the net result (same problem the IPO is having with RTP stream not happening.)
Most of our providers have their own STUN they either redirect to or have setup, and is usually pingable, ie STUN.egITSPetc.CO.NZ etcetc.
So that default setting is overwritten on any site we put SIP trunks into.

My basic understanding of ALG is the rewriting of packets from internal to external address and back again so the RTP hits the right device on the inside again.
ie 10 people on the phone using 10 different sets of RTP ports, but on one public IP. each persons packets need to get back to the right port in both directions.

Sorry that's prob not best analogy, but this STUN business is to do with the NAT/ FIREWALL traversal ability.
Short of having a purely public IP on the IPO.... it's gotta get thru/around/over somehow.

Great to see some telco techs rolling their sleeves up with  ports and packets etc.   :)

Chris

 

RE: SIP sudden 503 and call problems

Man this saved my a$$  i wwas wondering why perfectly running systems all on att DSL were all of a sudden having an outage, but none on comcast, or other providers.  In my case it was preventing registration and this solved the problem

Chris whereever you are at I will gladly buy you as many drinks as you want if I am ever in your city ( travel all the time)


Thanks again,

Robert
 

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close