[Home]

Summary:ASTERISK-20650: Asterisk resets ptime value in 200 OK response
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2012-11-05 04:22:01.000-0600Date Closed:2013-02-13 14:34:46.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General Resources/res_fax
Versions:1.8.17.0 Frequency of
Occurrence		Constant
Related
Issues:
must be completed before resolvingASTERISK-21004 Open Blockers for 1.8.21.0
must be completed before resolvingASTERISK-21005 Open Blockers for 11.3.0
is duplicated byASTERISK-20835 RTP not modified when UAS responds with an OK(200) with other ptime then 20ms
Environment:Attachments:( 0) ast_config.zip
( 1) Asterisk_1_4_26_RTP_packetization.pcap
( 2) ASTERISK-20650.patch
( 3) debug_5-autoframing_yes.cap.gz
( 4) debug_5-autoframing_yes.log
( 5) tmptk_20121102_1527_g02_editcap.cap
( 6) tmptk_20121105_1155_g03_edit_filtr.cap
Description:Today I have found a problem concerning asterisk 1.8.X
I've migrated one of my servers from old version of asterisk 1.4 branch to the newest 1.8.
Everything works fine, but faxes has stopped working.
I've made some research and what I have found is that asterisk 1.8 has some problems with transcoding ptime, it simply does not do this, Astersik 1.4 was coping with this.

I've attached the cap file where one of my legs is negotiating connection with ptime 10, the other one with ptime 20.
However if you look at the payload of RTP packets it is 10 ms every where.

Comments:By: Maciej Krajewski (jamicque) 2012-11-05 05:15:51.401-0600

Here is the trace from old asterisk, where everything works as it should.
By: Matt Jordan (mjordan) 2012-11-08 10:30:53.846-0600

Can you attach your sip.conf as well?
By: Maciej Krajewski (jamicque) 2012-11-08 15:36:02.515-0600

I've attached the sip.conf file - it is static from database.
By: Matt Jordan (mjordan) 2012-11-08 16:36:39.390-0600

I don't see any RTP packetization set on any of the peers in your config, which is okay, but that does mean that the packetization will comes soley from the SIP traffic (which is probably what you want anyway).  However, by default {{autoframing}} is False and I don't see it in your config.  This probably needs to be set to True for Asterisk to properly use the ptime attributes passed in the SDP (from https://wiki.asterisk.org/wiki/display/AST/RTP+Packetization):

{quote}
In sip.conf if autoframing=yes is set in the global section, then all calls will try to set the packetization based on the remote endpoint's preferences. This behaviour depends on the endpoints ability to present the desired packetization (ptime\:) in the SDP. If the endpoint does not include a ptime attribute, the call will be established with 20ms packetization.
{quote}

Can you try setting autoframing to yes and see what happens?
By: Maciej Krajewski (jamicque) 2012-11-09 04:11:49.969-0600

After sending autoframing to yes nothing has changed - the problem still exists.
By: Matt Jordan (mjordan) 2012-11-26 09:44:19.259-0600

So, I can tell you that you definitely need the 'autoframing' flag set on the peer in question.  Without that flag, it definitely will not work, as the framing parsed out of the INVITE request will not be applied to the codec preferences.

Can you provide a DEBUG 5 log illustrating the handling of the INVITE request?  If the framing is being set correctly on the codec, you should see the following message:

{noformat}
"Setting framing for [format name] to [ptime value]"
{noformat}

If you don't see that message, then {{autoframing}} wasn't detected for that peer.

If you do see that message and the ptime still isn't accounted for, then the log should illustrate what is going on.

By: Maciej Krajewski (jamicque) 2012-11-27 04:23:59.877-0600

I've attached the requested logs
By: Matt Jordan (mjordan) 2012-11-27 10:28:03.334-0600

Thanks for the pcap and logs.

You'll note in the debug 5 logs, the Asterisk system is actually setting the ptime to 10 when told to do so:

{noformat}
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for ulaw to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for gsm to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for g723 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for adpcm to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for adpcm to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for lpc10 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for alaw to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for g722 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for slin to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for slin to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for adpcm to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for adpcm to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for g729 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for jpeg to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for h261 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for h263 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for ilbc to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for h263p to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for h264 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for siren7 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for h263p to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for mpeg4 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for red to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for t140 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for speex to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for g726 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for g726aal2 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for siren14 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for g719 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for speex16 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Setting framing for slin16 to 10
[Nov 27 08:16:50] DEBUG[8867] chan_sip.c: Processing media-level (audio) SDP a=ptime:10... OK.
{noformat}

While the DEBUG log didn't go far along enough to illustrate this, the pcap does show that the UA at 10.0.6.23:5061 responds back with a 200 OK with an SDP (see packet 13).  In that SDP, it sets the ptime back to 30.  Asterisk responds accordingly and reset the min accepted packet length to 30, and notifies 10.0.6.40 accordingly.

So, this doesn't appear to be an Asterisk bug, but a bug with the carrier.
By: Maciej Krajewski (jamicque) 2012-11-27 14:16:04.029-0600

Considering SDP header everything is clear.
Please look at the first cap and the RTP packets - Asterisk does not transcode them. But according to signalization it should.
By: Matt Jordan (mjordan) 2012-11-27 14:19:51.290-0600

If the first pcap was generated without the autoframing flag, then yes - it won't transcode them.  The autoframing flag is required for Asterisk to change the framing for the various formats.
By: Maciej Krajewski (jamicque) 2012-11-27 14:23:09.329-0600

Hi Matt, the test where mad also with autoframinng flag and it does not help - the rtp packets still has the same payload as those with shorter ptime.
By: Matt Jordan (mjordan) 2012-11-27 14:34:10.458-0600

Gotchya.  I missed who the UA was on packet 13 - for some reason, I thought it was the carrier that sent that packet.

It does appear as if the ptime field is being reset in the 200 OK.  I think this can be acknowledged now.
By: Maciej Krajewski (jamicque) 2012-11-27 14:43:09.252-0600

is there a reason it's assigned to me?
By: Matt Jordan (mjordan) 2012-11-27 14:49:20.132-0600

Not especially.  I've assigned it to Unassigned.
By: i2045 (i2045) 2013-01-24 16:17:54.964-0600

I experience problems with RTP packetization also with Asterisk 11.2.1 (see ASTERISK-20976).
To investigate when RTP packetization stopped working i installed a few older releases of 1.8 and 1.6 and 1.4 and all indicated ptime:30 with codec ulaw:30 but the RTP packets were sent each 20ms instead.
I have attached a packet capture of Asterisk 1.4.26.
Has someone got RTP packetization working with a (recent) Asterisk release?
By: Mark Michelson (mmichelson) 2013-02-05 17:15:15.656-0600

I think the renaming of this issue is not correct.

The incoming leg into Asterisk is negotiated to have a ptime of 30. The outgoing leg from Asterisk is negotiated to have a ptime of 10. On the incoming call leg, the audio from the far end comes in 30 ms segments (good). Asterisk, however, sends the RTP in 10 ms segments (bad). On the outgoing leg, Both Asterisk and the far end send their audio in 10 ms segments (good). The issue is that Asterisk, despite claiming a ptime of 30 on the incoming leg, is sending audio in 10 ms segments.

I'm going to set up some local tests and see if I can reproduce the issue and come up with a fix.
By: Mark Michelson (mmichelson) 2013-02-05 18:46:37.093-0600

I set up a scenario similar to yours. The inbound leg has ptime 30 and the outbound leg has ptime 20. I noticed that the RTP layer in Asterisk set up a smoother of the proper size, but when I look at the packet captures, it's clear that the audio is being sent in 20 ms segments in all cases.
By: Maciej Krajewski (jamicque) 2013-02-06 02:15:02.706-0600

As far as I understand, you acknowledge that this is a bug?
By: Mark Michelson (mmichelson) 2013-02-06 11:40:07.135-0600

Yes.

I have traced the problem down to local RTP bridging. When local RTP bridging is used, the smoother that is used to make packetization work properly is bypassed. Instead, the RTP packets are sent directly from the read side to the write side.

I have a quick workaround you can use until the problem is fixed with a patch. For now, you can change your usage of Dial to have an option that prevents local RTP bridging from occurring. You can either set T, t, H, h, X, x, W, w, K, or k on the Dial statements and that will prevent local RTP bridging from occurring.

The problem I have right now is that I don't know if it's possible to change local RTP bridging to use the smoother or if that will completely break local RTP bridging. The other possibility is not to allow local RTP bridging if packetization of the two streams is different.
By: Mark Michelson (mmichelson) 2013-02-06 12:35:06.110-0600

I have uploaded ASTERISK-20650.patch

This patch was created against the tip of the 1.8 branch. Please test and see if you still have the same packetization issues.
By: Mark Michelson (mmichelson) 2013-02-12 13:40:35.616-0600

The corresponding review has received a ship-it. I am going to commit the fix and close this issue. Please re-open if there are still problems.
By: Maciej Krajewski (jamicque) 2013-02-12 13:59:28.008-0600

ok thank you.
By: i2045 (i2045) 2013-04-16 06:31:40.756-0500

I use 1.8.21 with same configuration as ASTERISK-20976.

User A sends RTP each 20ms. User B has packetization set to :30.

I now see: A 20ms20ms20ms20ms20ms20ms -> Asterisk ->  20ms40ms20ms40ms -> B.

I would expect: A 20ms20ms20ms20ms20ms20ms -> Asterisk ->  30ms30ms30ms30ms -> B.

Is this correct behaviour?