cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
New Contributor III

Adtran NV6330 Hosted SIP Survivability

Jump to solution

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.

Labels (1)
0 Kudos
Reply
1 Solution

Accepted Solutions
Highlighted
New Contributor III

Re: Adtran NV6330 Hosted SIP Survivability

Jump to 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).

View solution in original post

5 Replies
Highlighted
Valued Contributor II
Valued Contributor II

Re: Adtran NV6330 Hosted SIP Survivability

Jump to solution

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

0 Kudos
Reply
Highlighted
New Contributor III

Re: Adtran NV6330 Hosted SIP Survivability

Jump to solution

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 

0 Kudos
Reply
Highlighted
Valued Contributor II
Valued Contributor II

Re: Adtran NV6330 Hosted SIP Survivability

Jump to solution

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    

0 Kudos
Reply
Highlighted
New Contributor III

Re: Adtran NV6330 Hosted SIP Survivability

Jump to 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).

View solution in original post

Highlighted
Valued Contributor II
Valued Contributor II

Re: Adtran NV6330 Hosted SIP Survivability

Jump to solution

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

-Mark

0 Kudos
Reply