[asterisk-bugs] [JIRA] (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

[Alexander Traud (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227953#comment-227953 ] 

Alexander Traud commented on ASTERISK-21492:
--------------------------------------------

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?

> RTP packetization negotiated at ptime=30 for first leg; ptime=20 for second leg results in deltas of 20/40ms and 30/0ms
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21492
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21492
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Resources/res_rtp_asterisk
>    Affects Versions: 1.8.21.0, 11.20.0, 13.6.0
>            Reporter: i2045
>            Assignee: i2045
>         Attachments: 1_8_21_0_packetization_extensions.conf, 1_8_21_0_packetization.pcap, 1_8_21_0_packetization_rtp.conf, 1_8_21_0_packetization_sip.conf, 1_8_21_0_packetization.txt
>
>
> 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?



--
This message was sent by Atlassian JIRA
(v6.2#6252)