You may need to create a SIP trunk specifying the destination of the remote PBX. Use the 10.225.X.X address as your SIP endpoint. Then in your grouped-trunk configuration create an accept pattern for the remote extensions and include that trunk.
Capturing a looped call with "debug voice verbose" will give more insight as to exactly what's going on.
IP routing, crypto and VPN occur after voice routing steers the call to the destination IP so I suspect your issue is with the SIP routing and/or dialplan and not IP routing or VPN.
Thank you for the answer. I will give it a try.
You also touched the other topic - how to troubleshot the Adtran?
I've enabled "debug voice verbose" (and I tyried some other options like sip) but there is nothig appeared/collected during the active debugging.
Any idea why?
If you have no output under "debug voice verbose" and "debug sip stack messages", then the Adtran isn't processing the call. It may be treating it like normal IP traffic, or something else is going on. In your original post you indicated that the Astran was looping the SIP request back to the PBX. What drew you to that conclusion? Could it be a DNS or routing issue causing the call to be hairpinned?
Are you using a non-standard port for SIP and if so is the Adtran configured to recognize it as SIP traffic?
OK. I've figured out for the "hairpinned" calls in Adtran.
There was nothing but my error in the local PBX programming pointing to the wrong address. So, it was my fault.
Now it is corrected and I see that my INVITE message is delivered to Adran's local Ethernet interface - 192.168.101.35. Then Adran responds with "503 - Service Unavailable" message.
Honestly, I am not sure if this response is from my destination PBX - 10.225.0.12.
Is there any way in Adtran to trace the remote "SIP" network - 10.225.0.x?
For SIP messages I use a standard UDP port 5060. Nothing special.
I could be mistaken (please correct if so), but how I see this configuration, Adtran, as a VPN' tunnel provider, should be transparent for SIP messages and should not proxy them.
If you want to turn off all SIP processing in the 908e, the command "no ip sip" will do so and the device will function as a straight router/firewall. This usually isn't how the devices are deployed, as enabling SIP handling allows use of the voice ports, MOS scoring, and a host of other features.
As far as a trace to the remote side, that would be within the crypto and policy-session rules. You may have better information with tools such as traceroute using the connected hosts than the Adtran as the source for troubleshooting. Packets sourced from or destined to a router are treated differently from traffic transiting it.
Sorry for the dummy question: from where to submit this command (no ip sip)?
Can I do the same from web GUI?
Also for crypto and policy-session, where these menus in the web GUI? I can not find them.
Many of the more advanced features are CLI-only, and once you become accustomed to using the CLI you'll probably prefer it. There is a "Telnet to unit" option under the Utilities tab that will bring up a telnet window on most systems. Debug and show commands are pretty much CLI-only. If you want to be proficient in configuring and troubleshooting most network gear, learn the CLI. You'll find that the Adtran CLI is very similar to that of another somewhat well-known network equipment manufacturer based in California's Bay Area.
You can turn off SIP globally via GUI under Voice -> Sip Services -> Main Local SIP Service.
I've made this setup working!
Initially, my assumption was not to involve Adtran into the SIP messaging. As such, there are no SIP trunk' settings configured in Adtran.
My error was that, in my SIP PBX, I configured the address of Adtran as a external SIP proxy. Because of this, Adtran supposed modifying the SIP headers which I did not want to happen from the beginning. It is understandable why Adtran was rejecting those messages.
So, eventually I did the following:
- I used Adtran as a VPN creator/keeper only (no SIP programmed there);
- In my SIP PBX, I removed all settings that previously pointed to Adtran as a SIP proxy or SIP gateway;
- In my SIP PBX, I programmed the only address of the far end SIP peer (10.225.0.12)
- In my SIP PBX, I changed the Default Router's IP address from 192.168.x.1 poiting to Adtran instead. In this way, whatever leaves my SIP PBX will be routed to Adtran by default.
After all that, I was able to make and receive the calls between 2 subnets (192.168.x.x and 10.225.x.x).
However, there was the issue with one-way audio at my side when the calls were answered.
That issue persisted because my local phones were residing in 192.168.x.x subnet and their Default Router was not changed. As soon as I point all my phones to Adtran as a Default Router, everything started working normally.