Asterisk behind SIP proxy

[hogle]

Has anyone been able to get SIP proxy transparent to work with Asterisk? When I turn off the proxy and port forward the Aterisk ports, SIP registration and incoming calls work fine. However using the proxy server, only outgoing calls work. My SIP provider reports that the Asterisk server is not registered. Appears to only register for outgoing calls, which do work. Incoming calls fail. Debugging the SIP proxy yields the following error messages:

21:46:26.202 SIP.PROXY ROUTING Transc 0x663a5e8: SIP Request Method = REGISTER.

21:46:26.202 SIP.PROXY ROUTING Using ALG Info to forward transparent outbound REGISTER to <SIP provider IP address>:5060 via UDP.

21:46:26.204 SIP.PROXY ROUTING Modify request for proxy - dec max forwards; add record-route

21:46:26.205 SIP.PROXY ROUTING Adding entry with offeredContact of Contact: <sip:s@<my public IP address>:5060>

21:46:26.207 SIP.PROXY ROUTING Transc 0x663a7d8: Request forwarded.

21:46:26.326 SIP.PROXY ROUTING Transc 0x663a7d8: SIP Response Code = 407 to REGISTER.

21:46:26.327 SIP.PROXY ROUTING ERROR! Invalid address.

21:46:26.327 SIP.PROXY ROUTING ERROR! getResponseDestination failed.

21:46:26.327 SIP.PROXY ROUTING ERROR! proxyResponseAsServer failed.

21:46:26.328 SIP.PROXY ROUTING ERROR! proxyResponse failed.

Any ideas? Thanks.

[Anonymous]

Do you have Asterisk running behind the Adtran? I noticed you mentioned port forwarding. Can you post your configuration and describe how the phones and Asterisk are setup on the network?

[hogle]

Attached is the running-config (edited only for security reasons). With this config I get the registration error messages. This is a live network in the midst of enhancements and upscaling. Eventually VOIP UAs and Asterisk will live on the 192.168.124.0/24 (VLAN 124) subnet. For now, you can ignore the probes/tracks and VLAN 124. The descrete Voip subnet and Policy Based Routing using Tracks have not been implemented yet.

Currently all the UAs and Asterisk are on VLAN 1 192.168.125.0/24. The Asterisk server is inside at 192.168.125.15. Asterisk is running under FreePBX ver 2.9. SIP is configured with 2.2.2.139 as the External IP for registration with a SIP trunk provider. I've tried all 4 combinations of FreePBX's NAT settings (yes, no, never, route) with the SIP proxy. Makes no difference. I've also tried making the PBX External IP the router's inside IP, 192.168.125.2, thinking the proxy would translate it to the real external address "media-gateway ip secondary  2.2.2.139". No, the SIP proxy does not appear to be that smart. Or, maybe I need to better understand the SIP proxy.

To revert to port forwarding, change the config by issing:

Router(config)#no ip sip proxy transparent

Router(config)#no ip sip proxy

Router(config)#no ip sip

and change ip policy-class OutsideMega to the following:

ip policy-class OutsideMega

  nat destination list PublicMega138 address 192.168.127.38

  nat destination list PublicMega140 address 192.168.127.40

  nat destination list PublicMega142 address 192.168.127.42

  nat destination list PublicMega139 address 192.168.125.15

  allow list MatchPing self

  allow list PublicMega self

  discard list MatchAll

(Note: adds "nat destination list PublicMega139 address 192.168.125.15".)

This above changes turn off SIP proxy and port forwards the Asterisk sever ports to 2.2.2.139 as per "ACL PublicMega139" in the config. Registration and incoming calls work with this port forwarding. The registration does work through NAT and incoming calls hit the open RTP ports in the ACL/ACP.

The  PublicMega139 ACL is not used when SIP proxy is turned on. Although, I tied it as an "allow" with the proxy in the ACP. That made no difference either. In any case, I can only get port forwarding to work.

Other registration details are per CallCentric's online instructions. Their advice on this SIP proxy issue is to consult with Adtran. They report having no experience with the Adtran SIP proxy.

[Anonymous]

Hello hogle,

I found that with most firewalls the SIP Proxy feature doesn't work as expected.

With my Asterisk installs I have the following settings:

- Disable the SIP Proxy

- Forward 5060 UDP and 10000-20000 UDP to the Asterisk Box

- Set the External IP in the PBX to the public IP

Let me know if this does the trick.

[hogle]

Thanks unified,

When I wrote the original July 16 post, incoming and outgoing calls were working with what I believed was a configuration that performed port forwarding, proxy disabled, as you suggest. With that config saved to flash, I did another experiment with the SIP proxy that also failed to work. To my surprise, when I reloaded the saved "port forwarding" config, Asterisk port forwarding no longer worked. I'm not sure why it worked prior to the reload. Maybe a route or something got cached thet allowed it to work. In any case, while looking for the cause, I now realize that the above posted config is lacking some policies/routes from the inside to the outside. This site is a little more complex than a classic port forwarding exercise. There are two WANs in which other other traffic is supposed to be policy routed. Plus there are multiple addresses on the WAN ports. One of the issues I noticed is that the previous posted config allows Voip traffic to exit (source from) a different IP than the IP assigned to Voip traffic and known to Asterisk.

I am in the midst of developing/testing a revised config. For the moment, I have voice traffic routed via a gateway until I confirm bi-directional SIP working. This is a live network. So, I have to select appropriate times to test new configs. My goal now is to get Asterisk working reliably via port forwarding just as you suggest. (I have a config to test. Will probably get to test either tonight or tomorrow night.) I will post the progress.

Thanks for the advice. Stay tuned...

[hogle]

After some fixes and clean-up to the previously posted config, Asterisk is working reliably using port forwarding. In the midst of all this there was an independent problem in my Asterisk configuration. On some calls the g.729 codec was being enabled on the sever. This requires a license for anything other than RTP pass-thru. This caused me to think there was an obscure routing, proxy or firewall issue on the new hardware/config.... the Adtran router. Now that is resolved. QOS works great, etc. Asterisk works okay using conventional forwarded ports (both directions), described above and in numerous non-Adtran blogs. Back to the original question or issue:

With all the fixes in place, I re-attempted to get the AOS SIP proxy to work. First, I tried SIP proxy outbound, Example #2 in Adtran's "Configuring SIP Proxy" application guide. Using "show" and "debug" commands, it was apparent that none of the SIP nor RTP traffic was finding its way through the proxy.

Next, I re-tried "ip sip proxy transparent", Example #3 in the guide. This yielded a flood of registration errors, same as posted in the original post. It seems that it would be nice to use the proxy for security and RTP routing. If it works as described to me in my ATSP/IN training, we should be able to allow phones, Polycom in my case, send and receive RTP media directly through the router/firewall. Currently, I have inside phones routing RTP with the outside via the Asterisk server due to NAT and security issues. Even with port forwarding it may be possible to configure Asterisk and SIP reINVITES to route RTP media directly through the firewall beteen UAs. But, that is a topic for a different forum.

The question remains: Is there a way to use Adtran's SIP proxy with Asterisk?

So far, the answer appears to be No.

[Anonymous]

:

Thank you for your participation in the support community.  The AOS devices will absolutely work with an Asterisk PBX configured in SIP proxy mode. 

The following post explains how to configure the SIP Proxy User Templates for an IP PBX configuration (it also links to the documentation guide):  https://supportforums.adtran.com/message/2012#2012

Further, this post explains how to choose the appropriate SIP Proxy mode (it also links to the documentation guide):  https://supportforums.adtran.com/message/3029#3029

If you follow the suggestions in the above posts, AOS devices will have no problem working with Asterisk IP PBXs.  After you change the configuration to SIP Proxy User Templates, if you would like to reply and attach the new configuration, I will be happy to review it for you.

Levi

[hogle]

Thanks Levi,

Reading the info looks like I was missing the user-template in my previous attempts. I am trying to schedule time on the network. Looks like I should be able to make the changes and test on Sunday. I will post the config and results. Stay tuned...

Howard

[Anonymous]

Howard:

Were you able to get a chance to test this with the suggested configuration changes?

Levi

[hogle]

Levi,

I added the user-template. I believe I’m doing the sip proxy as documented. But, I still get the SIP parser error. See attached files.

192.168.125.15 is the Asterisk server. Currently phones do not re-invite. So, all internal phone SIP/RTP is thru Asterisk.

There are three WANs in this config. External VOIP traffic is supposed to only be via 222.222.222.139, on eth 0/1.

Help is appreciated. Thanks

Howard

[Anonymous]

:

There are several things that still appear to be missing.  In the policy-class OutsideMega you still appear to be port forwarding 5060 and RTP ports to the PBX's IP address at 192.168.125.15.  In the previous post I attached, I explained that you need to remove all port forwards to the PBX and simply allow SIP traffic to the ADTRAN unit (in both the public and private policy-classes).  Here is an example:

ip access-list extended SIP-TRAFFIC

  permit udp any any eq 5060

  permit tcp any any eq 5060

ip policy-class PRIVATE

  allow list SIP-TRAFFIC self

ip policy-class PUBLIC

  allow list SIP-TRAFFIC self

Furthermore, the "SIP.STACK ERROR MSGBUILDER SIP PRE-PARSER ERROR (UDP)" error can typically be ignored.  This error message is usually from phones doing a "SIP keep-alive" with an empty packet to UDP 5060.

Please, remove the port-forwards to the PBX and allow SIP traffic to the ADTRAN unit, and let me know the results.  The SIP proxy user-template portion of the configuration appears to be correct.

Levi

[hogle]

Levi,

Thanks for pointing out my oversight. Argh, this is what happens when testing in the middle of the night. This is a live network with limited time to test. I removed the port forwarding and revised the ACL(s) and policy-class. I had a 20 minute window in which I could try the new config. Still didn't work. But, it appeared that some packets were trying to go through the proxy. I double checked the config. It looked correct.

Don't know if this is revelent. But, it apppears that the outside SIP provider/server that we have been using may be handling registrations differently than expected. I observed using sh ip policy-sessions that with this provider there is both a SIP session open outbound as well as one initiated from the outside inbound. I do not see this happen with other SIP servers or providers. This particular provider had us make some custom changes to Asterisk when we were on our old non-Adtran router. I am currently looking into Asterisk settings with this provider.

In the mean time, we have another SIP provider that we just added. Registration is a striaght forward SIP peer relationship. I am awaiting time to test the SIP proxy feature with this provider. We are buying another Adtran router, 3120, to allow me to perform testing without disturbing the live network. I also have another machine on which I can install Asterisk. This is my first Adtran deployment after taking the ATSP/IN course. The goal here was to get everything working on our 3458 and deploy multiple 3120 devices at a couple remote offices and with field personal. I will update you after we get the new router and test. Another advantage with a test platform is that it can be a much simpler config, focusing on the issue being solved.

Thanks for the help, stay tuned...

hogle

[Anonymous]

:

Do you have any further questions on this application or configuration.  Please, let me know if you do.

Levi

[Anonymous]

:

I went ahead and flagged this post as “Assumed Answered.”  If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Levi