Does FreePBX have any settings for PJSIP’s jitter buffer? I can see that it’s implemented in the documentation for PJSIP, but I can’t find any way to enable it for PJSIP in FreePBX, just SIP. Enabling them for SIP is a snap. Does PJSIP share SIP’s settings for jitter buffer?
How does this work?
for pjsip jitterbuffer is handled via dialplan app… We currently have nothing implemented for this. Feel free to add a feature request http://issues.freepbx.org
Thanks! I’ve put the request in.
I need to enable the jitter buffer on PJSIP extensions. This is my first time modifying the dialplan. Following the guidelines here, all I have to do is edit extensions_custom.conf and add the following two lines?
; Enable PJSIP Jitter Buffer
exten => 1,1,Set(JITTERBUFFER(adaptive)=default)
Not quitye you will need to add a context , something like
[yourextension]+
Thank you for setting me on the right path. Does the code look correct for a PJSIP endpoint that is remote? I assume since the extension is configured as PJSIP there isn’t a separate context outside of extensions.conf?
; PJSIP Jitter Buffer - Test x1000
[from-sip-external]
exten => 1000,1,Set(JITTERBUFFER(adaptive)=default)
So I’m confused about this too, I set a fixed jitter buffer of 2000ms and tap on the microphone. Shouldn’t it be delayed by 2000ms? I see the jitter buffer being added as below:
This is from desk phone to desk phone…
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [6000@from-internal:1] Set("PJSIP/3000-00000000", "JITTERBUFFER(fixed)=2000") in new stack
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [6000@from-internal:2] Macro("PJSIP/3000-00000000", "exten-vm,novm,6000,0,0,0") in new stack
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [s@macro-exten-vm:1] Macro("PJSIP/3000-00000000", "user-callerid,") in new stack
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [s@macro-user-callerid:1] Set("PJSIP/3000-00000000", "TOUCH_MONITOR=1515723731.0") in new stack
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [s@macro-user-callerid:2] Set("PJSIP/3000-00000000", "AMPUSER=3000") in new stack
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [s@macro-user-callerid:3] GotoIf("PJSIP/3000-00000000", "0?report") in new stack
[2018-01-11 21:22:11] VERBOSE[16526][C-00000000] pbx.c: Executing [s@macro-user-callerid:4] ExecIf("PJSIP/3000-00000000", "1?Set(REALCALLERIDNUM=3000)") in new stack
Also I just want the jitter buffer regardless of from-internal or from-external and couldn’t find much on context in asterisk documentation wise… Its currently added like this to test in extensions_custom.conf
; PJSIP Jitter Buffer
[from-internal]
exten => 6000,1,Set(JITTERBUFFER(fixed)=2000)
[from-external]
exten => 6000,1,Set(JITTERBUFFER(fixed)=2000)
I doubt whether your users will be happy with a 2000 ms jitter buffer 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Function_JITTERBUFFER
What are you trying to achieve with “from-external”
I realize that but just wanted to test if it even works, still don’t think that it is as there is no delay in the call. Just hoping for the best possible call quality on a Note 8 when connected to WiFi for both incoming and outgoing calls.
This is literally the only thread on the Internet that deals with FreePBX, PJSIP, and jitter buffers, and I feel like this XKCD comic right now. 
I have one endpoint that is on a connection with bad jitter and no way to fix it short of scrapping the extension and putting in a landline. I’d like to try a jitter buffer, but I’m using PJSIP. Whether it’s a jitter buffer on that single extension or an adaptive jitter buffer on all extensions (assuming that the “adaptive” part means that low-jitter connections won’t be horrifically affected) doesn’t really matter, I guess, but I’m stumped at how to implement this.
I have little experience writing Asterisk dialplans and have only added things to extensions_custom.conf and whatever as a result of hours and hours of Googling to find very specific instructions in a tutorial followed by a ton of trial that ends up mostly in error.
I’m not a complete Asterisk/FreePBX neophyte (though I recognize I sound like one here), but can someone post some hints or walk me through relatively step-by-step with which file(s) to modify (pjsip.endpoint_custom_post.conf, extensions_custom.conf, etc.) and what to put in for whichever is the simplest way (edit a single extension to use the jitterbuffer or add it to the normal context for all extensions)?
I see dicko’s suggestion to add a context, which I assume goes into extensions_custom.conf, but then how do I “activate” that context for either the extension in question or the full system/dialplan? And is just the one line referenced in cw89’s post(s) acceptable, or do I somehow need to Goto the regular context to complete the remainder of the dialplan?
Many thanks in advance for even the tiniest assistance.
(Asterisk 13.13, FPBX 12.0.74)
This sounds suspicious. What is the actual problem with the line? There are lots of theoretical fixes that can solve problems like this without resorting to something as onerous as a 2-second delay between you speaking and your callee hearing what you say. That (having to say “over” at the end of my part of the conversation) most assuredly would drive me nuttier than having jitter.
I know you think a jitter buffer might help you, but it would really help us if you could explain what the actual no-kidding problem is. Is it a dial-up line? Is the network connection congested? Are there switching/routing issues that are slowing or duping the traffic?
I’m not saying we won’t end up at a jitter buffer solution, but that’s really a last-resort, big-hammer fix that is almost always worse than the original problem.
It’s a rural WISP connection using an unlicensed band. No way to improve the connection quality (ISP isn’t the most responsive, technically), and no other options for an Internet connection outside of cellular.
I don’t need 2 seconds (I’d test it with the Adaptive mode enabled, but if I had to put a fixed amount in, a couple hundred MS at most would likely cover almost all of the jitter). Here’s a traceroute from the Mikrotik router on premises to the PBX (TCP, as UDP traceroutes fail, but you get the idea–look at the STD-DEV column):
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 192.168.250.1 0% 100 0.2ms 0.2 0.2 0.8 0.1
2 192.168.3.1 0% 100 28.9ms 20.4 2.5 131.1 20.9
3 162.251.191.73 0% 100 6.3ms 15.3 5.5 85.8 18.4
4 162.251.190.181 0% 100 12.1ms 23.6 5.4 129.9 22
5 162.251.190.173 0% 100 12.6ms 27 11.5 232.6 28.2
6 162.251.190.145 0% 100 43.1ms 29.8 11.7 135.1 23.8
7 162.251.190.41 0% 100 24.2ms 25.1 11.6 121.9 17
8 72.29.169.121 0% 100 42.4ms 32.8 11.7 93 19.6
9 72.29.160.168 0% 100 18.4ms 27.1 11.9 98.4 16.6 <MPLS:L=307232,E=0>
10 xe-0-0-1-5013.core02.dwni.pin... 1% 100 18.3ms 35.5 17.8 160.3 24.4
11 xe-0-18-0-3-9-100.r02.snjsca0... 0% 100 18.6ms 29.9 17.8 116.4 17.2
12 ae-11.r22.snjsca04.us.bb.gin.... 7% 100 24.7ms 34.6 17 105.3 19.7 <MPLS:L=629764,E=0>
13 ae-8.r21.chcgil09.us.bb.gin.n... 0% 100 74.3ms 87 67.9 159.8 68.3 <MPLS:L=770034,E=0>
14 ae-16.r08.chcgil09.us.bb.gin.... 0% 100 97.5ms 85.3 68 147.2 67.4
15 ae-0.a02.chcgil09.us.bb.gin.n... 0% 100 73.9ms 87.8 67.6 171.6 68.4
16 xe-0-0-16-0.a02.chcgil09.us.c... 0% 100 79.8ms 86.9 68.2 172 68.5
17 te9-2.dist02.chi18.steadfast.net 0% 100 73.9ms 87.1 66.7 188.7 69.1
18 ip202.50-31-112.static.steadf... 0% 100 74ms 86.2 72.5 176.8 68.5
19 x.x.x.x.static.steadfas... 0% 100 72.5ms 102.9 72.5 576.6 116.1
I’m open to other suggestions (I haven’t tried G.729 yet, FWIW), but on-topic for this thread, it would still be nice to know how to turn the jitter buffer on even if only for testing purposes.
Try IBLC if your provider supports it.
perhaps
rtp set debug on
examine the log , there are timestamps and sequences and packet lengths in there , seq(uences) out of order are “jitter”, delays between “from” and “to” are network latency issues , and len not equal to 160 is fragmentation.
Both the OBi202 and my Asterisk/FPBX support iLBC although it’s disabled on the OBi by default, so I’m working on figuring out how to enable that in my OBi’s XML config file now (it’s not intuitive) and will test it soon.
rtp debug results (162.251.191.74 is the endpoint in question; the other IP is presumably the Flowroute media endpoint for this call):
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021566, ts 1812093587, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032023, ts 1812093424, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032024, ts 1812093584, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063080, ts 1817673249, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020716, ts 1817671968, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021567, ts 1812093747, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032025, ts 1812093744, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063081, ts 1817673409, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020717, ts 1817672128, len 000170)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063082, ts 1817673569, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020718, ts 1817672288, len 000170)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063083, ts 1817673729, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020719, ts 1817672448, len 000170)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063084, ts 1817673889, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020720, ts 1817672608, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021568, ts 1812093907, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021569, ts 1812094067, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021570, ts 1812094227, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021571, ts 1812094387, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032026, ts 1812093904, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032027, ts 1812094064, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032028, ts 1812094224, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032029, ts 1812094384, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063085, ts 1817674049, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020721, ts 1817672768, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021572, ts 1812094547, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032030, ts 1812094544, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063086, ts 1817674209, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020722, ts 1817672928, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021573, ts 1812094707, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021574, ts 1812094867, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021575, ts 1812095027, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021576, ts 1812095187, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021577, ts 1812095347, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032031, ts 1812094704, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032032, ts 1812094864, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032033, ts 1812095024, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032034, ts 1812095184, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032035, ts 1812095344, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063087, ts 1817674369, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063088, ts 1817674529, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063089, ts 1817674689, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063090, ts 1817674849, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063091, ts 1817675009, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063092, ts 1817675169, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020723, ts 1817673088, len 000170)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020724, ts 1817673248, len 000170)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020725, ts 1817673408, len 000170)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020726, ts 1817673568, len 000170)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020727, ts 1817673728, len 000170)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020728, ts 1817673888, len 000170)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020729, ts 1817674048, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021578, ts 1812095507, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032036, ts 1812095504, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021579, ts 1812095667, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032037, ts 1812095664, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063093, ts 1817675329, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021580, ts 1812095827, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032038, ts 1812095824, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063094, ts 1817675489, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020730, ts 1817674208, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021581, ts 1812095987, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032039, ts 1812095984, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063095, ts 1817675649, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020731, ts 1817674368, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021582, ts 1812096147, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032040, ts 1812096144, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063096, ts 1817675809, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020732, ts 1817674528, len 000170)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063097, ts 1817675969, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020733, ts 1817674688, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021583, ts 1812096307, len 000160)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021584, ts 1812096467, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032041, ts 1812096304, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032042, ts 1812096464, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063098, ts 1817676129, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020734, ts 1817674848, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021585, ts 1812096627, len 000160)
Sent RTP packet to 74.120.93.196:25516 (type 00, seq 032043, ts 1812096624, len 000160)
Got RTP packet from 74.120.93.196:25516 (type 00, seq 063099, ts 1817676289, len 000160)
Sent RTP packet to 162.251.191.74:37887 (type 00, seq 020735, ts 1817675008, len 000170)
Got RTP packet from 162.251.191.74:37887 (type 00, seq 021586, ts 1812096787, len 000160)
Thanks again for the help, especially as it’s OT for this thread!
Now you just have to look at both legs
grep -v 74.120.93.1
and
grep 74.120.93.1
You will notice that you are sending oversize packets (170) to surfnet
It looks like a jitter buffer won’t help, the packets arrive in sequence but the latency on this very short snip are as much as a second. There is little you can do to improve that further to making sure you have your QOS set and working optimized.
QOS is sadly not possible, as it is not a fixed-speed link. It’s a 5m/5m connection but it constantly fluctuates from 4-6m depending on whatever (the tower’s network load, the phase of the moon, the WISP’s mood at the moment, etc.), and the latency is all over the place even on a completely idle connection (as was the case during this test), so I don’t think QOS will help.
I did see the oversize packets; what’s the cause of that and is there any way to adjust that?
Even if you’re 100% sure it won’t solve anything, I would still like to test out a jitter buffer if anyone is willing to help me understand how to do it, as I mentioned a few posts ago.
FWIW, the user on the OBi in question has no issues hearing audio on their end (what I presumed to be due to the OBi’s built-in jitter buffer). It’s only audio from the OBi to the PBX (and onward) that experiences constant drop-outs, making understanding them difficult.
If this is the same Surfnet as the one in SLO, then I notice they have levels of service both residential and business, perhaps they prioritize the business offerings better, you should perhaps check.
Yes, it is the one in SLO (and the user is in far eastern rural Paso Robles). For the price difference between the residential and business offerings, they could have 12 landlines (11 more lines than we need). And frankly, I don’t trust Surfnet to do much better with the business network: this happens day or night, even 3am when virtually every last one of the other Surfnet users in the county is sleeping and the entire countywide network should be close to idle. With Surfnet, the price is reasonable, but their technical support is pretty bad (and so I don’t trust they’ve engineered their biz offerings any better), but at least it’s functional Internet for a rural area.
BTW, I tried iLBC…not much better (and in fact, a slightly muddier sound–worse than I was expecting given the close MOS of g711 and iLBC).
FWIW, I’ve attached an interesting status report from the OBi during my test call. The OBi is definitely using its internal jitter buffer, and the user reported that I sounded clear on the test call (while I could hear many drop-outs). I still think they’re related.
Would you be willing to humor me and help me try a jitter buffer, just for the heck of it?
