Adtran
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dnoyes
New Contributor III
‎11-01-2016 01:06 PM

SIP/2.0 487 Request Terminated

I'm suddenly getting this error when dialing between two adtran 7100's.  Does anyone know what would cause this?  Its not constant either.  One time the phone will ring on the other end and the next you will get a fast busy.  When we get the fast busy i notice the "SIP/2.0 487 Request Terminated " message is in the debug repeatedly.  I also get this in the debug too...

Its as if the server 10.13.2.241 is rejecting the call.

14:12:04.662 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

14:12:05.162 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

14:12:06.162 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

14:12:07.475 SIP.STACK MSGSUM  Tx: CANCEL sip:3256@10.13.2.241:5060 SIP/2.0

Tags (2)
0 Kudos
Reply
5 Replies
jayh
Honored Contributor
Honored Contributor
‎11-01-2016 01:41 PM

Re: SIP/2.0 487 Request Terminated

It looks to me as if the server at the other end isn't responding to the INVITE at all, or it's responding and the response isn't reaching the sending end. There's an invite sent, then 500 ms. later re-sent, and then 1 second later re-sent. could there be packet loss between the units? Duplex mismatch perhaps? When the call succeeds, is the audio quality good?

If you turn on SIP debugs on the other side, do you see the INVITE received? Is there a response sent?

0 Kudos
Accept as Solution Reply
dnoyes
New Contributor III
‎11-01-2016 02:37 PM

Re: SIP/2.0 487 Request Terminated

It appears that the connection between locations is functioning correctly.  This is what i get on the other end.  I made a call and initially it rang but then i tried again and it did not work.

15:18:10.881 SIP.STACK MSGSUM  Rx: INVITE sip:3300@10.13.2.241:5060 SIP/2.0 (with SDP)

15:18:10.886 SIP.STACK MSGSUM  Tx: SIP/2.0 100 Trying

15:18:10.892 SIP.STACK MSGSUM  Tx: INVITE sip:3300@10.13.20.3:5060 SIP/2.0 (with SDP)

15:18:10.904 SIP.STACK MSGSUM  Rx: SIP/2.0 100 Trying

15:18:10.942 SIP.STACK MSGSUM  Rx: SIP/2.0 180 Ringing

15:18:10.945 SIP.STACK MSGSUM  Tx: PRACK sip:3300@10.13.20.3 SIP/2.0

15:18:10.947 SIP.STACK MSGSUM  Tx: SIP/2.0 180 Ringing

15:18:10.953 SIP.STACK MSGSUM  Rx: SIP/2.0 200 OK

15:18:13.249 SIP.STACK MSGSUM  Rx: CANCEL sip:3300@10.13.2.241:5060 SIP/2.0

15:18:13.252 SIP.STACK MSGSUM  Tx: SIP/2.0 200 OK

15:18:13.253 SIP.STACK MSGSUM  Tx: SIP/2.0 487 Request Terminated

15:18:13.255 SIP.STACK MSGSUM  Tx: CANCEL sip:3300@10.13.20.3:5060 SIP/2.0

15:18:13.269 SIP.STACK MSGSUM  Rx: SIP/2.0 200 OK

15:18:13.271 SIP.STACK MSGSUM  Rx: SIP/2.0 487 Request Cancelled

15:18:13.274 SIP.STACK MSGSUM  Tx: ACK sip:3300@10.13.20.3:5060;transport=UDP SIP/2.0

15:18:13.755 SIP.STACK MSGSUM  Tx: SIP/2.0 487 Request Terminated

15:18:14.756 SIP.STACK MSGSUM  Tx: SIP/2.0 487 Request Terminated

15:18:16.757 SIP.STACK MSGSUM  Tx: SIP/2.0 487 Request Terminated

15:18:20.758 SIP.STACK MSGSUM  Tx: SIP/2.0 487 Request Terminated

0 Kudos
Accept as Solution Reply
jayh
Honored Contributor
Honored Contributor
‎11-01-2016 02:55 PM

Re: SIP/2.0 487 Request Terminated


dnoyes wrote:



It appears that to connection between locations is functioning correctly.  This is what i get on the other end.  I made a call and initially it rang but then i tried again and it did not work.



15:18:10.881 SIP.STACK MSGSUM  Rx: INVITE sip:3300@10.13.2.241:5060 SIP/2.0 (with SDP)


15:18:10.886 SIP.STACK MSGSUM  Tx: SIP/2.0 100 Trying


15:18:10.892 SIP.STACK MSGSUM  Tx: INVITE sip:3300@10.13.20.3:5060 SIP/2.0 (with SDP)


15:18:10.904 SIP.STACK MSGSUM  Rx: SIP/2.0 100 Trying


This looks like something strange with your dialplan. The receiving end gets an invite for 3300 and responds with 100 Trying as expected. Then 6 ms. later it generates a new INVITE  back to the sending side for the same extension. Where is 3300 located? Is it a shared appearance between the two locations?


15:18:10.942 SIP.STACK MSGSUM  Rx: SIP/2.0 180 Ringing


15:18:10.945 SIP.STACK MSGSUM  Tx: PRACK sip:3300@10.13.20.3 SIP/2.0


15:18:10.947 SIP.STACK MSGSUM  Tx: SIP/2.0 180 Ringing


15:18:10.953 SIP.STACK MSGSUM  Rx: SIP/2.0 200 OK


Shortly thereafter at 15:18:10.942, the receiving end gets a message from the sending end that 3300 is ringing at the sending end. Then it sends a PRACK and starts ringing 3300 locally. Something at the receiving side is trying to ring what should be a local extension at the sending end. Your call is somehow looping as if the receiving side is both trying to ring a local phone and forward the call to the same extension at the sending end.

0 Kudos
Accept as Solution Reply
dnoyes
New Contributor III
‎11-01-2016 03:15 PM

Re: SIP/2.0 487 Request Terminated

The dial plans seem to be correct.  It is strange.  3300 is at a remote location and there is no 3300 extension at the local location.  It appears you are correct though.  I can see that it is trying 3256 (in this example) at the local adtran (10.10.20.1) and then failing.  It works like it should when it tries the remote adtran.  Why would it even try looking for a 3XXX extension on the local adtran if i have them set to go out a trunk to another adtran?

17:25:37.620 SIP.STACK MSGSUM  Rx: INVITE sip:3256@10.10.20.1;user=phone SIP/2.0 (with SDP)

17:25:37.625 SIP.STACK MSGSUM  Tx: SIP/2.0 401 Unauthorized

17:25:37.634 SIP.STACK MSGSUM  Rx: ACK sip:3256@10.10.20.1;user=phone SIP/2.0

17:25:37.637 SIP.STACK MSGSUM  Rx: INVITE sip:3256@10.10.20.1;user=phone SIP/2.0 (with SDP)

17:25:37.643 SIP.STACK MSGSUM  Tx: SIP/2.0 100 Trying

17:25:37.651 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

17:25:37.687 SIP.STACK MSGSUM  Rx: SIP/2.0 100 Trying

17:25:37.745 SIP.STACK MSGSUM  Rx: SIP/2.0 180 Ringing

17:25:37.749 SIP.STACK MSGSUM  Tx: SIP/2.0 180 Ringing

17:25:37.750 SIP.STACK MSGSUM  Rx: SIP/2.0 200 OK (with SDP)

17:25:37.756 SIP.STACK MSGSUM  Tx: SIP/2.0 200 OK (with SDP)

17:25:37.765 SIP.STACK MSGSUM  Rx: ACK sip:10.10.20.1:5060;transport=udp SIP/2.0

17:25:37.770 SIP.STACK MSGSUM  Tx: ACK sip:3256@10.13.2.241:5060;transport=UDP SIP/2.0

17:25:39.573 SIP.STACK MSGSUM  Rx: REGISTER sip:10.10.20.1 SIP/2.0

17:25:39.579 SIP.STACK MSGSUM  Tx: SIP/2.0 200 OK

17:25:39.588 SIP.STACK MSGSUM  Tx: NOTIFY sip:1400@10.10.20.55:5060 SIP/2.0

17:25:39.599 SIP.STACK MSGSUM  Rx: SIP/2.0 200 OK

17:25:40.046 SIP.STACK MSGSUM  Rx: BYE sip:10.10.20.1:5060;transport=udp SIP/2.0

17:25:40.050 SIP.STACK MSGSUM  Tx: SIP/2.0 200 OK

17:25:40.052 SIP.STACK MSGSUM  Tx: BYE sip:3256@10.13.2.241:5060;transport=UDP SIP/2.0

17:25:40.552 SIP.STACK MSGSUM  Tx: BYE sip:3256@10.13.2.241:5060;transport=UDP SIP/2.0

17:25:40.968 SIP.STACK MSGSUM  Rx: REGISTER sip:10.10.20.1 SIP/2.0

17:25:40.974 SIP.STACK MSGSUM  Tx: SIP/2.0 200 OK

17:25:40.977 SIP.STACK MSGSUM  Tx: NOTIFY sip:1205@10.10.20.26:5060 SIP/2.0

17:25:40.993 SIP.STACK MSGSUM  Rx: SIP/2.0 200 OK

17:25:41.553 SIP.STACK MSGSUM  Tx: BYE sip:3256@10.13.2.241:5060;transport=UDP SIP/2.0

17:25:43.082 SIP.STACK MSGSUM  Rx: INVITE sip:3256@10.10.20.1;user=phone SIP/2.0 (with SDP)

17:25:43.087 SIP.STACK MSGSUM  Tx: SIP/2.0 401 Unauthorized

17:25:43.096 SIP.STACK MSGSUM  Rx: ACK sip:3256@10.10.20.1;user=phone SIP/2.0

17:25:43.098 SIP.STACK MSGSUM  Rx: INVITE sip:3256@10.10.20.1;user=phone SIP/2.0 (with SDP)

17:25:43.104 SIP.STACK MSGSUM  Tx: SIP/2.0 100 Trying

17:25:43.113 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

17:25:43.555 SIP.STACK MSGSUM  Tx: BYE sip:3256@10.13.2.241:5060;transport=UDP SIP/2.0

17:25:43.614 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

17:25:44.614 SIP.STACK MSGSUM  Tx: INVITE sip:3256@10.13.2.241:5060 SIP/2.0 (with SDP)

0 Kudos
Accept as Solution Reply
dnoyes
New Contributor III
‎11-02-2016 09:40 AM

Re: SIP/2.0 487 Request Terminated

I found the problem.  The firewall at the main location was incorrectly flagging the calls as DoS attacks.  This must be do to a recent update on the firewall itself. 

0 Kudos
Accept as Solution Reply