PBXes (http://www1.pbxes.com/forum/index.php)
- English (http://www1.pbxes.com/forum/board.php?boardid=16)
-- Bugs (http://www1.pbxes.com/forum/board.php?boardid=24)
--- (http://www1.pbxes.com/forum/threadid.php?threadid=1213127118)

Distorted sound on callthrough

I set up an extension to forward the calls to SIP URI, the recipient happens to be registered @eu.voxalot.com. I called few times using callthrough from Montreal, Canada - the other party hears me perfectly, but I have seriously distorted sound, although we both hear each other.

To exclude PBXes as a cause I setup DID to forward my call directly to that SIP URI - quality was excellent on both sides. Call through PBXes - I have distortions.

What could be wrong here?

Somewhere along the line of the call, the packetization period is set to 30 ms instead off 20 ms in a SIP User Agent. That is demonstrated as the voice being heard through water on one side of the call.

Does this describe accurately the symptom you are experiencing?

Well, I'd describe it as sound has tiny interruptions few times a second.

The line

Me(PSTN) => DID => PBXes (callthrough) => Voxalot << ATA

What is SIP user agent here - is it ATA, or it can also be something in the middle?

Even if packetization period in ATA set to 30ms, shouldn't PBXes be able to deal with it? When I set up DID to call that SIP URI there was no problems, which means that server managed to get in the right mode?

I did one more test to see if something wrong could be in Voxalot where my recipient registered.
I called the same way, but forced Voxalot to give me a error message instead routing the call to the registered ATA. Everything was OK, no distortions, which to me means that packetization period is most likely set to 30 in ATA.

Diafora, could you help me figure out a workaround? I can't go to that person and demand changing its settings just because I want to call him using PBXes.

Well, the PBXes server is dealing with it, since the call is going through, but as you have experienced the results are not ideal.

In the calls scenario you mentioned, there are 2 SIP UAs, which might have a packetization setting that affects the call, but the most important UA is your friend's ATA, which I am willing to bet is Sipura (Linksys) unit.

Start by asking the person, what kind of ATA he or she has. Then mention, they might have to deal with the issue in the future, if and when they acquire their own DIDs. They might be willing to change the setting on a trial basis.

Thanks Diafora, but please, help me understand this better.

First, he has PAP2T, where 30 is predefined default value

Second, how comes it works when calling from other systems, and it's only PBXes that doesn't work well? Don't you see something illogical in making that ATA as a root cause?

Considering that 30 is the default value for Linksys boxes, and it does work for him everywhere - it doesn't work only for me, and only when using PBXes.

What if a thousand others my recipients buy Linksys boxes with pre-set 30 - should I persuade all of them to change it?

C'mon, guys!

I'm happy to report that after I convinced my recipient to change RDP packet size to 20ms everything looks, no - actually sounds - fine.

Guys, I do realize that this problem is overly boring, but can you do (or at least say) something specific about the fact that SIP URI calls can only be done if the recipient set up with 20ms RTP packet size? You disagree that it's a bug?

There is actually nothing boring with your question, except that you had an answer regarding the root cause of the issue, and I naively believed the explanation could wait for a couple of days.

The slight incompatibility between all Sipura (now Linksys) devices and Asterisk systems is a well known fact, when two Asterisks are used back to back, and the vocoder is either G.729 or G.711. So the bug is clearly on Linksys' side, but someone could argue that it's not really a bug more of a quirk, since the packetization period interval can be changed via the web interface.

Please note Sipura devices have other slight quirks, for which almost all SIP Proxies had to make changes to accommodate them, due to their popularity. One of them is the G.729 vocoder name in the SDP description of the SIP packets.

Regarding the timeframe of our response, I would like to remind you, the support service we provide via the forums is not meant for time critical issues. Occasionally, we would like to take a weekend off and enjoy life too. I am sorry if this affects the flow of explanations, but not the actual support cases!