[Home]

Summary:ASTERISK-21492: RTP packetization negotiated at ptime=30 for first leg; ptime=20 for second leg results in deltas of 20/40ms and 30/0ms
Reporter:i2045 (i2045)Labels:
Date Opened:2013-04-17 09:30:33Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/General Resources/res_rtp_asterisk
Versions:1.8.21.0 11.20.0 13.6.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) 1_8_21_0_packetization_extensions.conf
( 1) 1_8_21_0_packetization_rtp.conf
( 2) 1_8_21_0_packetization_sip.conf
( 3) 1_8_21_0_packetization.pcap
( 4) 1_8_21_0_packetization.txt
Description:I use the 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.

Can i make Asterisk send RTP packets each 30 ms?
Comments:By: Rusty Newton (rnewton) 2013-04-22 16:00:37.592-0500

1.8.21 Should contain the fix from ASTERISK-20650. If you are still having the issue then it may be a different issue, or maybe the fix missed a certain scenario.

We'll need the following: (please attach these to the issue as separate files and do *not* paste them inline)

* sip.conf
* rtp.conf
* PCAP with all SIP and RTP
* Asterisk log (for the same call you gathered PCAP) with VERBOSE and DEBUG set to level 5, plus SIP debug enabled in the log itself.

Be sure to sanitize your files for private information (passwords).
By: i2045 (i2045) 2013-04-23 09:59:58.688-0500

The fix does make a difference.
Before the packetization setting had no effect.
With 1.8.21 Asterisk sends out packets 20ms40ms etc if 30ms is configured. Average is 30ms but still...

I will attach all the files as soon as possible.
By: i2045 (i2045) 2013-04-24 10:53:49.473-0500

Files are attached.



The test setup:

  192.168.178.1 Endpoint (SIP client)
  192.168.178.21 Asterisk 1.8.21.0
  192.168.178.20 Endpoint (other Asterisk machine playing demo)

  I have configured the Asterisk 1.8.21.0 machine with a packetization of 20ms with 192.168.178.1 and a packetization of 30ms with 192.168.178.20.
  So i would expect Asterisk 1.8.21.0 to convert between the two legs (20ms and 30ms).



The result:

     192.168.178.1 -> 30ms30ms etc. -> 192.168.178.21 -> 30ms0ms30ms20ms0ms ??? -> 192.168.178.20

  reverse direction:

     192.168.178.20 -> 20ms20ms etc. -> 192.168.178.21 -> 20ms40ms20ms40ms etc. -> 192.168.178.1



I would expect:

     192.168.178.1 -> 30ms30ms etc. -> 192.168.178.21 -> 20ms20ms etc. -> 192.168.178.20

  reverse direction:

     192.168.178.20 -> 20ms20ms etc. -> 192.168.178.21 -> 30ms30ms etc. -> 192.168.178.1
By: Rusty Newton (rnewton) 2013-04-25 09:33:34.957-0500

We acknowledged this as a bug. It looks like a different issue than ASTERISK-20650.
By: Alexander Traud (traud) 2015-10-20 08:11:59.420-0500

Here, I see this issue as well, even in the latest Asterisk versions. Looking at your and my Wireshark output, filtered with {noformat}ip.dst == 192.168.178.1{noformat}both, the RTP timestamp is as expected and the amount of samples per RTP packet is correct. However, between each RTP packet, there is an time interval of 20ms, then 40ms, then 20ms, then 40ms and do on. That is the bug, you are about. Is my observation correct?

Because I investigated a similar issue today, I looked into this issue here as well. According to my current understanding, Asterisk does not have an internal clock for media. Instead, Asterisk uses the source media as clock generator. An example: 20ms are not enough to create 30ms, therefore Asterisk has to wait for the next RTP packet. Then, Asterisk has 40ms from which 30ms are sends immediately. Another 20ms of samples arrive just 20ms later, Asterisk takes the previous 10ms+20ms, and sends those *immediately*. Because it does not have an internal clock, this second packet is not delayed. You are asking for delaying RTP packets, right?

Therefore, this issue happens whenever the packetization is different on both legs, but not a multiple of each other. For example 20:50 would face the same issue. Or ulaw:ilbc because iLBC has a default packetization time of 30ms.

For me, this looks like an architectural design issue: There is no internal clocking in Asterisk when it comes to media. Asterisk is not able to delay an RTP packet. Currently, I am thinking about a solution but have not found one, yet. For example, {{ast_rtp_raw_write}} is only concerned about tagging the RTP timestamp correctly. This is not a real-time clock. There is no FIFO buffer on that control-flow path to delay a packet.

Should Asterisk delay an RTP packet at all? Is that the job of Asterisk?
The idea of Asterisk is to pass-through RTP data as fast as possible. The receiving call-leg needs to buffer the RTP packets anyway, because RTP packets could come later. Although it would be nice to see RTP packets coming from Asterisk every 30ms – what would be the benefit of this? Or asked differently: Which drawback is created by the current behaviour: How does it affect RTP clients?