Hello!
Asterisk version 18.16.
TS = RTP Timestamp,
SN = RTP Sequence Number
We have such scenario:
We generate ARI command to Asterisk to call to Extension, play prompt, then call to External number. Somekind of click-to-call.
Shortly scenario looks like (two legs):
ARI → Asterisk – Extension → Kamailio → UDP softphone
Asterisk – External number → Kamailio → Vendor
First leg:
ARI → Asterisk – Extension → Kamailio → UDP softphone
RTP from Asterisk to RTPEngine and then to user:
Asterisk is playing prompt, ends with TS: — TS = 17347, SN = 24558 —> RTPEngine —> UDP Softphone
Then Asterisk does second call to DID:
Asterisk – External number → Kamailio → Vendor
DID answered, starts “Welcome prompt”. RTP from RTPEngine to Asterisk:
Asterisk <— TS = 160 — RTPEngine <— Vendor
At first leg:
Asterisk sends RTP from External number to RTPEngine — TS = 160, SN = 24559 → RTPEngine → UDP Softphone
And UDP softphone receives RTP stream:
Asterisk prompt, that ends with RTP Timestamp = 17347
After that it receives RTP that starts with Timestamp = 160
Then user heard silence until RTP Timestamp reaches 17600, so first part of “Welcome prompt” disappeared, user heard second part.
This how it looks like on Wireshark (upper numbers - the number of packets):
What it’s expected to be:
Asterisk receives RTP from the second leg with TS = 160, re-writes it to 17348, as Asterisk does with RTP Sequence Number.
Does somebody have the same on Asterisk 18 version?
Thanks in advance!
There is a terminology problem here in that the I in DID stands for Incoming, and DID is therefore only a meaningful concept for incoming calls.
There at least was an issue that Asterisk used not to reflect changes of source in the SSRC field, and relied on misusing the marker bit to indicate a possible discontinuity. I’m not sure if that is still the case, so can you say whether the SSRC is changing at the same time as the timestamp discontinuity?
Thank you. Updated the post, changed “DID” to “External number”.
About SSRC:
No, it is the same in the packet 4606 (with TS = 17347), packet 7202 (with TS = 160), and packet 11890 (with TS = 17600).
Hello! I found in the similar thread your advised to update Asterisk to new version.
I tried with Asterisk 20.2.1, then rollback to 17.3.0 (my previous Asterisk version, before 18.16). The result is the same as with 18.16. version.
Also I tried with parameter “strictrtp” “yes” and “no”. Didn’t help.
I enabled debug log, and found this:
res_rtp_asterisk.c: 0x7f95d4212b70 – Strict RTP switching to RTP target address 10.199.240.154:37192 as source
res_rtp_asterisk.c: Got RTP packet from 10.199.240.154:37192 (type 00, seq 001848, ts 000160, len 000160)
res_rtp_asterisk.c: Sent RTP packet to 10.199.240.154:37166 (type 00, seq 020526, ts 000160, len 000160)
Where 10.199.240.154 - RTPEngine instance
10.199.240.154:37192 - IP:port from the second leg,
10.199.240.154:37166 - IP:port from the first leg of a call.
So, Asterisk received RTP with Timestamp = 160, and send it to the first leg without changing (it should check previous RTP packet TS, and increase TS for the new one).
Is there any possibility to mark RTP packets on Asterisk (to mark the end of “silence”)?
The another idea is to send re-Invite at the moment when the second “leg”/channel is answered. But I din’t find such possibility in Asterisk . I can send re-Invite at the channel where the call is now (using Dial “U” option), like this:
app.dial("PJSIP/PSTN_NUMBER@PSTN_TRUNK,nil,"U(c2cPstnAnswered)")
.....
local function c2cPstnAnswered( context, extension )
if dputils.isPJSIP() then
channel.PJSIP_SEND_SESSION_REFRESH():set("invite")
end
app.Return()
end
