On 6/26/2011 4:24 AM, Michael Picher wrote:
> This is a totally different problem that you're describing and it's
> important to separate the two.
>
> You really need to make sure your up-stream connectivity is taken into
> account and consider your method of terminating the call locally.
I apologize for the confusion. Since my initial post, I've always been
wondering if the issue with users experiencing dropped syllables was a
hardware issue or a network issue. One of the users did mention that
they experienced an issue with the voicemail as well so I added that to
my question too. I'll do a better job of keeping things separate in the
future.
>
> Are these calls through your SIP trunk or through your AudioCodes gateway?
These calls are going through a SIP trunk as well as the AudioCodes
gateway. The SIP trunk is used for long distance calls and the
AudioCodes is used for calls in the same area code.
>
> If through your SIP Trunk, is sipXbridge terminating your trunk,
Yes.
> who's your provider,
VOIP.MS
> what's your firewall and how are you prioritizing RTP
> outbound above all else?
I'm using a Cisco 1811. You may recall that that we looked at that and
agreed that it was fine. I provided you with the configuration and
statistics. Here they are again:
sarrouter#show policy-map interface fastEthernet 0
FastEthernet0
Service-policy output: VoIP
Class-map: VoIP.Signal (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip dscp cs5 (40)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip precedence 3
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip precedence 4
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 5 (%)
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: VoIP.RTP (match-any)
3006 packets, 1276178 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs4 (32)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip dscp ef (46)
2128 packets, 694503 bytes
5 minute rate 0 bps
Match: ip precedence 5
878 packets, 581675 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 70 (%)
Bandwidth 2100 (kbps) Burst 52500 (Bytes)
(pkts matched/bytes matched) 2986/1274378
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
39277230 packets, 12329347110 bytes
5 minute offered rate 38000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/28/0
exponential weight: 9
You commented on 6-22-2011 at 11:48 AM that, "Yea that looks good for
RTP... you don't seem to be matching any signalling but that's probably
not an issue..."
> If SIP Trunks / remote users are going to be
> critical to the success of your system consider separate upstream
> connection for them and also consider an off-board session border
> controller (like an Ingate). If you are going to 'cheap it out', you
> may need to live with some little issues.
I think this is where I may have caused the confusion. When I mentioned
remote users, I was referring to remote callers who were having
conversations with the local users who are on the sipXecs system.
Currently, the local users are all at one location so I was referring to
the remote callers on the other end of calls going through the
AudioCodes gateway or the SIP trunk. Those remote callers can hear the
local users just fine but the local users experience dropped syllables
when the remote callers are talking. Also, just to be clear, since
upgrade, I haven't had any users complain about the voicemail so that's
a good thing.
>
> If through your AudioCodes gateway, what rev of the firmware are you on,
> how was it configured, are these copper lines or are they handed off by
> some sort of CPE gear (cable modem, IAD, etc.)?
The AudioCodes gateway is using firmware version 5.80A.023.006. It was
configured using sipXecs. The lines are copper.
>
> The 6 P's apply to all voice over IP solutions... Proper planning
> prevents p*ss poor performance....
>
I agree. That's always good advice.
>
> On Sun, Jun 26, 2011 at 2:50 AM, Alex Brown <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 6/24/2011 7:58 AM, Tony Graziano wrote:
> > As I've said, the FS update eliminated that same stutter we all
> had at
> > some point. You probably haven't moved to the most recent patch, be
> > aware it does make polycom template changes, so when the system comes
> > up it will reboot the phones.
> >
> > On Fri, Jun 24, 2011 at 7:55 AM, Michael Picher<[email protected]
> <mailto:[email protected]>> wrote:
> >> At a minimum you've cleaned up your QOS :-)
> >> But as Tony suggests, I'd still do a 'yum update'.
> >>
>
> I did a 'yum update' on Thursday night (June 23) and now I'm at version
> "4.4.0- 2011-06-22EDT11:58:30 ip-10-72-38-198." Unfortunately, users on
> the local LAN are still experiencing the dropped syllable issue when
> speaking with remote callers but there hasn't been any mention of users
> experiencing the stutter when listening to voicemail. Thank you for the
> suggestion to upgrade.
>
> Since we've verified that the QoS has been set properly (thank you, :-))
> and this is a gigabit LAN, is it possible that there is some electrical
> interference causing the issue with dropped syllables? Have either one
> of you had experience with that being the cause of VOIP problems? One
> of the on-site techs was wondering if there might be some EMF
> interference.
>
> Thank you both for your help thus far. I really appreciate it.
>
>
> _______________________________________________
> sipx-users mailing list
> [email protected] <mailto:[email protected]>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
> --
> Michael Picher
> eZuce
> Director of Technical Services
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> www.ezuce.com <http://www.ezuce.com>
>
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
