BYE Reason: RELEASE_CAUSE ;cause=3 ;text="Media bearer loss" #142
Comments
|
Hi @gmaruzz Couple of observations:
|
|
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 For INVITE in packet 1, the above SDP attribute is missing that why call is successful.
|
very interesting! |
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...) |
|
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 |
|
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) they both have the same traffic 1st call is a successful call, no ipsec, no volte precondition |
|
(you may want to only look at tcpdump pcap, sngrep pcap is there just to see in clear what the UE sends) |
|
Ah..now I see the complete picture. I have three questions
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 none
Media Attribute (a): curr:qos local none After this Dedicated Bearer gets created
Media Attribute (a): curr:qos local sendrecv
Media Attribute (a): curr:qos local sendrecv But, in your case its happening as follows:
Media Attribute (a): curr:qos local none
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 |
|
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!! |
|
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 1st call BYE in 8 sec 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!! |
|
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 |
|
(in the reinvite testing, no AS is involved) |
|
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 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 do you have any hint on how/where to invoke rtpengine for the 200 reply coming from AS ? |
|
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 |
|
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!! |
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
Can you provide a pcap so that I can take a look? |
|
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");
}
+
}
}
|
|
(TODO: qos for vilte, video stream needs a second request, separate from the audio stream, for qci 2 - conversational video) |
|
Yeah, you would have to configure in open5gs WebUI for that. QCI 2, ARP 4 |
|
Are you planning to make that Application Server work open-source? |
|
I am experimenting on how to have an external AS correctly connect to the IMS core |
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
The text was updated successfully, but these errors were encountered: