[asterisk-bugs] [JIRA] (ASTERISK-25332) marker bit lost in outgoing stream when incoming stream has vad

[Gergely Dömsödi (JIRA)]

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

Gergely Dömsödi commented on ASTERISK-25332:
--------------------------------------------

Investigating a bit further, it is interesting that in the second pcap ([^calls.pcap]) I attached, there are times when the marker bit is set after silence, and there are cases when it is not. In {{res_rtp_asterisk.c}} there is a debug line which shows "Difference is..." when timestamp skew is is larger than 640 ms, and if it is 1640ms (at 14:04:54.110099) it is in the logs, and the marker bit is set properly, but when is more, about ~16000ms (at 14:05:52.695958) it is not in the logs, and the marker bit is not set. I also noticed that in the latter case the timestamp is over the 4 byte integer storage (it would fit only in unsigned int) and in {{ast_rtp_raw_write}} the {{pred}} variable used when calculating skew is signed int while {{rtp->lastts}} is unsigned int.

I am going to make a patch for this and try if this solves the problem.

> marker bit lost in outgoing stream when incoming stream has vad
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-25332
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25332
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.3.2
>         Environment: Fedora 22
>            Reporter: Gergely Dömsödi
>            Assignee: Unassigned
>         Attachments: calls.pcap, in.pcap, messages.call, out.pcap, pjsip.conf
>
>
> When asterisk receives an incoming call from a peer capable of VAD (rtp packets stop coming on silence, and start coming again on voice), in the outgoing leg of the call, the marker bit is not set on the first packet when the audio is restarted, so the called party is unable to play/sync audio properly.



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