Open gmaruzz opened 1 year ago
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 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.
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
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...)
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) 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)
(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 sendrecv
in the final response to INVITE. Technically the UE updates those parameters in the following process
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
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
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
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:
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
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 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!!
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 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 ?
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!!
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?
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) no rush on this :D
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 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
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