[asterisk-bugs] [JIRA] (ASTERISK-29295) chan_pjsip: Does not respect SRCUPDATE and SRCCHANGE control frames

Joshua C. Colp (JIRA) noreply at issues.asterisk.org
Tue Feb 16 04:26:17 CST 2021


     [ https://issues.asterisk.org/jira/browse/ASTERISK-29295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp updated ASTERISK-29295:
--------------------------------------

    Summary: chan_pjsip: Does not respect SRCUPDATE and SRCCHANGE control frames  (was: Asterisk doesn't set the RTP marker bit when source changes in some cases)

> chan_pjsip: Does not respect SRCUPDATE and SRCCHANGE control frames
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-29295
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29295
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 18.0.0
>            Reporter: nbougues
>         Attachments: log_asterisk_rtp_marker_absent.log.gz
>
>
> Under some circumstances, after switching the remote call in.a bridge, the outbound RTP stream changes its timestamp without setting the marker bit, thus causing issues on some remote systems that are confused by the apparent timing gap.
> This happens because the incoming streams switch from one to another, and the timestamp forwarded changes from the one in the older stream to the one in the newer stream.
> The problem is easily reproductible in our setup, and seems to be constant across Asterisk version (tester to Asterisk 18).
> See attached full debug log (which includes a minor patch to display RTP fields details in debug output).
> Issue can be seen with RTP stream SSRC 5e4757f0 which goes from seq number 239414 with ts 56800 to seq number 23915 with ts 2682843120 (and not mark bit set on 23915).



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



More information about the asterisk-bugs mailing list