RTP stream timestamp/SSRC issue after blind transfer on chan\_pjsip (Asterisk 22.4.1)

Asterisk Asterisk SIP
1

Environment

  • Asterisk PBX 22.4.1 (Docker, clean install)
  • Also tested on Asterisk 16.x and Asterisk 18.x with the same results
  • Only PJSIP used (chan_sip not loaded)
  • Problem occurs in a typical trunk scenario: inbound SIP trunk call, answered by local extension, then blind-transferred (REFER) to another local extension.

Problem Description

During a blind transfer, Asterisk (chan_pjsip) incorrectly handles RTP stream continuity. After the transfer completes, the outgoing RTP stream suddenly changes the RTP timestamp but keeps the same SSRC. No marker bit is set on the first RTP packet after the timestamp jump.

This behavior likely violates RFC 3550 (§8.1), which requires either the SSRC to change, or the timestamp to remain continuous for the same SSRC.

Practical effect:

On the remote SBC, this unexpected RTP timestamp jump is detected as an error and, as a result, the SBC stops sending RTP packets entirely for the call.

Example RTP flow (from RTP analysis screenshot):

Before transfer:
PT=ITU-T G.711 PCMA, SSRC=0x633E050E, Seq=11946, Time=120800

Immediately after transfer (no SSRC change, timestamp jumps):
PT=ITU-T G.711 PCMA, SSRC=0x633E050E, Seq=11947, Time=1082141016

Expected Behavior

According to RFC 3550 §8.1:

  • If a significant RTP discontinuity occurs (e.g., after transfer), a new SSRC should be used.
  • If SSRC stays the same, RTP timestamp should be continuous.
  • A marker bit SHOULD be set on the first packet after a discontinuity, but this does not compensate for a timestamp jump with an unchanged SSRC.

Comparison with chan_sip

  • This issue occurs every time with chan_pjsip.
  • When using chan_sip, the behavior is correct and compliant with RFC 3550:
    After transfer, a new SSRC is used for the new RTP stream, so the SBC accepts the stream and media flow continues as expected.

Steps Tried

  • rtp_symmetric = false/true — no effect
  • Various PJSIP endpoint/global options — no effect
  • Problem is always reproducible

Relevant PJSIP configuration

Global PJSIP settings:

all_codecs_on_empty_reinvite               : false
accept_multiple_sdp_answers                : false
direct_media                               : false
rtp_engine                                 : asterisk
rtp_symmetric                              : true
media_encryption                           : no

Trunk endpoint (pjsip.conf):

[trunk-endpoint]
type=endpoint
context=trunk_context_1
allow=alaw
direct_media=no
rtp_symmetric=yes
rtp_engine=asterisk
media_encryption=no
rtcp_mux=no
rtp_timeout=60
force_rport=yes
100rel=yes
allow_transfer=yes
...

Request

Is this a known bug or limitation in chan_pjsip?
Is there a way (option, patch, workaround) to force SSRC change, ensure timestamp continuity, or otherwise handle the RTP stream reset correctly during blind transfer?

If not, can this be treated as a bug or feature request?

Related Issues

I have found a very similar (possibly identical) open issue:
Asterisk GitHub Issue #927: RTP timestamp/SSRC continuity bug after transfer
My scenario and RTP analysis match the behavior described there, including the unexpected RTP timestamp jump without SSRC change after a blind transfer, causing interoperability problems with SBCs.

Thank you for any advice!

2

It appears you’ve answered your own questions, in that an issue already exists. If you’re affected by it then you can comment on the issue. If someone had a quick fix it probably would be mentioned there.

3

Thanks.
Just to update the thread: we have now resolved the issue by modifying the code as discussed, and have prepared a pull request with the proposed fix:

Hopefully this will help others facing the same issue.