BYE Reason: RELEASE_CAUSE ;cause=3 ;text="Media bearer loss"

[gmaruzz]

Hello,

I'm struggling with this one since forever...

If I use UEs that do not support precondition and sec-agree, I can have a regular call to an external Application Server (AS) defined in FHOSS, media via rtpengine

If I use UEs that wants sec-agree and precond, after 8 seconds call is hangup from UE

Note: UE receives and plays audio from AS

I tried so many variations...

Would you give me some hints? QOS seems to be correctly established by pcscf... But UE do not sends audio...

I attach a pcap with two calls, second one from a UE with no precond and secagree (works no problem), and first one from a UE with them (BYE after 8 seconds)

If you deem useful any other info or test, please let me know

[herlesupreeth]

Hi @gmaruzz

Couple of observations:

1. As seen in screenshot below, for the second call UE is sending to IPSec port of Kamailio without an ESP header
2. Usually a packet of size 2436 bytes is sent over TCP rather than UDP

[herlesupreeth]

Also, if you compare the SDP part of two INVITEs in packet 1 and packet 19 (screenshot attached). You see that phone is sending SDP with Media Attribute (a): des:qos mandatory local sendrecv explicitly saying that a dedicated bearer with QoS 1 is required.

For INVITE in packet 1, the above SDP attribute is missing that why call is successful.

[gmaruzz]

Hi @gmaruzz

Couple of observations:

1. As seen in screenshot below, for the second call UE is sending to IPSec port of Kamailio without an ESP header

2. Usually a packet of size 2436 bytes is sent over TCP rather than UDP

very interesting!
maybe this is actually the culprit, I'll try to dig into this

[gmaruzz]

Also, if you compare the SDP part of two INVITEs in packet 1 and packet 19 (screenshot attached). You see that phone is sending SDP with Media Attribute (a): des:qos mandatory local sendrecv explicitly saying that a dedicated bearer with QoS 1 is required.

For INVITE in packet 1, the above SDP attribute is missing that why call is successful.

Yep, actually this is what I was meaning when I wrote the UE wants precondition (volte precondition, QCI=1)

pcscf is correctly setting it when 183/200 is answered to this INVITE (seems to me...)

[gmaruzz]

ooooops, I attached the wrong pcap :(((

I delete the capture_2023-01-31_01_sngrep.zip

I will attach a new one in a while

[gmaruzz]

these are the correct pcaps, inside media_bearer_loss.zip:

tcpdump pcap is just a capture on the any interface in the laptop running docker (ALL traffic, as it is in real world)
sngrep pcap is made by a modified version of sngrep, the kamailios from docker they all send HEP incapsulated packets to it (SIP traffic as seen by inside the kamailios, so all is in clear even if in real world is ipsec/wss/whatever)

they both have the same traffic

1st call is a successful call, no ipsec, no volte precondition
2nd call is the failed call, require both ipsec and volte (ipsec requirements are then removed by the AS proxy, so they are not propagated to the AS platform)

media_bearer_loss.zip

[gmaruzz]

(you may want to only look at tcpdump pcap, sngrep pcap is there just to see in clear what the UE sends)

[herlesupreeth]

Ah..now I see the complete picture. I have three questions

1. What is the AS you are using?
2. Is that AS allows modification of SDP parameters?
3. Does that AS allows generation of 183 message before sending 200 OK for INVITE?

The issue here lies in AS. Since we cannot change the behavior of the UE its upto the AS to send the response for INVITE as desired by the UE.

In the INVITE below sent by UE, the SDP is mandating QoS to be met by the network. And, this is met by Dedicated Bearer Creation in packet 17357.

However, its not reflected in the SDP of 200 OK for INVITE. i.e. SDP parameter must be Media Attribute (a): curr:qos local sendrecv in the final response to INVITE. Technically the UE updates those parameters in the following process

1. UE --> AS - INVITE with SDP

Media Attribute (a): curr:qos local none
Media Attribute (a): curr:qos remote none
Media Attribute (a): des:qos mandatory local sendrecv
Media Attribute (a): des:qos optional remote sendrecv

2. AS -> UE - 183 with SDP (NOTE: I am assuming AS does not desire QoS to be met)

Media Attribute (a): curr:qos local none
Media Attribute (a): curr:qos remote none
Media Attribute (a): des:qos optional local sendrecv
Media Attribute (a): des:qos optional remote sendrecv

After this Dedicated Bearer gets created

3. UE -> AS - PRACK (no SDP here)
4. AS -> UE - 200 for PRACK (no SDP here)
5. UE -> AS - UPDATE with SDP

Media Attribute (a): curr:qos local sendrecv
Media Attribute (a): curr:qos remote none
Media Attribute (a): des:qos mandatory local sendrecv
Media Attribute (a): des:qos optional remote sendrecv

6. AS -> UE - 200 OK for UPDATE with SDP

Media Attribute (a): curr:qos local sendrecv
Media Attribute (a): curr:qos remote sendrecv
Media Attribute (a): des:qos mandatory local sendrecv
Media Attribute (a): des:qos optional remote sendrecv

But, in your case its happening as follows:

1. UE --> AS - INVITE with SDP

Media Attribute (a): curr:qos local none
Media Attribute (a): curr:qos remote none
Media Attribute (a): des:qos mandatory local sendrecv
Media Attribute (a): des:qos optional remote sendrecv

2. AS -> UE - 200 OK with SDP

Media Attribute (a): sendrecv

So UE has no way to know QoS was met or not in response to INVITE.

Therefore, I would suggest to add following (screenshot below) Media Attributes to your 200 OK response from AS

If you are using kamailio as AS, there is a handy module to modify SDP parameters - https://kamailio.org/docs/modules/5.6.x/modules/sdpops.html

[gmaruzz]

ah ok!!!!!!!

I was under the impression that, because qos was correctly established (QCI=1), then the UE has no need for telling that to her in SDP

Yep, I'll do the SDP mannipulation (AS uses OpenSIPS as proxy, so no problems)

I'll report here how it will go

Thanks a lot!!

[gmaruzz]

Hello!

I tested with SDP manipulation, but it does not succeed: it still BYE in 8 sec, media bearer loss

So, I believe is something to do with how the connection to internal rtpengine is made

I attach a new case that probably shows the specific problem:

Call initiated by UE that requires precond & ipsec, callee UE that don't
rtpengine is forced in the middle

1st call BYE in 8 sec
2nd call (same caller/callee) do immediately a hold/unhold (so, 2 re-INVITEs), and it succeed!

I tried to understand why, testing various things, but I have not understood

Could you take a look at the pcaps attached here?

Thanks a lot!!

8_sec_bye_reinvite.zip

[gmaruzz]

this last pcap, testing reinvite, was took from calls oneplus8T->oneplus5

Because I suspected maybe a bug in oneplus8T, I repeated same test between iphone8->oneplus5

With NO reinvites, oneplus5 sends a bye at 20 seconds, BYE reason: RTP timeout

With reinvites, all is working

[gmaruzz]

(in the reinvite testing, no AS is involved)

[gmaruzz]

OK, I understood at least where the problem is:

problem is my invocation of rtpengine!

I added a case so I can manage the reply coming from AS:

} else if (is_reply() && isflagset(FLT_MOBILE_ORIG)) {
                        set_dlg_profile("caller", "$fU");
                        rtpengine_manage($avp(rtpproxy_offer_flags));

this addition breaks the UE(ipsec+precond)->UE(no ipsec no precond) call (8 sec BYE), so please disregard last pcap about reinvite

this addition makes working OK the UE(no ipsec no precond) -> AS call
this addition do NOT makes working the UE(ipsec+precond)->AS call (8 sec BYE)

So, actually, I need to find the correct place and flags to invoke rtpengine for the reply coming from the AS (tryed many variations, no joy)

(eg, UE calling voicemail->INVITE->AS AS->200REPLY->UE)

my addition is working only for NO ipsec NO precond UEs
(fails on UE(secagree+precond) even with SDP manipulation putting sec-agree and precond in 200 SDP from AS)

do you have any hint on how/where to invoke rtpengine for the 200 reply coming from AS ?

[gmaruzz]

I believe I maybe understood the problem:

instead of using rtp_manage, because I actually have more complex use case, I will need to rewrite it (maybe to rewrite even all other rtpengine invocations) using rtp_offer/rtp_answer, taking care of all different use cases and networks involved

[gmaruzz]

in my addition, rtpengine is invoked on reply coming back (from AS) to the originating UE (so, mobile originated reply), after that qos/qci is requested via diameter for the to-tag/from-tag streams of the call

in original code no rtpengine is invoked in this case

my guess is:

rtpengine changes fromtag/totag/streams, but these changes are not reflected in what variables kamailio acts upon for diameter call

so, I need to have kamailio call diameter using the variables changed by rtpengine, and not the pre-rtpengine vars

I'll look into that asap, unfortunately I cannot do it until tuesday or so (I'll be at fosdem, cannot carry all equipment with me :D )

I'll update this tkt as soon as I have news

Thanks for all your work!!

[herlesupreeth]

So, actually, I need to find the correct place and flags to invoke rtpengine for the reply coming from the AS (tryed many variations, no joy)

(eg, UE calling voicemail->INVITE->AS AS->200REPLY->UE)

my addition is working only for NO ipsec NO precond UEs
(fails on UE(secagree+precond) even with SDP manipulation putting sec-agree and precond in 200 SDP from AS)

do you have any hint on how/where to invoke rtpengine for the 200 reply coming from AS ?

This was the most trickiest part of the fix I did on kamailio cfg files. Unfortunately, I could only solve the RTPEngine issue for basic calling. But, when you involve AS, then the complexity explodes :P

rtpengine changes fromtag/totag/streams, but these changes are not reflected in what variables kamailio acts upon for diameter call

Can you provide a pcap so that I can take a look?

[gmaruzz]

this seems to solve all QOS/QCI issues in IMS side (using FORCE_RTPRELAY works for both UE to UE calls, and for UE to AS calls. It checks the User-Agent in reply to know if the call is from AS so not to risk rtpengine loops in UE-UE - obviously we can find a better check, but the POC works!):

diff --git a/pcscf/route/mo.cfg b/pcscf/route/mo.cfg
index a31a031..15847b8 100644
--- a/pcscf/route/mo.cfg
+++ b/pcscf/route/mo.cfg
@@ -119,6 +119,8 @@ onreply_route[MO_reply] {
                        drop();
                }
 
+               msg_apply_changes();
+
                xlog("L_DBG","Diameter: Orig authorizing media via Rx\n");      
                $avp(FTAG_CUSTOM_AVP)=$ft;
                $avp(TTAG_CUSTOM_AVP)=$tt;
diff --git a/pcscf/route/rtp.cfg b/pcscf/route/rtp.cfg
index d2566ec..0936fb4 100644
--- a/pcscf/route/rtp.cfg
+++ b/pcscf/route/rtp.cfg
@@ -161,7 +161,14 @@ route[NATMANAGE] {
                } else if (is_reply() && !isflagset(FLT_MOBILE_ORIG)) {
                        set_dlg_profile("callee", "$tU");
                        rtpengine_manage($avp(rtpproxy_answer_flags));
+                } else if (is_reply() && isflagset(FLT_MOBILE_ORIG) && (is_present_hf("User-Agent") && ($hdr(User-Agent)=="FreeSWITCH"))   ) {
+                        set_dlg_profile("caller", "$fU");
+                        rtpengine_manage($avp(rtpproxy_offer_flags));
+                       xlog("L_ALERT","ADDED_RTPENGINE is coming from FreeSWITCH $avp(rtpproxy_offer_flags)\n");
+               } else {
+                       xlog("L_ALERT","NO_RTPENGINE\n");
                }
+
        }
 }

[gmaruzz]

(TODO: qos for vilte, video stream needs a second request, separate from the audio stream, for qci 2 - conversational video)
no rush on this :D

[herlesupreeth]

Yeah, you would have to configure in open5gs WebUI for that.

QCI 2, ARP 4

[herlesupreeth]

Are you planning to make that Application Server work open-source?

[gmaruzz]

I am experimenting on how to have an external AS correctly connect to the IMS core
Now the calls works, as a proof of concept
I want to further integrate it, and make it better
As soon as I have it "decent", yes, I want to make it open source