Adtran NV6330 Hosted SIP Survivability

[Anonymous]

I am trying to get a working transparent proxy configuration to provide local survivability for phones registering to our hosted VoIP platform. I have the basic configuration in place and phones are registered but I am not able to make calls. I am looking for troubleshooting commands to hopefully find out where things are breaking down.

[Anonymous]

This config guide will go over all commands and debug.

What type of proxy are you doing?

Guide:

https://supportforums.adtran.com/docs/DOC-1826

-Mark

[Anonymous]

I am implementing transparent proxy and the guide you linked to is what I used for the base configuration as well as pieces from various other articles on the support site. Here is a snippet of what I am seeing (debug voice verbose) when dialing our standard voicemail access star code... it appears that the Adtran is trying to only process the dialed number locally and not sending it up to our platform.

14:19:22.507 TM.Proxy 01 SipTM_Idle           rcvd SIP call-leg request: INVITE
14:19:22.508 TM.Proxy 01 SipTM_Idle           call-leg -> Offering
14:19:22.508 TM.Proxy 01 SipTM_Idle           State change      >> SipTM_Idle->SipTM_Trying
14:19:22.509 TM.Proxy 01 SipTM_Trying         SDP offer is not loopback request
14:19:22.510 TM.Proxy 01 SipTM_Trying         Processing From for Caller-ID.
14:19:22.510 TM.Proxy 01 SipTM_Trying         Caller ID Name   = "ChrisLab VVX5xx"
14:19:22.510 TM.Proxy 01 SipTM_Trying         Caller ID Number = "7009971005"
14:19:22.511 TM.Proxy 01 SipTM_Trying         info: unable to set redirect number(s) from INVITE
14:19:22.511 TM.Proxy 01 SipTM_Trying         sent: TA->InboundCall
14:19:22.512 TM.Proxy 01 Looking up source address for destination 10.0.20.100
14:19:22.512 TM.Proxy 01 SipTM_Trying         Final proxy addresses - source is 10.0.20.1 : 5060, dest is 10.0.20.100
14:19:22.513 TM.Proxy 01 call-leg (0x51e68b8) -> src: 127.0.0.1 : 5060  dst: 127.0.0.1 : 5060
14:19:22.515 TM.Proxy 01 SipTM_Trying         sent: 100 Trying
14:19:22.524 TA.Proxy 01 TAIdle               rcvd: inboundCall from TM
14:19:22.524 TA.Proxy 01 State change      >> TAIdle->TAInboundCall (TAS_Calling)
14:19:22.524 TA.Proxy 01 Failed - DID translation: no match for *318, using *318
14:19:22.525 TA.Proxy 01 TAIdle               sent: call to SB
14:19:22.526 TM.Proxy 01 SipTM_Trying         tachg -> TAInboundCall
14:19:22.526 TM.Proxy 01 SipTM_Trying         State change      >> SipTM_Trying->SipTM_Pending
14:19:22.526 SB.CALL 32 Idle                 Called the call routine with *318
14:19:22 SB.TGMgr Testing Trunk Access List proxy
14:19:22 SB.TGMgr Trunk Access List proxy is Permitted
14:19:22 SB.TGMgr Trunk lists configured in TrunkGroup FAILOVER permit SABR Routing
14:19:22.528 SB.CALL 32 Idle                 No TRUNK accepted dialed number (*318)
14:19:22.528 SB.CALL 32 Idle                 No LOCAL station matched dialed number (*318)
14:19:22.529 SB.CALL 32 Idle                 No routable destination found on call from (7009971005) to (*318)
14:19:22.529 SB.CALL 32 State change      >> Idle->CallIdlePending
14:19:22.530 TA.Proxy 01 TAInboundCall        CallResp event accepted
14:19:22.530 TA.Proxy 01 State change      >> TAInboundCall->TAClearingComplete (TAS_Clearing)
14:19:22.530 TM.Proxy 01 SipTM_Pending        tachg -> TAClearingComplete
14:19:22.531 TM.Proxy 01 SipTM_Pending        State change      >> SipTM_Pending->SipTM_CallFail
14:19:22.533 TM.Proxy 01 SipTM_CallFail       call-leg -> Disconnected
14:19:22.533 TM.Proxy 01 SipTM_CallFail       CallLegStateChanged to Disconnected - TM change to closing state.
14:19:22.534 TM.Proxy 01 SipTM_CallFail       State change      >> SipTM_CallFail->SipTM_Closing
14:19:22.534 TM.Proxy 01 SipTM_Closing        sent: TA->Clear
14:19:22.534 TM.Proxy 01 SipTM_CallFail       sent: 0
14:19:22.535 TM.Proxy 01 SipTM_Closing        State change      >> SipTM_Closing->SipTM_Terminated
14:19:22.535 TM.Proxy 01 SipTM_Terminated     sent: TA->AppearanceOff
14:19:22.535 TM.Proxy 01 SipTM_Terminated     State change      >> SipTM_Terminated->SipTM_Idle
14:19:22.548 TA.Proxy 01 TAClearingComplete   rcvd: clear from TM
14:19:22.549 TA.Proxy 01 TAClearingComplete   rcvd: appearance off from TM
14:19:22.549 TA.Proxy 01 TAClearingComplete   Clear Local Variables
14:19:22.549 TA.Proxy 01 State change      >> TAClearingComplete->TAIdle (TAS_Idle)
14:19:22.550 TM.Proxy 01 SipTM_Idle           tachg -> TAIdle
14:19:22 SB.ProxyCallObserver 31 Created
14:19:22 SB.CallStructObserver 32 Created
14:19:22 SB.CallStructObserver 32 <-> ADTN-FAILOVER-1a8bbb2d5392e84df8393b7b51ab7a12
14:19:22 SB.CallStructObserver 32 Finalized
14:19:22 SB.ProxyCallObserver 31 Created
14:19:22 SB.CallStructObserver 32 Created
14:19:22 SB.CallStructObserver 32 <-> ADTN-FAILOVER-1a8bbb2d5392e84df8393b7b51ab7a12
14:19:22 SB.CallStructObserver 32 Finalized
2017.12.05 14:19:23 SMDR 32         12/05/2017 14:19:22      0.0 0    E  00/00 ChrisLab VVX5xx 7009971005      00/00 Unknown         *318            0 N  

[Anonymous]

can you send your config and make sure to remove all usernames/passwords.

do the following command and send me output

show sip proxy user

do the following debug commands and send output

debug sip stack messages

debug sip proxy routing    

[Anonymous · Accepted solution]

Mark,

Thank you for the debug commands, I was able to find the culprit and things are now working as expected. The issue ended up not being the Adtran but the Polycom phones behind the proxy, I noticed when requests would get sent to the phones from the proxy that they were being ignored by the phones. I ended up digging through the phone configs and found the parameters affecting the proxy functionality.

reg.1.outboundProxy.failOver.reRegisterOn="1" changed to reg.1.outboundProxy.failOver.reRegisterOn="0"

reg.1.server.1.failOver.reRegisterOn="1" changed to reg.1.server.1.failOver.reRegisterOn="0"

I changed these parameters to "0" and everything is now working. From what I can tell, these parameters being enabled in a proxy environment tells the phone to only signal with the backup server. We are using SRV so technically this was telling the phone to ignore signaling from the primary server (proxy).

[Anonymous]

Good deal. Glad you found the problem. Thanks for posting the resolution to your problem.

-Mark