Unable to Generate SIP Trunk Signaling from TA904 with R10.7.0.E Firmware

[peterk]

I recently procured a TA904 2nd generation  gateway for lab testing and in potential SMB customer opportunities who wish to cost-reduce their voice networks by utilizing SIP-based PSTN peering. I have the PRI link enabled to a Cisco CME voice server and have been working to establish the connectivity to our preferred SIP-based PSTN provider. The unit is loaded with the latest R10.7.0.E firmware.

A sniffer has been placed on the Ethernet 0/1 interface to observe outgoing signaling traffic so that SIP attributes can be fine-tuned work with the IP-based PSTN provider. The provider uses  a single softswitching proxy for inbound and outbound calls, authenticated registration for inbound PSTN calls, and SIP options to keep the registration alive. There is no authentication required for outbound PSTN calls.

The TA904 unit is in a lab behind firewalls, so the TA904 firewall and ALG has been disabled for the moment.

Our immediate issue is the inability to generate any SIP signaling from the TA904 through the Ethernet WAN port. The firewall was enabled at one point and a policy was defined to allow all traffic through the Eth 0/1 interface  - still no SIP traffic on the WAN side. I have been using the Cbeyond and Cox interoperability documents as framework for provisioning the TA904. FQDNs and explicit IP addresses were pinged from the TA904 console so gateway and default routing appears correctly set.

The TA904 is a new product for us - sincere apologies in advance for the simplicity of the question, but am certain a simple attribute is being overlooked in this setup.

Any insights are appreciated - once SIP trunk signaling can be generated from the unit, we should be able to move through the remainder of the testing in quick order.

Many thanks in advance.

All the best

Peter

[jayh]

Could you post your configuration?

As a rule you will want the firewall enabled and a policy allowing your SIP traffic self-bound on the interface facing the softswitch.  You'll also want media-gateway ip primary on this interface.

Make sure the following are in the configuration:

ip firewall

ip sip

interface eth 0/1

  ip access-policy Public

  media-gateway ip primary

!

ip access-list extended allow-all

  remark Allow in to Adtran

  permit ip any  any   

!

ip policy-class Public

  allow list allow-all self stateless

!

Show commands that may be useful:

show sip trunk-registration

Debug commands that may be useful:

debug sip stack messages

debug voice verbose  (when placing a call in either direction)

[Anonymous]

Peter,

Thanks for posting!  I agree with Jay's post above that the "media-gateway ip primary" is important to have configured on the egress interface.  If you would like to post the configuration, removing any sensitive information such as IP addresses, phone numbers, and passwords, I would be glad to check that over for you. It would be a good idea to check the output of "show interfaces" as well so that you can verify IP interfaces are up and that the D channel is active on the PRI. Also, we typically need to check the debug output on the unit to determine why a call is not sent out a particular trunk.  You can log into the unit and issue the following commands.

enable

(password)

debug sip stack message

debug voice verbose

debug isdn L2-formatted

Then you can place a test call and capture the output of the call being processed.  We can usually determine the issue fairly quickly with that information.  If necessary, you may need to open a Technical Support ticket with Adtran by calling 888-423-8726.

Thanks!

David

[peterk]

Many thanks Jay/David for the responses. We took your template and others, and started comparing the command lines generated by the Adtran Web GUI with SHOW RUN to get our trunk registration up and running. As well we have been able to successfully place outbound calls from both Cisco CME and Shoretel PBXs connected via T1 to the 908E. The firewall is currently disabled.

Inbound calls have been unsuccessful to-date, as we keep encountering  the attached errors from the 908E (output from DEBUG SIP CLDU).

16:49:55.772 SIP.CLDU Cldu::CallLegCreatedEv: (0x2b0d740)

16:49:55.773 SIP.CLDU Incoming CallLeg created from NPANXXXXXX@ITSP_IP:5060 to PBXDIDXXXX@publicIPaddressoffirewall:5060

16:49:55.774 SIP.CLDU ERROR! Request-URI host is not local, unable to proxy incoming message to PBXDIDXXXX@publicIPaddress:5060

16:49:55.774 SIP.CLDU ERROR! Failed to get CLDU Interface, (0x2b0d740)

16:49:55.775 SIP.CLDU Incoming message received from ITSP_IP:5060 via UDP

16:49:55.776 SIP.CLDU CLDU::AppCallLegMsgReceivedEv: Null CLDU Interface, (0x2b0d740)

16:49:55.776 SIP.CLDU Cldu::CallLegStateChangedEv: Null CLDU Interface, (0x2b0d740)->Offering

16:49:55.777 SIP.CLDU Request rejected (404)

16:49:55.778 SIP.CLDU ERROR! Unable to finalize message: (0x2b0d740), (0x0)

The Eth 0/1 interface of the Adtran is currently connected within a lab behind a combined firewall router with a public IP address dynamically assigned to the firewall/router. The invite for an incoming call from the PSTN looks something like this:

INVITE sip:PBXDIDXXXX@publicipaddressoffirewallrouter SIP/2.0
Call-Id: 292d37777da04ad8377204ee36323400@ITSP_IP_Address:5060-0
Cseq: 102 INVITE
From: "DIDCALLER" <sip:DIDCALLER@ITSP_IP_Address>;tag=525783942
To: <sip:PBXDIDXXXX@publicipaddressoffirewallrouter>
Via: SIP/2.0/UDP ADTRANETH0/1_PrivateIPaddress:5060;branch=z9hG4bK2d26178015eea66cc8279620874f06e6353136;sipxecs-id=642b6c3c
Max-Forwards: 19

The interoperability templates we have looked at all show the Adtrans as being directly connected to the public IP network, and the stateful firewall provides the security and necessary NAT translations to process the incoming SIP invite correctly.

My question is whether the Adtran can be configured so that it uses the the address in the SIP 'VIA' message to process the incoming call. From the CLDU output, it appears the Adtran sees an incoming INVITE with  PBXDIDXXXX@publicIPaddressoffirewall:5060 instead of  PBXDIDXXXX@AdtranIPAddress:5060 and does not know how to route the Invite. We experimented with the SIP proxy capability on the Adtran without success....

We are trying to determine whether we can place the Adtran behind the firewall for small business environments where their access is primarily broadband and dynamic public IP address assignment to the firewall/router of the enterprise. The alternative is upgrade of the services to static IP and leverage the rich Adtran firewall capabilities.

If the Adtran can be configured for deployment behind firewall/routers, I'd be glad to provide some generic configurations for you to review.

Hope this make sense - appreciate the support!

All the best

Peter

[peterk]

Just a brief update - we re-configured our lab setup this afternoon to give the 908E a public IP address, and successfully tested incoming and outgoing calls to a Shoretel PBX. Similar results are expected for incoming calls into a Cisco CME voice server.

Any insights and/or sample configurations on the ability to place the Adtran completely within the enterprise domain for SIP-based PSTN calling (my previous question) is appreciated.

Many thanks again for the support.

All the best

Peter

[peterk]

We have Cisco CME up and running with the Adtran 908E. Firewall has been enabled on the public port side. For the moment, we are deferring placement of Adtrans completely within the enterprise domain and taking advantage of the rich firewall capability.

Am impressed with the rich diagnostic capabilities!

Appreciate the support.

All the best

Peter

[Anonymous]

Peter,

I went ahead and flagged this post as "Assumed Answered".  If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be 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.

Thanks!

David