[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=227346#comment-227346 ] 

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

Unfortunately changing {{pred}} to unsigned int didn't solve the issue (but I still think it should be unsigned, because rtp->lastts is unsigned, too). I inserted some more debug messages there, and it seems that the real problem is that {{ast_tvzero(frame->delivery)}} is false, so the skew check is not reached. Attaching a patch I made for debugging and the debug output when ast_rtp_raw_write should set the marker bit, but it did not.

The debug output:
{noformat}
[2015-08-24 15:20:32.405624] DEBUG[11560][C-00000a66] audiohook.c: Write factory 0x7fe5611af068 was pretty quick last time, waiting for them.
[2015-08-24 15:20:32.405654] DEBUG[11636][C-00000a66] res_rtp_asterisk.c: lassts: 1935205808, ms: 1700, diff: 13440, rate: 8, pred: 1935192368
[2015-08-24 15:20:32.405665] DEBUG[11636][C-00000a66] res_rtp_asterisk.c: ast_tvzero(frame->delivery) is false

{noformat}

> 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: 11.18.0, 13.3.2, 13.4.0
>         Environment: Fedora 22
>            Reporter: Gergely Dömsödi
>            Assignee: Unassigned
>         Attachments: calls.pcap, in.pcap, messages.txt, 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)