Wireshark-users: Re: [Wireshark-users] Need help with troubleshooting VOIP using Wireshark
From: "Steven Pfister" <SPfister@xxxxxxxxxxxxx>
Date: Mon, 11 Aug 2008 16:07:52 -0400
So I probably won't be able to figure this out on my own, correct?

Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister@xxxxxxxxxxxxx


>>> Jaap Keuter <jaap.keuter@xxxxxxxxx> 8/11/2008 4:01 PM >>>
Hi,

NEC's PBXes are usually networked by means of CCIS. It's a proprietary protocol. 
Not much detail is know, apart from what's on their website.

Thanx,
Jaap

Steven Pfister wrote:
> The PBXes are NEC. Model number on the remote side is 2400, I believe. I can find out about the central side. I'm hoping this is what you mean by type...
> 
> The remote sides are connected to the central side over ATM. I can probably try and find out what the trunk protocol is.
> 
> Thanks!
> 
> Steve Pfister
> Technical Coordinator, 
> The Office of Information Technology
> Dayton Public Schools
> 115 S. Ludlow St. 
> Dayton, OH 45402
>  
> Office (937) 542-3149
> Cell (937) 673-6779
> Direct Connect: 137*131747*8
> Email spfister@xxxxxxxxxxxxx 
> 
> 
>>>> Jaap Keuter <jaap.keuter@xxxxxxxxx> 8/11/2008 12:32 PM >>>
> Hi,
> 
> It would be helpful if you could tell us what type of PBX's these are and by 
> what trunk protocol they're supposed to be linked. I guess you don't know the 
> latter, but the PBX info shouldn't be a problem.
> 
> Thanx,
> Jaap
> 
> Steven Pfister wrote:
>> Are there any kind of guides to troubleshooting VOIP problems (if this really is a problem that I'm seeing) using Wireshark? I'm trying to understand some strange network patterns that are going on. We have several remote sites with their own PBXes that connect to a PBX at the central site using VOIP. The VOIP setup was done before I got here, and I've so far had fairly minimal contact with it.
>>
>> A lot of the remote sites seem to have a steady, 24x7 stream of udp packets coming back to the central site. For the most part, the source and destination port numbers seem to be in the 15000 to 20000 range, and I really can't see any kind of pattern to them. It's a different set of numbers each time, and I don't really see many repeats.  Most of the udp packets are from the remote site to the central site, but there are occasionally similar packets from the central site to the remote site (the ones coming from the remote site outnumber the ones going the other direction, though).
>>
>> While this is going on, there are some tcp packets being exchanged. Since I'm not really sure what's going on, this is hard to describe, but it looks something like:
>>
>> 1. remote site sends central site an ack of some previous packet at port 1720
>> 2. a lot of udp packets come through
>> 3. about a minute later, the central site send the remote site a keepalive, and the remote site sends one back
>> 4. immediately after that, the central site sends the remote site an ack of the packet from step 1
>> 5. shortly after that, after some more udp packets, an ack from the remote site to the central site of the packet in step 4 is sent
>> 6. the cycle repeats from step 2
>>
>> This going on fairly constantly, even when the sites are closed (the majority of them are public school buildings). One site, a maintenance building  is sending out 5.5 to 6 gb/day.
>>
>> I really hope I'm not misreading what I'm seeing in Wireshark (I'm still pretty new at it) and confusing the issue. 
>>
>> On the whole, everything is working fine. It's mostly that the large amount of unidentified outgoing traffic is throwing off our bandwidth reports, especially when the sites don't have their normal amount of incoming traffic to hide what's going on.
>>
>> Thank you!
>>
>>
>>
>> Steve Pfister
>> Technical Coordinator, 
>> The Office of Information Technology
>> Dayton Public Schools
>> 115 S. Ludlow St. 
>> Dayton, OH 45402
>>  
>> Office (937) 542-3149
>> Cell (937) 673-6779
>> Direct Connect: 137*131747*8
>> Email spfister@xxxxxxxxxxxxx 
>>

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx 
https://wireshark.org/mailman/listinfo/wireshark-users