asterisk users - Aug 2008 - Asterisk might be dropping RTP packets before reaching eth int?

[This email is either empty or too large to be displayed at this time]

On Wed, Aug 13, 2008 at 7:40 PM, Jonathan Miller <iamfromit at gmail.com>
wrote:
> From what I can determine while troubleshooting a voice-dropping
> issue, the Asterisk server in my organization has been dropping RTP
> packets between the asterisk server process and the network interface.
>
> I determined this from an RTP debug that showed packets sent to the
> phone and packets received from the phone during the entire call. A
> tcpdump done on the server for the interface that would deliver the
> packet to the wire does not show the packets.
>
> Is there somewhere I can look to resolve this? Something anybody has
> come across? It is happening frequently and with great discomfort to
> many users.
>
> I had upgraded from 1.2.x to latest 1.4.x in attempts to resolve this.
> I also disabled a lot of COM/LPT and USB devices in the BIOS to free
> up some IRQ's. no devices are sharing IRQ's at this point, with I
> thought might have been part of the issue, but has proved to at least
> not be directly related.
>
> These calls are from a PRI to a Cisco 7940 using SIP. There is a
> Juniper EX switch between the two. Both sides negotiate at
> 100Mbps/Full Duplex.
>
> I have ruled the switch out of the problem as it's not seeing the
> packets on the wire when the issue is occuring.
>
> Please help or point me to someone that can.
>
> -Jonathan
> iamfromit at gmail.com
Jonathan,

It sounds hardware specific to me.  Is this a new install or a new problem?

If it is a new problem, then what has changed?  Is the NIC in question
onboard?  What hardware are you using?  Brands, MoBo, NIC, etc...

If I were you, I would remove or disable the NIC and stick a tried and
true old school 3Com NIC in the server and try that.

Thanks,
Steve Totaro

Er, it would be one integrated with the MoBo, on the board if you will...

Thanks,
Steve Totaro

On Thu, Aug 14, 2008 at 11:50 AM, Eric ManxPower Wieling
<eric at fnords.org> wrote:
> What would "on-board NIC" be?
>
> Jay R. Ashworth wrote:
>> On Wed, Aug 13, 2008 at 11:54:23PM -0400, Steve Totaro wrote:
>>> "NIC card" is redundant ;-)
>>
>> And you can take that to the ATM machine.
>
> --
> Consulting for Asterisk, Polycom, Sangoma, Digium, Cisco, LAN, WAN, QoS,
> T-1, PRI, Frame Relay, Linux, and network design.  Based near
> Birmingham, AL.  Now accepting clients worldwide.
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
> Register Now: http://www.astricon.net
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

On Thursday 14 August 2008 10:52:57 Doug Lytle wrote:
> Jay R. Ashworth wrote:
> > On Wed, Aug 13, 2008 at 11:54:23PM -0400, Steve Totaro wrote:
> >> "NIC card" is redundant ;-)
> >
> > And you can take that to the ATM machine.
>
> And use your PIN number.
>
> Sorry, hadda do it.
For to purchase a SCUBA breathing apparatus?

-- 
Tilghman

On Sun, Aug 17, 2008 at 7:10 PM, David Backeberg <dbackeberg at gmail.com>
wrote:
>> This is weird. Any help you can offer would be appreciated. We spent 6
>> hours on phone with Digium support yesterday and could not locate an
>> issue within asterisk itself.
>
> Have you tried putting a soft phone on the same machine as the
> asterisk box? Put a sound card in there, connect a microphone, or at
> least a speaker, and try calling your soft phone. Does the call go
> through between the system and itself?
>
> Am I the only person who has suggested that?
>
At this point, if I were you, I would get a different server, an HP,
IBM, SuperMicro, or something that is known to work well with
Asterisk.  After how many hours of troubleshooting do you give up
because you are wasting more time/money than it would cost to buy a
new box and be done with it?

If it is hardware, I give up after about eight hours or less.

Thanks,
Steve Totaro

Thanks,
Steve Totaro