RTPengine no audio during multiple seconds after pre-answer music

[Franck James]

Hello,

We have a specific call flow on which we have no audio during multiple seconds after playing pre-answer music from a SBC. I'm attaching SIP flows.

After this pre-answer played on SBC, call is forwarded to a SIP phone user, and we have no audio during multiple seconds.

When the SBC, replies the 200OK with SDP it indicates the PRIV IP of the sip user behind :

Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: o=- 1644433832 1644433832 IN IP4 192.168.22.240
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: s=-
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: c=IN IP4 192.168.22.241
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: t=0 0
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: m=audio 40000 RTP/AVP 8 101
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: a=rtpmap:8 PCMA/8000
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: a=rtpmap:101 telephone-event/8000
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: a=fmtp:101 0-15
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: a=rtcp:40001
Feb 9 20:24:10 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: a=ptime:20

We have no sound, until the rtpengine receives the following : 
Feb 9 20:24:21 fr-rtpengine-misc-lab-vma-1 rtpengine[863]: INFO: [SD169ac02-a5c983d9270d9ce4e26263b85cdc20ce-v300g00040 port 20104]: [core] Confirmed peer address as public_ip_of_user

We found a way to solve, the issue, when we disable 3pcc on the Freeswitch located between B-SBC and Kamailio, then the Freeswitch blocks the RE-INVITE WITHOUT SDP that sends the B-SBC and audio is working fine.

Another information, we didn't have this issue when we used rtpengine mr10.0.0. Now we upgraded to version 10.4.0.

Do you have any idea about our issue ?

Thanks a lot for your help.

[Richard Fuchs]

Hard to say without more detailed logs, but it sounds like the user is behind NAT and indicates their private IP in the SDP, and so can start receiving RTP only once it has sent some RTP on their own, from which rtpengine can learn the correct address? I'm not sure how this would have ever worked in a previous version, or why blocking a re-invite without SDP would make a difference. There's probably some other RTP flow OR some other SDP signalling going on that you're not aware of (or haven't mentioned), that lets rtpengine learn the correct endpoint address.

Cheers

[Franck James]

Hello,

thanks for your feedback.

I attach a full trace of a call log in rtpengine.

We made a pcap of this call and we can't see any other RTP flows than those indicated earlier.

Do you see something strange in call log by chance ?

Thanks a lot for your help.

Best regards,

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/711edbc4-9817-fc06-4be4-78f3637c61a7%40sipwise.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Fuchs]

The log unfortunately doesn't include the SDP bodies, so there's some guesswork needed.

The RTP flow after the initial invite can be seen here:

300g00040 port 20212]: [core] Handling packet: remote sbc_peering:27376 (expected: sbc_peering:27376) -> local ip_pub_rtpengine:20212 (RTP seq 47958 TS 3148973649 SSRC bbba7667)
300g00040 port 20192]: [core] Forward to sink endpoint: local ip_pub_rtpengine:20192 -> remote ip_pub_sbc:40000 (RTP seq 47958 TS 3148973649 SSRC bbba7667)

and

300g00040 port 20192]: [core] Handling packet: remote ip_pub_sbc:40000 (expected: ip_pub_sbc:40000) -> local ip_pub_rtpengine:20192 (RTP seq 518 TS 961 SSRC 3052dd96)
300g00040 port 20212]: [core] Forward to sink endpoint: local ip_pub_rtpengine:20212 -> remote sbc_peering:27376 (RTP seq 518 TS 961 SSRC 3052dd96)

So this looks like proper bidirectional media flow.

After the re-invite, this then changes to:

300g00040 port 20226]: [core] Handling packet: remote sbc_peering:27376 (expected: sbc_peering:27376) -> local ip_pub_rtpengine:20226 (RTP seq 48417 TS 3149046969 SSRC bbba7667)
300g00040 port 20192]: [core] Forward to sink endpoint: local ip_pub_rtpengine:20192 -> remote 192.168.1.24:4008 (RTP seq 48417 TS 3149046969 SSRC bbba7667)

300g00040 port 20192]: [core] Handling packet: remote ip_pub_nat:64424 (expected: 192.168.1.24:4008) -> local ip_pub_rtpengine:20192 (RTP seq 2155 TS 10720 SSRC 5f344ebf)
300g00040 port 20226]: [core] Forward to sink endpoint: local ip_pub_rtpengine:20226 -> remote sbc_peering:27376 (RTP seq 2155 TS 10720 SSRC 5f344ebf)

which is asymmetric until the correct address is learned after a few seconds:

300g00040 port 20192]: [core] Handling packet: remote ip_pub_nat:64424 (expected: 192.168.1.24:4008) -> local ip_pub_rtpengine:20192 (RTP seq 2301 TS 34080 SSRC 5f344ebf)
00g00040 port 20192]: [core] Confirmed peer address as ip_pub_nat:64424
300g00040 port 20192]: [core] Peer address changed from 192.168.1.24:4008 to ip_pub_nat:64424

300g00040 port 20226]: [core] Handling packet: remote sbc_peering:27376 (expected: sbc_peering:27376) -> local ip_pub_rtpengine:20226 (RTP seq 48564 TS 3149070489 SSRC bbba7667)
00g00040 port 20226]: [core] Confirmed peer address as sbc_peering:27376
300g00040 port 20192]: [core] Forward to sink endpoint: local ip_pub_rtpengine:20192 -> remote ip_pub_nat:64424 (RTP seq 48564 TS 3149070489 SSRC bbba7667)

Is this what you're referring to?

To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/CABwsnswH8n8aA4fiJS5Q3eo4-NFpYvMr8vgwj10YurR2T%2Bi_cg%40mail.gmail.com.

[Franck James]

Hello!

Indeed the faulty part is the time you see asymetric flows.

At this time no RTP passing.

If you need SDP bodies how could we inclure this part of debug ?

I can send you the full pcap of this call if needed.

Thanks a lot.

Best regards 

To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/cd0c78d8-720c-a6f6-57c6-ebff06944d0b%40sipwise.com.

[Richard Fuchs]

On 24/02/2022 10.01, [EXT] Franck James wrote:
> Hello!
>
> Indeed the faulty part is the time you see asymetric flows.
> At this time no RTP passing.
> If you need SDP bodies how could we inclure this part of debug ?
> I can send you the full pcap of this call if needed.

Ok, but I'm not sure how this would be different between 10.0.x and
10.4.x as I don't really see any change in the code in this regard. Even
9.5 seems identical.

What happens is that the re-invite changes the address advertised by the
client (from one private address to another I guess), which indicates a
new RTP endpoint, and so when rtpengine receives packets from the same
source address as before, it ignores them for address learning purposes
for a few seconds, as it's likely that these packets were still sent by
the original RTP endpoint (from before the re-invite) which would be the
wrong one to send the reverse RTP flow to. Instead it's waiting to
receive packets from a new source address (as indicated by a new address
in the SDP) and would use these for address learning purposes
immediately, if there were any.

So this is actually a feature. I'm not sure what could be changed here
without breaking other use cases that rely on this behaviour.

Cheers

[Franck James]

Hello,
I'm back regarding the topic of different versions.
I can downgrade my version to 9.5 and extract new logs and compare this difference. Could this help ? 

Because the only difference between working and not working situations is the version of rtpengine.

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/e3300822-6a9c-2b70-0bcf-a09030036275%40sipwise.com.

[Franck James]

Hello,

We kept looking into this issue, and we were able to locate part of code that is the source of our problem.

This part of source code was introduced in 9.4 and don't know which use case it solved.

But when removing this part, now all our traces are good, and we don't see any latency.

Is there any way to improve this part of code or block this kind of media flows on kamailio side during wait time ?

Thanks a lot for your help.

[Richard Fuchs]

On 08/03/2022 11.14, [EXT] Franck James wrote:

Hello,

We kept looking into this issue, and we were able to locate part of code that is the source of our problem.

This part of source code was introduced in 9.4 and don't know which use case it solved.

But when removing this part, now all our traces are good, and we don't see any latency.

Is there any way to improve this part of code or block this kind of media flows on kamailio side during wait time ?

This is exactly the code responsible for the feature I explained in my last email:

What happens is that the re-invite changes the address advertised by the client (from one private address to another I guess), which indicates a new RTP endpoint, and so when rtpengine receives packets from the same source address as before, it ignores them for address learning purposes for a few seconds, as it's likely that these packets were still sent by the original RTP endpoint (from before the re-invite) which would be the wrong one to send the reverse RTP flow to. Instead it's waiting to receive packets from a new source address (as indicated by a new address in the SDP) and would use these for address learning purposes immediately, if there were any.

Or in short:

1. Client X advertises A as its RTP address
2. Rtpengine receives RTP from X with source address B
   
3. Rtpengine therefore sends RTP destined for X to address B
   
4. Client X then does a re-invite, now advertises C as its RTP address
5. Immediately following the re-invite, rtpengine receives RTP from X with source address B

What should rtpengine do now? Without the code snippet in question, rtpengine would immediately assume B to be the correct address for X and forget everything about C. This would be wrong if C were actually the correct address (or perhaps some other address D that is mapped to C). This is a real world (and somewhat common) scenario where RTP flows are not immediately switched on or off (or switched to a new port/address) following a re-invite, or while the re-invite is still in progress. Removing this code would result in complete loss of media for X after the re-invite in this scenario.

I would argue that losing 1-2 seconds of audio in a fringe use case (why does the SDP advertise a change in address when the RTP doesn't change address?) is a better outcome than losing all audio in a more common scenario.

Cheers