Have a NetVanta 4430 that will not respond to SIP options reliably

[Anonymous]

I am having problems getting a 4430 running the SBC load R10.9.3.V to reliably respond to SIP option requests.  The NetVanta is connected to two different Acme SBC's.  Some NetVanta always responds to, the other the NetVanta ignores.  Below is an example:

This endpoint is ignored:

08:02:14.234 SIP. MSG OPTIONS REQ RX ping ping

OPTIONS sip:10.77.126.59:5060 SIP/2.0

From: <sip:ping@10.77.126.58>;tag=51e84bf81f5e64392ba35c52342eae1900000v3

To: <sip:ping@10.77.126.59>

Call-ID: 13cc52a01fb3f0323f51fc4f84f49c4300000v3@10.77.126.58

CSeq: 254 OPTIONS

Via: SIP/2.0/UDP 10.77.126.58:5060;branch=z9hG4bKlqmn4s30308gsk8ui5k1

Max-Forwards: 0

08:02:14.234 SIP. MSGSUM OPTIONS REQ RX ping ping sip:10.77.126.59:5060

08:02:18.235 SIP. MSG OPTIONS REQ RX ping ping

OPTIONS sip:10.77.126.59:5060 SIP/2.0

From: <sip:ping@10.77.126.58>;tag=51e84bf81f5e64392ba35c52342eae1900000v3

To: <sip:ping@10.77.126.59>

Call-ID: 13cc52a01fb3f0323f51fc4f84f49c4300000v3@10.77.126.58

CSeq: 254 OPTIONS

Via: SIP/2.0/UDP 10.77.126.58:5060;branch=z9hG4bKlqmn4s30308gsk8ui5k1

Max-Forwards: 0

08:02:18.236 SIP. MSGSUM OPTIONS REQ RX ping ping sip:10.77.126.59:5060

This endpoint is always responded to

08:02:19.673 SIP. MSG OPTIONS REQ RX ping ping

OPTIONS sip:10.77.127.93:5060 SIP/2.0

From: <sip:ping@10.77.125.65>;tag=6c0111b7ef97be7ecedc23ea2dba72060o06ic3

To: <sip:ping@10.77.127.93>

Call-ID: e47f74e8b4b4e3d9aee9b51d8f5faf350o06ic3@10.77.125.65

CSeq: 205785 OPTIONS

Via: SIP/2.0/UDP 10.77.125.65:5060;branch=z9hG4bKrrlrlv10c8i1nk4p81i0

Max-Forwards: 0

08:02:19.674 SIP. MSGSUM OPTIONS REQ RX ping ping sip:10.77.127.93:5060

08:02:19.674 SIP.TDU Transaction accepted by SIP Server

08:02:19.674 SIP.TDU Incoming message received from 10.77.125.65:5060 via UDP

08:02:19.675 SIP. MSG OPTIONS RSP TX ping ping

SIP/2.0 200 OK

From: <sip:ping@10.77.125.65>;tag=6c0111b7ef97be7ecedc23ea2dba72060o06ic3

To: <sip:ping@10.77.127.93>;tag=4be26580-a4d7c63-13c4-ea5b-bee69fa2-ea5b

Call-ID: e47f74e8b4b4e3d9aee9b51d8f5faf350o06ic3@10.77.125.65

CSeq: 205785 OPTIONS

Via: SIP/2.0/UDP 10.77.125.65:5060;branch=z9hG4bKrrlrlv10c8i1nk4p81i0

Supported: 100rel,replaces

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

User-Agent: ADTRAN_NetVanta_4430/R10.9.3.V

Content-Length: 0

08:02:19.675 SIP. MSGSUM OPTIONS RSP TX ping ping 200 OK

Also responds to this endpoint

OPTIONS sip:10.77.127.93:5060 SIP/2.0

From: <sip:ping@199.11.104.70>;tag=a2b91c2963614bcbc705981c7b4254470g0qcm0

To: <sip:ping@10.77.127.93>

Call-ID: 98c29b1cd6ffc53ac0cd8d8af3b594060g0qcm0@199.11.104.70

CSeq: 183596 OPTIONS

Via: SIP/2.0/UDP 199.11.104.70:5060;branch=z9hG4bKg2heb920a8a0pjogh0a1

Max-Forwards: 0

08:49:06.597 SIP. MSGSUM OPTIONS REQ RX ping ping sip:10.77.127.93:5060

08:49:06.597 SIP.TDU Transaction accepted by SIP Server

08:49:06.598 SIP.TDU Incoming message received from 199.11.104.70:5060 via UDP

08:49:06.598 SIP. MSG OPTIONS RSP TX ping ping

SIP/2.0 200 OK

From: <sip:ping@199.11.104.70>;tag=a2b91c2963614bcbc705981c7b4254470g0qcm0

To: <sip:ping@10.77.127.93>;tag=4be38780-a4d7c63-13c4-f552-feb2e67b-f552

Call-ID: 98c29b1cd6ffc53ac0cd8d8af3b594060g0qcm0@199.11.104.70

CSeq: 183596 OPTIONS

Via: SIP/2.0/UDP 199.11.104.70:5060;branch=z9hG4bKg2heb920a8a0pjogh0a1

Supported: 100rel,replaces

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

User-Agent: ADTRAN_NetVanta_4430/R10.9.3.V

Content-Length: 0

08:49:06.598 SIP. MSGSUM OPTIONS RSP TX ping ping 200 OK

I am confused why we see this erratic behavior from the device.

The one that is ignored uses the 10/100 ethernet port, the others that are responded to use the gig ethernet ports

[Anonymous]

I found that if I reboot teh 4430, it starts responding then quits after some call activity.

[Anonymous]

Randy,

Thanks for posting!  This may be an issue that we need to work under a normal technical support ticket.  However, we would typically request a copy of the configuration and the output of the following debug commands on a failure to respond.

debug sip stack message

debug sip cldu

debug sip tdu

debug sip stack level err

debug sip stack level ex

debug sip stack level warn

We may also need to see a packet capture.

Thanks!

David

[Anonymous]

sprint_randy:

It appears you opened a ticket with ADTRAN Technical Support on this post.  Please, reply to this post with the outcome of that ticket to assist other support community members.

Levi

[Anonymous · Accepted solution]

The solution to this problem was found as an IP conflict within the subnet. An Acme SBC and another windows 8 PC were attaching to the network using the same address. All three devices were attached within the same subnet. The Acme blocked all visibility to our 4430 by failing to respond to update requests and the windows PC would eventually show up in the local arp cache. The Acme would respond very quickly whenever we restarted our Adtran 4430 and allow calls to route for a short time (2 – 4 minutes). Then the Acme session agent would fail due to the conflict without generating an alarm. The Acme nor the PC ever indicated there was an IP address conflict. This was not known to us when we performed basic troubleshooting. Neither device responded to option pings and windows PC would eventually overwrite the Acme in the 4430’s arp cache upon each restart of the 4430.