RTP Address Learning And Timing Problem

Home » Asterisk Users » RTP Address Learning And Timing Problem
Asterisk Users 10 Comments

Hello,

We have a system that interoperates with an external service, so that the basic call flow is:

PSTN origination -> Asterisk A -> External service -> Asterisk B

Initially the SDP from the external service tells the two Asterisks to send RTP directly to each other. Part way through the call the external service sends re-INVITEs both Asterisks to change the address for audio to itself, but this fails to work intermittently. The problem seems to be one of timing.

If there’s no RTP between the two re-INVITEs then it works fine, and both Asterisks send future RTP to the external service as instructed.

The problem is if RTP is transmitted/received in the fraction of the second between the two re-INVITEs. If Asterisk A receives the re-INVITE first, and then receives RTP from Asterisk B (which hasn’t yet received its re-INVITE), then it re-learns the media address of Asterisk B and sends audio there instead of the new address. Asterisk B gets the second re-INVITE with the new media address, but soon re-learns the media address of Asterisk A because it’s getting RTP from it.

Note we have “canreinvite = no” in sip.conf, but I don’t think that’s relevant to the problem.

Can anyone suggest how to prevent this problem? Is it possible to turn off learning the media address per call or per peer?

Thanks for your help.

10 thoughts on - RTP Address Learning And Timing Problem

  • Hello,

    Does anyone know if one of the “strictrtp” options disables RTP learning?
    As far as I can tell from the documentation the values “no” and “seqno” are more permissive in allowing other sources rather than less, but I thought I’d check.

    Thanks.

  • Hi Joshua,

    Thanks for that. The naming is a little confusing as “no” makes it sound like it’s “not strict” – good to know though. Is it possible to set strictrtp to no for just one peer?

  • Since I haven’t gotten the email yet I’ll just reply to my own.

    The “no” option disables strict RTP protection. Learning is part of strict RTP protection, it is what determines what the source of media is and then blocks other packets. There is no ability to set it per-peer/per-endpoint.

  • Hi Joshua,

    Could you confirm if the 5 second period for learning a new audio stream is a minimum or a maximum? The unusual call flow in question results in Asterisk learning a new audio stream when we don’t want it to, and having a minimum of say 2 seconds of audio would help avoid this.

    Thank you!

  • Hi Joshua,

    Thank you for that. From the code it kind of looks like STRICT_RTP_LEARN_TIMEOUT is a minimum, not a maximum:

    if (!ast_sockaddr_isnull(&rtp->strict_rtp_address)
    && STRICT_RTP_LEARN_TIMEOUT < ast_tvdiff_ms(ast_tvnow(), rtp->rtp_source_learn.start)) {
    ast_verb(4, “%p — Strict RTP learning complete – Locking on source address
    %s\n”,

    Our call shows:

    # grep C-00024cd5 full.log | egrep ‘Strict RTP’
    [Feb 22 11:16:41] VERBOSE[29023][C-00024cd5] res_rtp_asterisk.c: >
    0x2b308c074f80 — Strict RTP learning after remote address set to:
    xx.xx.154.111:18578
    [Feb 22 11:17:00] VERBOSE[29023][C-00024cd5] res_rtp_asterisk.c: >
    0x2b315c01cbc0 — Strict RTP learning after remote address set to:
    xx.xx.0.12:16498
    [Feb 22 11:17:00] VERBOSE[28191][C-00024cd5] res_rtp_asterisk.c: >
    0x2b308c074f80 — Strict RTP switching to RTP remote address xx.xx.154.111:18578 as source
    [Feb 22 11:17:00] VERBOSE[28191][C-00024cd5] res_rtp_asterisk.c: >
    0x2b308c074f80 — Strict RTP learning complete – Locking on source address xx.xx.154.111:18578
    [Feb 22 11:17:00] VERBOSE[28194][C-00024cd5] res_rtp_asterisk.c: >
    0x2b315c01cbc0 — Strict RTP switching source address to xx.xx.114.237:16498
    [Feb 22 11:17:01] VERBOSE[28194][C-00024cd5] res_rtp_asterisk.c: >
    0x2b315c01cbc0 — Strict RTP learning complete – Locking on source address xx.xx.114.237:16498

    I’m a bit confused because the second “Strict RTP learning after remote address set” should reset the rtp_source_learn.start timestamp, and yet the
    “Strict RTP learning complete” messages are less than 5000ms after that. What could be happening?

    Thanks again.

  • I don’t know in that specific output what happened. Your best course of action is to add further logging or step through the logic with all of the knowledge you have of the RTP streams to understand what is happening.