Closed Bug 1313454 Opened 9 years ago Closed 9 years ago

SF0 - 705 Boardroom - Teleconference: Unable to dial out

Categories

(Infrastructure & Operations Graveyard :: NetOps: Other, task)

Product:
Infrastructure & Operations Graveyard
Component:
NetOps: Other
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: trecendez, Assigned: dcurado)

Details

**Created from INC0021522** ClearOne VH20 is not dialing out. Device has dial-tone, then busy signal when entering a number. VH20 MAC: 00:06:24:01:5F:E2 IP: 10.251.46.197 Ex: 5705 Dialing plan confirmed to be correct.
Hrm, I don't know what to do with this bug. I've never seen a bug opened for this device before. The device is on the network, and in the correct vlan... [dcurado@admin1a.private.scl3 ~]$ ping 10.251.46.197 PING 10.251.46.197 (10.251.46.197) 56(84) bytes of data. 64 bytes from 10.251.46.197: icmp_seq=1 ttl=59 time=4.54 ms 64 bytes from 10.251.46.197: icmp_seq=2 ttl=59 time=4.43 ms 64 bytes from 10.251.46.197: icmp_seq=3 ttl=59 time=4.57 ms Have you tried rebooting the device? Thanks.
Assignee: network-operations → dcurado
Status: NEW → ASSIGNED
Flags: needinfo?(trecendez)
JustDave had been working on and off during the last few days. Visibility into this is increasing rapidly. Heard it was a PBX issue?
Flags: needinfo?(trecendez) → needinfo?(justdave)
Service Now Ticket INC0021522
Thanks. I have pinged justdave to get his input on this.
Thanks for the help.
So as I already explained on the SN ticket, the device is registering just fine to the PBX, but has never attempted to place any calls. This sounds like a dialplan problem on the device, nothing to do with the PBX. Just for completeness, I'll paste in all the logs I already emailed to Tony... [Oct 20 08:31:49] VERBOSE[9646] chan_sip.c: -- Unregistered SIP '75705' [Oct 20 08:31:49] VERBOSE[9646] chan_sip.c: -- Registered SIP '75705' at 10.251.46.197:5060 [Oct 20 08:33:53] NOTICE[9646] chan_sip.c: Peer '75705' is now UNREACHABLE! Last qualify: 8 [Oct 20 08:34:09] NOTICE[9646] chan_sip.c: Peer '75705' is now Reachable. (14ms / 2000ms) That's the entirety of everything that's been logged for that SIP device from Oct 20 onwards (nothing since then in the log for it either). Looks like that was a reboot, because I also see this in the provisioning logs: Oct 20 08:34:09 pbx1.voip.sfo1.mozilla.com xinetd[9140]: START: tftp pid=1664 from=10.251.46.197 Oct 20 08:34:09 pbx1.voip.sfo1.mozilla.com in.tftpd[1665]: RRQ from 10.251.46.197 filename CLROVoipConfig.txt Oct 20 08:34:09 pbx1.voip.sfo1.mozilla.com in.tftpd[1665]: sending NAK (1, File not found) to 10.251.46.197 Oct 20 08:34:09 pbx1.voip.sfo1.mozilla.com in.tftpd[1666]: RRQ from 10.251.46.197 filename CLROVoipConfig_000624015FE2.txt Oct 20 08:34:09 pbx1.voip.sfo1.mozilla.com in.tftpd[1666]: sending NAK (1, File not found) to 10.251.46.197 So there's been zero attempts to place any phone calls from that device. My guess based on what I've walked through with Guillermo in the past trying to set those up on Jive is that the dialplan isn't set up correctly. (It's obviously registering okay from the log, but it's never placing any calls). Guillermo's reply: ----8<----- Dialplan in the system: <C1DIALPLAN> <SYSCONFIG DIALTIME="120000" FIRST_DIGIT_WAIT="30000" INTER_DIGIT_WAIT="1000" TERMINATION_DIGIT="#"/> <DIGITMAP MATCH="+&" MIN_DIGITS="1" MAX_DIGITS="44" STRIP_FIRST_DIGITS="0" ADD_PREFIX_AFTER_STRIP="" DIAL_STRING="sip:+&@pbx1.voip.sfo1.mozilla.com"/> </C1DIALPLAN> Has the Yoshi's system been unplugged? ----8<----- nobody replied beyond that in the thread.
Flags: needinfo?(justdave)
So the obvious next step here is we need a packet trace while a call is being placed to conclusively prove what the logs are already telling me.
Team I seem to recall something with programming in the past. Have we confirmed the programming we expect is on the clearone device?
I am also curious, it seems that no changes have been made to this space(i.e. Programming) in many months. We seem to be seeing several Voip dialing issues in the environment lately. Are we seeing any similarity?
firmware got upgraded recently because what used to be on them wasn't compatible with Jive.
Firmware has not been upgraded in Boardroom yet. The dialplan and account are setup on the clearone the same as they have been. The Clearone is showing that it is registered to pbx1.voip.sfo1.mozilla.com.
The Yoshi's system is unplugged, and the Clearone's have been rebooted multiple times (latest being this morning 10/28 @8am) The Vh20 is metering when the audio conferencing mode is enabled from the crestron. Multiple attempts to dial out this morning were performed around 8am as well, with no change in results.
Yes the clearone is registered 75009/75009 (Unspecified) D 0 UNKNOWN 75100/75100 10.251.55.6 D 5060 OK (3 ms) 75101/75101 10.251.47.165 D 5060 OK (8 ms) 75104/75104 10.251.47.181 D 5060 OK (8 ms) 75132/75132 10.251.47.133 D 5060 OK (8 ms) 75153/75153 10.251.47.149 D 5060 OK (8 ms) 75209/75209 10.251.47.197 D 5060 OK (7 ms) 75350/75350 10.251.47.213 D 5060 OK (8 ms) 75356/75356 10.251.47.229 D 5060 OK (8 ms) 75704/75704 10.251.46.229 D N 5060 OK (8 ms) 75705/75705 10.251.46.197 D N 5060 OK (8 ms) 75731/75731 (Unspecified) D N 0 UNKNOWN 75750/75750 10.251.46.213 D N 5060 OK (8 ms) 7911ms/7911ms 10.251.41.185 D 5060 OK (14 ms) 7911tt/7911tt 10.251.41.204 D 5060 OK (13 ms) justdave, when you say there have been zero attempts to dialout ... what does that mean. I've tried on multiple occasions. Does that mean asterisk doesn't see any attempts to dial whatsoever?
Flags: needinfo?(justdave)
(In reply to James Barnell [:jbarnell] from comment #13) > justdave, when you say there have been zero attempts to dialout ... what > does that mean. I've tried on multiple occasions. Does that mean asterisk > doesn't see any attempts to dial whatsoever? That is correct. I see it registering, but never see it making any attempts to dial. This morning I have these additions to the logs from that phone: [Oct 20 08:33:53] NOTICE[9646] chan_sip.c: Peer '75705' is now UNREACHABLE! Last qualify: 8 [Oct 20 08:34:09] NOTICE[9646] chan_sip.c: Peer '75705' is now Reachable. (14ms / 2000ms) [Oct 28 08:13:08] NOTICE[9646] chan_sip.c: Peer '75705' is now UNREACHABLE! Last qualify: 8 [Oct 28 08:14:28] NOTICE[9646] chan_sip.c: Peer '75705' is now Reachable. (9ms / 2000ms) Is that about the time you were attempting? Looks like it dropped off the network (or at least stopped answering pings) about then. FWIW, I now (as of 2 or 3 minutes before this comment) have a standing wireshark packet capture going for that phone's IP address. It's a rotating buffer and keeping the most recent 1 hour worth, so let me know within an hour of making a test call so I can grab the capture before it rotates out.
Flags: needinfo?(justdave)
We power cycled the room a couple of times. Mark, can you test again and let justdave know?
Flags: needinfo?(mrichards)
:Freshness tells me this has been fixed now. The VH20s have two SIP profiles in them, and the config for asterisk was apparently in the alternate slot instead of the primary (which meant you needed to dial something in front of the number to use it). The primary SIP profile that you get when you direct dial a number wasn't registered to anything. (This is what it sounded like trying to interpret what he told me anyway).
I'm also told 75101 had the same problem.
I'm told on IRC that this was the problem on 75101 but not on 75705 and 75705 is apparently still not working. I just pulled the packet trace, and there's nothing in it but ARP traffic and a bunch of OPTIONS pings between the device and asterisk, so whatever's stopping it from dialing is happening before it attempts to connect to asterisk (there are no connection attempts aside from the initial registration and the OPTIONS pings).
OK, going back a little ways in the packet trace, I think I have a clue. I think this *is* the problem with 75705 after all, it's just not obvious because.... Asterisk is loaded in both slots. The backup one is succeeding in registering, and the primary one is getting a registration failure. This is why it looks like it's registered, the primary one actually isn't. There is a registration attempt which is getting rejected in the packet trace.
There are no port errors on the ethernet port this is attached to: access1.df701-2.ops.sfo1#sho int gi4/0/24 GigabitEthernet4/0/24 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 00b0.e1ca.a198 (bia 00b0.e1ca.a198) MTU 9192 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 01:00:56, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 2000 bits/sec, 2 packets/sec 56534 packets input, 11664232 bytes, 0 no buffer Received 23 broadcasts (7 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 7 multicast, 0 pause input 0 input packets with dribble condition detected 2629432 packets output, 290769893 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out access1.df701-2.ops.sfo1#
The VH20 had DHCP turned off which is the wrong configuration. It also had the admin hosts as the DNS servers. The Vh20 has since been configured properly, and dialing out is restored.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(mrichards)
Resolution: --- → FIXED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.