herlesupreeth
volte precondition
Hello,
I see that the phones who ask for volte precondition (qos) then fail the call after 8 seconds of connection.
As an example, oneplus 7t and 8t
So, it seems that open5gs (or srsran?) do not communicate to phones that resources has been allocated, and then qos volte preconditions are satisfied (des qos:local sendrecv des qos:remote sendrecv)
Seems that can also be satisfied if the bearer is QCI=1, but not sure how to force it, or how to communicate it to phones
I searched all Internet for long time, but I was unable to find info on how these preconditions can be satisfied in docker_open5gs (or similar)
do you have any hints (apart for setting the phones not to require preconditions)?
If you are using docker_open5gs (for both srsRAN and Core) then VoLTE precondition should work. But if you are using srsRAN on another machine compiled from source or installed via apt then copy the rb.conf file contents in docker_open5gs/srslte folder to add support for QCI1 bearer creation.
If you could send me a trace of the issue I may be of help.
hello, thanks for the prompt answer
I use docker_open5gs for both srsRAN and Core, and I have the correct rb.conf
I will double check if I changed anything related, then if I don't solve, I will attach a trace
Thanks again!
-giovanni
volte_precondition.zip seems to me there is no mechanism to communicate to the phone that preconditions are met by the network
this trace I attach now is between a phone that asks precondition and a phone that do not asks for it
if you want, I can attach a trace between two phones both asking for precondition
as you can see in traces, after 8 seconds the phone that asked for precond and have had them not satisfied, sends a BYE with reason "QOS"
2022/09/21 11:10:26.459072 192.168.101.2:5060 -> 172.22.0.21:5060 BYE sip:[email protected]:5060;alias=192.168.101.3~5060~2 SIP/2.0 To: <393472665612><393472665613><393472665613>
I had a quick look at the trace. From my perspective SIP signalling is correct, i.e. the other UE is clearly not advertising that precondition is supported.
I would suggest put the OnePlus phone in safe mode and take it out of safe mode and give it a try. Somehow feel the device at fault here.
Hello, thanks for the answer
Yes, as stated, the other phone do not support the precondition, and that is better: we only have to support one
As you can see, the problem is that the phone that asks for precondition ask for its one precondition mandatory (remote is optional)
It is network that is supposed to give him precondition, not the other phone
Also, if you want, I can take a trace of two phones that both asks for precondition, and the results is the same
Have you ever saw phones that asks for precondition doing complete calls of more than 8 seconds? In my experience, oneplus 5 and 6 do not asks for precon and they work. Oneplus 7 and 8 asks for precon and fails
I have done many dozen of tests (even putting phones in airplane and back)
There is some other tests or traces I can take for you?
Do you plan to add support to qos precondition?
I saw you suggested some manipulation at the proxy level, but it seems not to work :(
https://github.com/open5gs/open5gs/issues/581
do you have any hints? this problem block the usage of phones that are not very old... (btw, even Iphone 8 fails same way)
(eg, manipulation at the proxy level do not works, I have succeeded into altering the SDP bodies on the proxies, so each phone receive all preconditions - local and remote - as sendrecv, but seems to be not enough)
as per this answer, it seems that in any case, is the local network that will send "something" to phone to let him understand resources have been allocated
https://www.quora.com/In-SIP-Precondition-how-it-reserves-network-resources-before-session-establishment
The S-CSCF throughpt the proxy (P-CSCF) will “poke “ the LTE NW element PCRF which will check if UEs has subscription for those kind of GBR services. Then PCRF will foward the request to the P-GW which will perform admission control and enforce as well the establishment of the GBR into LTE domain, getting in touch with S-GW and finally with eNB, each element will perform its own admission control to allow a new GBR EPS Bearer been established. After the establishment LTE will send the feedback to IMS Core allowing the pre-conditions field changes its status from: a=curr:qos local NONE to a=curr:qos local sendrecv Both UE’s will perform its activation of EPS Dedicated RAB (GBR) and interchange its status through SIP UPDATE messages. One relevant thing about Pre-conditions. If one of the UEs can’t establish the Dedicated EPS RAB (GBR) then the call cant go further and will be rejected. Only without pre-condition the IMS network allows a VoLTE call over best effort RABs. The Pre-condition requirement is sent by the calling party over the INVITE message and the receiving party will reply if its support pre-condition on the SESSION PROGRESS MESSAGE (183). Why the receiving party also informs if its support or not pre-condition? Because in case of calling, for example to a landline, only the calling party will support pre-condition, thus the IMS network will know that B side wont have any issues with whateve RAB it will receive.
here in much more details:
https://netmanias.com/en/post/blog/11789/lte-volte/dedicated-bearer-setup-in-lte-and-impact-on-volte-precondition
I assure you that network does support preconditioning (technically IMS is transparent in the current implementation with kamailio, its upto UEs to negotiate). I have tested with OnePlus 5 (does not support preconditioning) with Xiaomi (support preconditioning) and I had successful calls for close to an hour.
If the phone says "remote is optional" it should not care about preconditioning of the called UE and should work irrespective of it.
I am attaching a call trace for your reference. Calling from Xiaomi to OnePlus 5 open5gs_xiaomi_to_oneplus_call.zip
this gives the framework view (very good!): https://realtimecommunication.wordpress.com/2016/02/02/volte-policy-control-summary/
then the case for qos: https://realtimecommunication.wordpress.com/2015/03/06/it-is-about-quality/
I assure you that network does support preconditioning (technically IMS is transparent in the current implementation with kamailio, its upto UEs to negotiate). I have tested with OnePlus 5 (does not support preconditioning) with Xiaomi (support preconditioning) and I had successful calls for close to an hour.
If the phone says "remote is optional" it should not care about preconditioning of the called UE and should work irrespective of it.
I am attaching a call trace for your reference. Calling from Xiaomi to OnePlus 5 open5gs_xiaomi_to_oneplus_call.zip
ah ok, super! then, is maybe some specific bug in openpluses ? (btw, oneplus 6 has h264 bug, vilte - video on lte- don't works, oneplus 7 and 8 works if you manage to overcome qos precondition)
If the phone says "remote is optional" it should not care about preconditioning of the called UE and should work irrespective of it.
yes, that's understood. Problem is that phone do not advance its own (local) to sendrecv, probably because do not receive the signaling it expects from network
I will attach traces between both onepluses that asks for precond, and study your xiaomi trace thanks a lot!
Hello, in your trace, if I understand correctly, your Xiaomi initially asks for precond qos, it does not receive/reach it, and it simply continues as it is not a problem. Eg, probably your Xiaomi just work around, or accept it does not get precond qos I do not see qos satisfied or even negotiated in the trace
2022/01/10 14:59:24.673283 172.22.0.21:6101 -> 172.22.0.20:6060 INVITE tel:698765432100;phone-context=ims.mnc001.mcc001.3gppnetwork.org SIP/2.0 Route:Record-Route: Record-Route: From: <598765432100><698765432100><7abf42d5-3551-458f-a574-04f721995912><598765432100> <598765432100><698765432100><192.168.101.2:5060><598765432100><698765432100>
I do not see qos satisfied or even negotiated in the trace
That is true. But its acting according to SDP in INVITE i.e. for remote the qos is optional. Eitherway, if you observe both yours and my pcap in both cases the dedicated bearer had been established (i.e. qos is maintained). Just that its not notified as part of SDP/SIP header
But its acting according to SDP in INVITE i.e. for remote the qos is optional.
yep, but if you test with another phone the same exact call to oneplus 5 (I have oneplus 5), then the call will fail because the originator do not have its own (local) qos satisfied
you can check with oneplus 7/8, or with iphone
would you like me to provide traces?
@gmaruzz I happen to face this issue myself when testing with an UE which didnt support precondition and I managed to fix this in the latest commits.