[asterisk-bugs] [JIRA] (ASTERISK-28162) [patch] need to reset DTMF last sequence number and timestamp on RTP renegotiation
Alexei Gradinari (JIRA)
noreply at issues.asterisk.org
Wed Dec 19 15:47:47 CST 2018
[ https://issues.asterisk.org/jira/browse/ASTERISK-28162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexei Gradinari updated ASTERISK-28162:
----------------------------------------
Description:
The remote side may start a new stream when renegotiating RTP.
Need to reset the DTMF last sequence number and the timestamp
of the last END packet on RTP renegotiation.
If the new time stamp is lower then the timestamp of the last DTMF END packet the asterisk drops all DTMF frames as out of order.
This bug was caught using Cisco ip-phone SPA5XX and codec g722.
On SIP session update the SPA50X resets stream and a new timestamp is twice smaller then the previous.
was:
The marker bit set on the voice packet indicates the start
of a new stream and a new time stamp.
Need to reset the DTMF last sequence number and the timestamp of the last END packet.
If the new time stamp is lower then the timestamp of the last DTMF END packet the asterisk drops all DTMF frames as out of order.
This bug was caught using Cisco ip-phone SPA50X and codec g722.
On SIP session update the SPA50X resets stream indicating it with market bit and a new timestamp is twice smaller then the previous.
> [patch] need to reset DTMF last sequence number and timestamp on RTP renegotiation
> ----------------------------------------------------------------------------------
>
> Key: ASTERISK-28162
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28162
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_rtp_asterisk
> Affects Versions: 13.24.0, 16.1.0
> Reporter: Alexei Gradinari
> Assignee: Alexei Gradinari
>
> The remote side may start a new stream when renegotiating RTP.
> Need to reset the DTMF last sequence number and the timestamp
> of the last END packet on RTP renegotiation.
> If the new time stamp is lower then the timestamp of the last DTMF END packet the asterisk drops all DTMF frames as out of order.
> This bug was caught using Cisco ip-phone SPA5XX and codec g722.
> On SIP session update the SPA50X resets stream and a new timestamp is twice smaller then the previous.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list