PJSIP Jitter Buffer

FreePBX Endpoints
42

Edited the wrong file, this needed to go into /etc/asterisk/extensions.conf

This is finally working, but through it would show up here:

Dialplan reloaded.
[ Context 'macro-dialout-one-predial-hook' created by 'pbx_config' ]
  's' =>            1. MacroExit()                                [pbx_config]

-= 1 extension (1 priority) in 1 context. =-
43

I have some experience with this. May I suggest before you start fixing my method, that you first try it as written.

2 Likes
44

Thanks for all your help, although this does seem to be in the right place from a working perspective but is this even applied to the right channel though? I see this is called by macro-dialout-trunk… It should be applied to the client side of things.

Also what about incoming calls? it seems to have no effect.

EDIT: added to the from-pstn context, but still nothing.

45

I dont know what you mean. You mean applied to the endpoint?

Except this is wrong and will get overwritten on every reload.

If it’s not working for you then perhaps as others have said Jitter Buffer is not what you should be looking towards.

46

Well instead of telling me where it shouldn’t go do you mind telling me where it should then? I mean we could be at this all day…

47

Open “/etc/asterisk/extensions.conf”. Read the first 5 lines.

1 Like
48

Looking through this and discussing with Lorne there is no way for you to use custom files to do what you want and hook into the B leg of the call

49

Thanks for all your help :slight_smile:

Wish we could achieve decent call qualify over HSPA / LTE / WiFi… Just surprised this is still an issue. For now I’ll just follow me to a POTS number but I loose hold music for clients, blind / assisted transfer and if voicemail answers this really screws up me being part of the queue.

:frowning:

50

If I switch to a ChanSIP extension, would it be possible to have a jitter buffer on the B leg?

51

Physics is, unfortunately, still physics. Satellite and wireless both are limited by physical elements that we just can’t change until Quantum Modems exist.

52

All I can say is other voip services like good voice, Skype still have a great quality over these types of links.

One day we’ll get there…

53

Hi all,

Just wondering if there is an update to this… Adding a receive jitter buffer to the B leg of the call. We continue to experience poor call qualify in the field without it.

54

Still trying to get a jitter buffer for the receive side from a device (the b-leg). Setting up a CHANSIP extension then changing Asterisk SIP settings and setting jbenable=yes, fixed 4000, force=yes…

When I call *43 my auto is repeated instantly so it has no receive jitter buffer, when calling 613 791 8378, I can get a 4000 ms delay (just testing here guys) but its applied to the trunk read side of things.

55

So I thought I would revive this old thread… Everyone is working from home these days with VoIP apps on their cell phones. Without a jitter buffer on the leg between the user’s phone and PBX (known as the B-leg) the call quality can be quite poor.

Anyone know if there was ever any progress on this?

56

Bump!

57

The need for a jitterbuffer is dependent on the quality of your network connection, it comes at a cost of better media continuity versus greater delay, at about 100ms , folks will get distressed :wink: .

Basically " you can’t polish a turd" (unless you are a Japanese schoolboy who loves dorodango)

58

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.