FPBX13 RC, G722 and 1-way audio - even to voicemail

Beta Program Issues
,
69

@tm1000 - Read my post again. Take your time, read carefully. I clearly said:

  1. You removed your snarky comments from your reply to me.
  2. You edited my post where I quoted your snarky comments and removed your words.

My point was, since you can remove the evidence from anyone’s post that you were confrontational, there isn’t much point in disagreeing with you. You can go to town to make sure anyone coming along later sees what a nice person you are and what a jerk I am. While the evidence above no longer shows it, you and I both know it isn’t true.

What is frustrating is that although you claim you are being helpful, trying to fix anything that can be identified as broken, you keep ignoring legitimate discussion on the topic and keep pointing the finger back at me. Again, if you read my last post, you will see I asked you a question:

You changed course. You firmly stated FreePBX was not the cause of the problem, and the problem should be reported to Asterisk/Digium. Something made you determine that this is not an Asterisk issue. Since you took a firm stand that it is not a FreePBX issue, nor is it an Asterisk issue, you must have based that on something you learned in your testing. Do you care to share it with us? What moved you to eliminate Asterisk as the problem? Did you identify where the problem lies?

You may also recall that I made note that the community had become confrontational and condescending. This is a prefect example. You apparently have some new information, but it is beneath you to share it with us? Stop arguing and answer questions about the discussion topic.

70

The problem is outside FreePBX. That’s what I am implying. I don’t think it’s an Asterisk bug anymore because I tried it on a Yealink T38g, Grandstream GXP 2200, Digium D70 and a couple of soft phones.

Look. I am saying the same thing. Above earlier before you pointed the finger at me that’s what I was saying over and over again and you got offended at that. Therefore I didn’t think it was productive to say “it works for me” any longer unless it wasn’t. But you also don’t seem to like that?

I never changed course. I said the issue isn’t FreePBX. It appears to be Asterisk. Then I said I don’t think it’s Asterisk. You are twisting my words around. I tested this in front of and with @xrobau and @lgaetz. In fact I asked them to work on it with me.

There is nothing I am not sharing. We (Rob & Lorne and I in person) discussed it and this thread for a good 30 minutes to an hour. Everything that I’ve done has been shared by Rob or Lorne or myself. I’m NOT hiding anything. If anything I’ve encouraged people to work on this thread (you don’t see that from YOUR perspective). By calling both Rob and Lorne and asking them to test individually and then when we are in the office. For you to assume or propose I am trying to hide something and/or therefore I am confrontational and condescending is strange indeed.

In case you want to know I’ve done your EXACT test. With:
linphone
JITSI
Yealink T38G
Digium D70
GXP 2200

You obviously have a big problem with me. I’m not fighting with you. I’m not hiding anything from you. I’m not trying to be condescending. I even apologized. I just don’t understand what the problem is. (Well I do. I just don’t understand why me?). You seem to get along fine with Rob and Lorne. Even after Rob replied to your first post about me (and it was basically the same rhetoric I’ve said this whole time?). SO perhaps it’s just me. I don’t know.

If anything you are being condescending right back to me?

Because this is such a huge deal with you I have restored the post and my comments in full. I shouldn’t have edited my post and then your post. Have a nice day.

71

What we’re saying is ‘we can’t reproduce this’. We’ve tried it, following your step by step instructions, and it works perfectly.

At this point, we’re pretty sure it’s the phone you’re using. So you should probably be speaking to the manufacturer.

If we could reproduce it, we would fix it, work around it, or document it. All we have, at the moment, is a couple of people saying ‘G722 is broken’ - when we use G722 all the time, so we’re pretty sure it’s not.

So how about ‘you guys’ with broken G722 get together and try to find what the common factor is? You’re all using NAT? You have some broken firewall in the way that’s trying to do ALG and is getting confused? Your Network cards have a hitherto-unknown bug that’s cropping up on an invite?

There’s lots of things it could be, but until we (as in, @tm1000, @lgaetz or myself) can duplicate it, we don’t know what it is.

Even a complete system backup of a broken machine, so we can actually see it broken would be good. Anything to help us duplicate it.

Edit: I’m serious about the backup. But, before you send it to me, make sure you restore it, and check that it’s still broken.

1 Like
72

Folks, please. I started this post, not because I necessarily felt there was a direct problem in FPBX, but possibly a bug in the way it was configuring Asterisk - I’ll admit, I felt it somewhat annoying that the first thing that was called into question was some simple customizations around RTP port ranges, but I understand the troubleshooting process and how sometimes even the simplest (and unexpected) things can be the cause.

However, I’d like to share something I discovered earlier this week. Grandsteam has a HUGE bug in their G722 codec - specifically causing it’s RTP timestamps to be all out of sequence (to the point the audio quality can easily become garbage). The 32xx phones were hit pretty hard by it, but so were newer firmwares on the 2130/40/60. Sure enough, testing an older 2140 (pre 1.0.4.x) worked fine with 722 calling into Asterisk, while the 32xx and current firmwares of the 2130/40/60 have this “dead air” issue.

Perhaps Asterisk or PJSIP interprets these as invalid data, causing no audio to flow. I don’t know, but I don’t believe it has anything to do with FPBX anymore, nor do I necessarily believe it’s Asterisk directly (merely how Asterisk interacts with phones that may have an oddity in their 722 audio stream).

That being said, why doesn’t everyone take a deep breath, go back to their corners, and think about why we’re all really here. This is a great system, a wonderful project, and frankly something that the smart guys need to continue focusing on rather than feel attacked. I know when I get attacked repeatedly for doing really cool things, it lowers my drive - Not that that would happen in this case, but why even put those folks through that.

My .02.

Thanks Andrew and Rob for at least digging into this - I know I tend to have a hard time seeing the difference between FPBX and Asterisk (as they’re all bundled into a great package in my mind), but I very much appreciate your efforts in supporting my insanity. :smile:

3 Likes
73

I have seen a packet capture of this happening, and did see something to this effect, so yeah, i believe it. Honestly, the solution to this (and the 10000 other problems involving grandstream/yealink/whatever is to stop using, selling, and recommending anyone use them. You will continue to have problems, there will continue to be close to or zero support from the manufacturer, and the model you’re using will be EOL’ed faster than literally any other brand out there. At this point, there are seriously competitively priced options from all the reputable manufacturers. The best part, of course, is that they will work and the manufacturer will support them. How neat is that?

74

Hi!

What do they all have in common?

  • G722: All of them… Actually nobody reported the same problem with another codec which was not a misconfiguration of some kind, right? Why don’t we see this problem elsewhere? Does the use of G722 require transcoding which would not be necessary with another codec and could this be causing problems? Everyone having this problem can fix it by switching to another codec so if their servers were misconfigured in some way, shouldn’t it affect more than one codec?

As for the rest of the things that were mentioned in this thread, for some people we don’t know if they were using it or not.

PJSIP: kistiandg, Bullfrog.
Asterisk 13: kistiandg, Bullfrog, Starlifter. (It would be verrrrrrry nice to know what the others are using…)
FreePBX 12: Bullfrog.
FreePBX 13: kistiandg, mbello, Bullfrog, Starlifter, czworks
Grandstream: kistiandg, Starlifter.
Linksys/Cisco: kistiandg.
Yealink: Bullfrog, Starlifter, czworks.
CPU Architecture: no information at this time
NAT: no information at this time

A few things that stands out:

  • kistiandg didn’t have this problem with the same phone(s) but with another server. That server was running FreePBX 12 and Asterisk 13 though maybe that version of Asterisk 13 wasn’t as recent as the one we are now using…
  • Bullfrog has a workaround here: FPBX13 RC, G722 and 1-way audio - even to voicemail , did anyone with the problem tried it to see if it fixes the problem for them?
  • Starlifter has the problem with Yealink T38G, Grandstream GXV3175v2, Siemens Gigaset VoIP DECT but his Aastra 6755i is OK… If it was a misconfiguration on her/his part shouldn’t it fail with all of the phones?
  • czworks only has this problem when he wants to use British English. I am the one who pointed out to her/him that it sounded like it could be this problem but what does switching language have anything to do with this problem???
  • lgaetz had the same problem but it disappeared after a restart and did not come back… Was it actually the same problem or did it only have the same symptoms and why did a restart fixed it??? Was it a lack of resources or some kind of memory corruption?

The problem is most likely with the phones or with Asterisk so the FreePBX version surely has no impact… However if Bullfrog workaround works then maybe there could be some way to, at least temporarily, try to do it at the FreePBX level maybe?

Unless someone can explain to me why so many different brands are affected like them using the same codec libraries or some sort of hardware implementation of G722 or something similar my bet is on Asterisk being at cause here…

By the way I see that mbello mentioned this problem on Yealink’s forum, maybe those of you with Yealink could add their voice to his there: http://forum.yealink.com/forum/showthread.php?tid=8330

Good luck everyone with this problem and have a nice day!

Nick

75

When I reported the issue, I was on FPBX 13/*13

The previous server that worked was FPBX12/*13, even though it was warned to be “experimental” (I like living on the edge). :smile:

76

Thank you!!!

Do you still have that server? Since you talk at the past tense I guess not, right? It would have been interesting to know if Bullfrog workaround worked for you…

As in FreePBX 12 / Asterisk 13?

Any idea of the version of that Asterisk 13? If Asterisk is the culprit it would be something that was added after that version…

Me too, especially when it’s my home server… :wink:

Thank you and have a nice day!

Nick

77

If we’re going to try to nail this down, we need all the information. I mean everything.

Complete Asterisk version, CPU Architecture, NAT or Not NAT, Phones that are playing up with explicit firmware versions… Everything.

(And I’m serious about CPU Architecture, is anyone not using 64 bit?)

78

Now testing with two phones with g722, one with audio, one without.

Environment:

  • 1 Grandstream GXP2160 w/ firmware 1.0.4.23
  • 1 Mitel 6865i w/ firmware 4.1.0.128
  • Asterisk 13.5.0
  • FreePBX 13.0.6
  • OS: SHMZ release 6.6 (Final)
  • Phones are local on internal NAT network, PBX is hosted on non-natted ip
  • both phones registered to PJSIP extension 2006 on same PBX, didn’t test with chan_sip
  • Extensions codec fields are empty
  • SIP Settings codec set to ulaw and g722 only in that order
dev2*CLI> pjsip show endpoint 2006
*snip*
accountcode                   :
aggregate_mwi                 : true
allow                         : (ulaw|g722)

Mitel audio works, Grandstream audio doesn’t.

links to logs:
Mitel log: http://pastebin.ca/3221725
GS log: http://pastebin.ca/3221730

1 Like
79

The Mitel asked for G722 first:

m=audio 3000 RTP/AVP 9 0 8 101 (Line 32)

The Grandstream asked for G711u.

m=audio 38976 RTP/AVP 0 9 18 2 101

That’s why the Grandstream isn’t working. It’s negotiating G711U, but then trying to use it as G722.

Edit: If you do a ‘core show channel [tab]’ and figure out the channel of the call, asterisk will think it’s G711, no matter what the phone says.

Edit 2: I bet the ‘but it works when I do xyz’ comments end up disabling every other codec so the Grandstream has no choice BUT to negotiate G722 correctly. That’s why it sorta kinda works, sometimes.

80

So knowing the above, I went into the phone config GUIs and made some changes with the codec priorities, but without making any changes to the PBX. The Mitel always properly negotiated audio, always using g722 (when configured) regardless of what I set the codec order to, and if g722 was not configured it would properly use ulaw. The GS phone would NEVER negotiate codecs properly if the phone codec list included both ulaw and g722 in any order. The only way to get audio to work was to force all codecs to either ulaw or force all to g722, in each of these circumstances, audio worked.

1 Like
81

Testing with Yealink T28P has exact behavior of the Grandstream. Making changes only to the codec priority on the phone (not to the PBX), it would never properly negotiate audio if both ulaw and g722 are included in the codec list, regardless of order. Remove one or the other and audio always works.

82

Hi!

That’s actually consistent with what BullFrog noted here: here: FPBX13 RC, G722 and 1-way audio - even to voicemail

Thank you!

We are definitely getting somewhere now with your tests, Rob’s observations and what Bullfrog had noticed…

Have a nice day!

Nick

83

Another data point, ran into this ‘feature’ again today on an HTEK UC806 with firmware ver. 1.0.3.91. No audio until I forced it to use g722.

84

Whoa kids… this thread has generated a great deal of heat relative to light.

Part time outside Asterisk developer here.

The issue here, and the complexity around reproducing it, has to do with a common misreading of the SIP specification by a number of handset manufacturers, one that almost ironically may stem from hardware product development done against older versions of Asterisk itself.

In SIP, there is no requirement that your read and write codecs on a two way audio call leg need to be the same. When you configure a PJSIP endpoint to have ulaw and g722 (and your phone’s initial invite SDP contains those codecs), Asterisk properly assumes that the inbound RTP stream to the phone could be either codec, though the send SDP negotiation has determined the sending codec.

Asterisk is properly trying to avoid transcoding by conforming to both what the PBX configuration of the endpoint has said is allowed and what the device itself has confirmed it is capable of. It happens that a number of sloppy handset manufacturers simply expect to receive the codec they are sending on the ingress-to-handset RTP leg and just drop that RTP stream if it doesn’t meet format expectations. The real issue here is really with manufacturers of these devices. From my limited testing, Polycom, Digium, Aastra and most common softphones conform to the RFC and will work properly. Yealink, Grandstream, and Snom all improperly implement their SDP media expectations, giving you one way audio.

The immediate workaround is to simply restrict either what the phone sends via its own allowed codec configuration or to do what has been suggested in this thread, and lock the endpoint to g722.

It would also be great to put some pressure on these non-conforming manufacturers to do testing with Asterisk 13 + PJSIP in this configuration to see the issue for themselves. At least some of them should acknowledge the issue and produce corrected firmware.

While not necessarily the correct solution, in the interest of pragmatism, if enough people are interested, I might be willing to produce a patch to Asterisk 13 that would surface a new knob to resolve this issue in the Asterisk core. Let me know if there’s an appetite for this and we can discuss.

Hope that helps!

2 Likes
85

Hi and thank you for your analysis of the problem!

Sounds like déjà vu…

(I had similar problem for other network related RFCs…)

I am trying to convince some people (look in the “blog section”…) which are in a position to at least report the problem to do do but I have been unable to convince them to do so…

Thank you very much for your help and have a nice day!

Season’s greetings!

Nick

86

You can report it yourself. We have no priority because we work for Sanomga. Please do not think that. It’s a community project.

87

(sorrrry for the delayed reply…)

I didn’t mean to report them to Digium but actually to Yealink since the problem is most likely in their firmware and FreePBX/Sangoma now having a more direct access to their engineers was in a perfect position to do this.

Preston has contacted Yealink about this so hopefully they will be able to replicate the problem and since they have access to their phone source code they will most likely more easily find what might be causing the problem (what joshelson mentioned seems pretty logical, hopefully this is what they will test first).

As to reporting a problem to Digium, you guys (ie FreePBX/Sangoma developers/employees) have a much higher credibility than most of us as far as these things are concerned so I am sure that it would definitely help.

Before you say that’s not important to have that kind of credibility I once reported a problem to an open source/community project concerning the non-respect of an RFC and got my ticket closed by someone who thought their interpretation of the RFC was correct…

I actually had to contact and ask for the help of the RFC author to have them reevaluate the problem and agree that there was a problem with their interpretation of that RFC.

(This was an email related RFC by the way… Quite a few years ago I “played” a lot with mail servers at work…)

Hopefully not all open source community projects are like that (I sure hope the one I a dev on never gave people that impression) but every little bit of added credibility helps and you guys have a lot more than most of us…

Have a nice day and Happy New Year!

Nick

88

Worked for me. Thanks