cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2085
Views
5
Helpful
4
Replies

ATA 186 connecting to a SPA3102

jablack04
Level 1
Level 1

I have things hooked up as follows:

PBX<==>SPA3102<==>ATA186<==>Analog phone

IP Addresses:

SPA3102 - 10.1.1.144

ATA186 - 10.1.1.45

SPA3102 Config:

Firmware 5.2.13(GW002)

Line1 is off.
Ethernet cable is connected to the Internet port

On the PSTN Line Tab:

     SIP Port: 5060

     EXT SIP Port: 5060
     Proxy: 10.1.1.45

     Register: No

     Make Call Without Reg: Yes

     Ans Call Without Reg: Yes
     Display Name: 423
     User ID: 423

     Password: 123456

     Dial Plan 1: (S0<:gw0>)

     Dial Plan 2: (S0<:10.1.1.45>)

     PSTN Ring Thru Line 1: No

ATA186 Config:

Firmware: 3.02.01

Under SIP Parameters:

     UID0: 423

     Password0: 123456

     SIPRegOn: 0

     Proxy: 10.1.1.144

Anyway, I can't get these two to work in this configuration. When I try to make a call from the PBX to the ATA186, I see an invite from the SPA3102 to the ATA186. The ATA186 responds with a "404 Not Found".

When I try to make a call from the ATA186 to the PBX, I see an Invite from the ATA to the SPA. Inside this invite it has "sip:<Number I dialed>@10.1.1.144". I then see the SPA respond with a "Status: 100 Trying" followed by a "Status: 503 Service unavailable".

Any insight as to how to connect these two devices together will be much appreciated! Thanks!

1 Accepted Solution

Accepted Solutions

Assuming your Dial Plan 1 is the VoIP Caller Default DP under the Voip-to-PSTN Gateway, I would think the dial plan should be (xx.).  Maybe the (S0<:gw0>) works, I don't know, try (xx.) and see if that makes any difference.  You said you had the PSTN Line Tab UserID set to 423.  If the ATA calls 423 (423@192.168.1.144:5060) the SPA should return a dial tone and wait for the dialing digits.  If the ATA calls the PBX extension number (xxx@192.168.1.144) where xxx is the extension number, then you have one-stage dialing and the SPA3102 should dial that number on the FXO port after it takes it off hook.

The INVITE will show the number sent to the SPA3102.

If you are running WireShark it will format the sip signalling so you can see exactly what is happening.  After you capture a test call you click on Telephony and then "Voip Calls".  WireShark then puts up a screen showing detected VoIP calls.  You click your test call to highlight it and then click on "Flow".  Wireshark puts up another beautiful screen that shows the sip signalling between the ATA and the SPA3102.  My WireShark version is Version 1.6.4.  There may be later versions.

Another Debug tool is the Sip Debug Trace.  You install a syslog program on a local computer, put the local computer's ip address under Debug Server on the SPA3102 System Tab, Set the Debug Level to 3 on the System Tab and set the Sip Debug Option to FULL on the PSTN Line Tab (and the Line Tab too if you are using it).  You can download a simple Windows pc syslog program here:

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

The Sip Debug Trace will show some internal things happening inside the SPA3102 that don't show up in the WireShark Trace, however the WireShark trace shows exactly what is going into and out of the SPA3102 on the ethernet link.

The Min CPC Duration setting you mentioned is for the detection of a CPC signal coming into the FXO port from the attached analog line.  As you know a CPC signal is a complete drop of voltage on the line signalling that the distant party disconnected the call.  You would increase the minimum duration to stop the detection of false voltage drops that would disconnect an in-progress call.  I am surprised that increasing the duration would solve your disconnect problem.

View solution in original post

4 Replies 4

Assuming the PBX is an analog PBX attached to the FXO (Line Port) on the SPA3102, the 503 Service Unavailable could be because the voltage level of the PBX is lower than "Line In Use" setting on the SPA3102.  You will find the voltage of the PBX on the INFO Tab of the SPA3102.  You usually have the "Line In Use" setting about half way between the On Hook voltage level of the PBX and the Off Hook Voltage level.  The SPA3102 is designed to not take the FXO port off hook if the port is in use and the test for in use is the voltage level which is higher when the line is not in use, lower when the line is in use.  An analog PBX often uses a voltage level that is lower than the standard telco voltage levels.

The "404 Not Found" message could be because the Invite to the ATA186 is not sent to 423@10.1.1.45 because of your ip dialing dial plan.  I would try a dial plan of (S0<:423@10.1.1.45>)

First off, THANK YOU!

Okay, so now it works with incoming calls into the SPA from the PBX. Calls from the ATA to the PBX don't work though. I see the line go off hook and the ATA and SPA create a SIP connection, but I get a busy signal from the analog phone. Wireshark shows the SIP session gets established and begins trasmitting VoIP with RTP fine. It is almost like the SPA isn't sending any of the digits to the PBX and eventually the PBX gives up and sends a busy signal on the analog lines.

One other setting I had to change on the PTSN Line tab:

Min CPC Duration: I had to up it to .4 because I would hang up from the PBX side and the SPA would keep the FXO line off hook.

Edit: This definitely looks like an issue with the SPA not sending the PBX numbers. If I switch dial plan 1 to (S0<:287@gw0>), if I dial anything it will ring my desk extension (287).

Any help on this will be much appreciated. Thank you!

Assuming your Dial Plan 1 is the VoIP Caller Default DP under the Voip-to-PSTN Gateway, I would think the dial plan should be (xx.).  Maybe the (S0<:gw0>) works, I don't know, try (xx.) and see if that makes any difference.  You said you had the PSTN Line Tab UserID set to 423.  If the ATA calls 423 (423@192.168.1.144:5060) the SPA should return a dial tone and wait for the dialing digits.  If the ATA calls the PBX extension number (xxx@192.168.1.144) where xxx is the extension number, then you have one-stage dialing and the SPA3102 should dial that number on the FXO port after it takes it off hook.

The INVITE will show the number sent to the SPA3102.

If you are running WireShark it will format the sip signalling so you can see exactly what is happening.  After you capture a test call you click on Telephony and then "Voip Calls".  WireShark then puts up a screen showing detected VoIP calls.  You click your test call to highlight it and then click on "Flow".  Wireshark puts up another beautiful screen that shows the sip signalling between the ATA and the SPA3102.  My WireShark version is Version 1.6.4.  There may be later versions.

Another Debug tool is the Sip Debug Trace.  You install a syslog program on a local computer, put the local computer's ip address under Debug Server on the SPA3102 System Tab, Set the Debug Level to 3 on the System Tab and set the Sip Debug Option to FULL on the PSTN Line Tab (and the Line Tab too if you are using it).  You can download a simple Windows pc syslog program here:

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

The Sip Debug Trace will show some internal things happening inside the SPA3102 that don't show up in the WireShark Trace, however the WireShark trace shows exactly what is going into and out of the SPA3102 on the ethernet link.

The Min CPC Duration setting you mentioned is for the detection of a CPC signal coming into the FXO port from the attached analog line.  As you know a CPC signal is a complete drop of voltage on the line signalling that the distant party disconnected the call.  You would increase the minimum duration to stop the detection of false voltage drops that would disconnect an in-progress call.  I am surprised that increasing the duration would solve your disconnect problem.

Thanks for the help.

I did some reading and thought that using S0 to send it directly to gw0 would be the correct dial plan for VoIP to PSTN calls. It seems to be working great at this point.

Thanks for the other tips as well. I'll go check those out sometime. I'm already using wireshark to help troubleshoot issues with SIP.

I'm not sure why adjusting the Min CPC Duration to .4 fixes the problem. I just know it happened to me twice and I adjusted it and it stopped happening. I tested it some today at .2 again and it did it again, so I think I'm going to leave it on .4 and see if it occurs anymore. Google led me to adjusting this value.

Jonathan

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: