Cant Make a Call
BorjanEch0 opened this issue · 59 comments
I have managed to attach 2 samsung UE's but i cant make a call. When i press call the dial begins and ends immediately and no call is transmitted. I see a lot in logs but i cant make much of it. Here is attached logs and pcap.
Are you sure you have the latest version of Kamailio_IMS_Config? I remember providing a fix for this
i just cloned the repository again and it stayed the same
Refer this commit, 93d28fe fixes in this
I just checked the config file it is as the fixed version yet it still does not work. How can i clear all of kamailio without reinstalling the server? and start over..
Hold on a moment..I think i may have a fix for this
thank you i am waiting
Can you send me a pcap captured of the IMS components (i.e. PCSCF + ICSCF + SCSCF)?
capture of traffic between the components?
how do i set that up?
wait a second, i think you have wrong configuration of either the SIM or the Network - your UE is sending a SIP Register to a IMS with PLMN 294 19 but the SIM has IMSI with PLMN 001 01
The sim was configured with imsi and plmn 29419 and the server aswell, but i had to change the sim to 00101 to enable volte because the imaginary operator 29419 does not exits so it does not want to give me volte.
The hss is configured with correct imsi and plmn both on ogs hss and fhoss,
the only place where plmn is old is in the FQDN is that a problem?
also ogs is serving both 29419 and 00101 and the enb has also both operators set up and lte data works perfectly.
In order for IMS/VoLTE to work, all must be in the single PLMN as the setup does not handle roaming. I would suggest drop all database (fhoss + pcscf + scscf + icscf) and re-add them and configure icscf db with scscf information. Please do not change PLMN on the fly
If I remember correctly, you said you were using Sysmocom ISIM right? Then i would suggest programming PCSCF, IMS Domain, IMPI and IMPU using the following pySim repo - https://github.com/herlesupreeth/pysim
i used the following repo to program them and i can confirm sims are programmed correctly they attach and get data also i see the volte icon in the status bar.
The new plmn is 00101 the UE imsis are
001010000000010
001010000000011
the impi is 001010000000011@ims.mnc019.mcc294.deltanet.org
impu sip:001010000000011@ims.mnc019.mcc294.deltanet.org
the only place where i havent changed the plmn is in the FQDN(ims.mnc019.mcc294.deltanet.org) as i thought it would not make a problem. Everywhere else(enb,epc,hss,fhoss) the plmn is changed.
Bust here still i will re-configure the the epc,ims, and enb again and state a new fqdn with the new plmn and see what happens. then.
I am 100% sure that for PLMN 001 01 all Samsung phones work. Important thing is to maintain a single PLMN in IMS as its quite tricky to get it working and heavily depends on the FQDN (interdependent on PLMN) being used
If you are re-installing I would definitely recommend this repo - https://github.com/herlesupreeth/docker_open5gs using this you can setup everything in few commands
I will reinstall the IMS machine and the EPC machine with a fresh ubuntu, start from scratch install kamailio and ogs and configure them both with the new fqdn and plmn and i will see where that goes, this will take me some time so i will reply with how that goes later today. I will also re programm all the sim cards with new imsi plmn impi impu and domain. I usually prefer when all the components are directly installed on physical machines i am not really a fan of the container approach but i might give it a shot. Thank you for all the help. I will let you know if it is successful.
Can you send me a pcap please?
Can you change the following line in kamailio_scscf.cfg and give it a try
# Now in sip: uri format
if ($ru =~ ".*@.*") {
$ru = $(ru{re.subst,/@[0-9+-]*;user=phone/@NETWORKNAME;user=phone/g});
$ru = $(ru{re.subst,/;phone-context=[A-Za-z.0-9+-]*@/;phone-context=NETWORKNAME@/g});
} else {
$ru = $ru + "@" + NETWORKNAME + ";user=phone";
#$ru = $(ru{re.subst,/;phone-context=[A-Za-z.0-9+-]*@/;phone-context=NETWORKNAME@/g});
}
And, dont paste the logs as above as its hard to read, better to put it in zip. Also, can you take the trace on EPC + IMS machine?
i appologise i will include them in files next time,
i will change the file now but i will be at work. i can reply results this afternoon + include the capture. Should i include lo of eth1 if in capture?
I would suggest take the trace on "any" interface so that it captures all
Capture of any if
and logs in text.
Thank you and sorry for the wait.
volte.any.pcapng.zip
scscf.log
pcscf.log
icscf.log
additionally
scscf2.log
pcscf2.log
icscf2.log
volte2.any.pcapng.zip
I had a look into pcap, the UE with this IMSI 001010000000002 registered successfully, but the UE with IMSI 001010000000001 didn't, see sceenshot below. The second SIP Register after 401 Challenge is not coming inside the IPSec tunnel from UE, thats strange behavior from UE. I would recommend to reboot only that phone in safe mode and clear out all tasks there and do a normal boot
Also, do these steps only for that UE which didnt register
Try in FHoSS as mentioned in this open5gs/open5gs#462 (comment) and try to re-attach.
The second ue is showing very strange activity i will try to get a new UE, its a galaxy note 9 , when i swap sims the imsi 001 registers ok but 002 not.
also the original 001 ue is trying to reach ims.mnc001.mcc262.3gppnetwork.org which i have never seen or ever set. only that ue is trying to reach it. 262 is germany and the phones product code is for germany too. the built in ims profiles are form Telekom DE but i changed all the impi impu to my setting i cant seem to find the 262 anywhere.. let me try the steps and let you know.
volte3.zip
scscf3.txt
pcscf3.txt
still no luck... i will try a different ue and if it does still not work i will try the docker version of ogs + ims together
I had a look and this time, both of your successfully registered and you were able to get the call half way.. i will have a deeper look and let you know
Are you using srsLTE for eNB? If so can you run some ping on both UE, then register UEs to IMS and then try calling?
Thank you, i am still seeing some errors in the logs, maybe those are the problem.
I will try to ping the ues and let you know.
I am using a comercial ZTE enb macrocell.
Can you apply the following diff to kamailio_pcscf/route/mt.cfg file and give it a try?
diff --git a/pcscf/route/mt.cfg b/pcscf/route/mt.cfg
index 9e06609..f286c41 100644
--- a/pcscf/route/mt.cfg
+++ b/pcscf/route/mt.cfg
@@ -87,6 +87,15 @@ route[MT_indialog] {
xnotice("Contact header: $ct\n");
#resetflag(FLT_MOBILE_ORIG);
t_on_reply("MT_indialog_reply");
+ if ($du != "" && $ru != "") {
+ # Remove sips: and sip: from destination URI for comparision
+ $var(destination) = $(du{re.subst,/sips://g});
+ $var(destination) = $(var(destination){re.subst,/sip://g});
+ if (is_request() && $rP == "tcp" && $ru =~ ".*" + $var(destination) + ".*") {
+ #ipsec_forward("location");
+ $du = $du+";transport=tcp";
+ }
+ }
}
onreply_route[MT_indialog_reply] {
Hi sorry for the late reply on the news i was busy.
I can ping ue to ue and both ue to epc server and other way arround.
I reinstalled the server but i used ubuntu server 20.04 i faced a lot of issues but i made kamailio work and the sip call test passed, only at rtpengine i couldnt get it to compile no matter what, i used the latest release but no luck the problem is that iptables was changed to xtables and iptables dev was changed to libip6tc ilbip4tc something allong those lines which breaks the compilation.. So i will reinstall the server again now using ubuntu bionic and re configure the lab and start a test with no changes. Then i will try the fixes in this thread. I am hoping that i will work. I will try the diff last to see if it will work. I will capture traces and pcap at all stages of my test. I am really hoping it will work. I will let you know tomorrow at this time how it all went. Thank you
volte.diff.pcapng.zip
scscf.diff.log
icscf.diff.log
pcscf.diff.log
Here is a combination of trying with applied patch and the commented line in scscf sadly, i think the issue is the same.
only issue i can clearly see is this:
ue2 phone-context=ims.mnc001.mcc262.3gppnetwork.org@073000002
ue1 phone-context=073000001@073000001
and BOTH are wrong..
it should be phone-context=07300000X@ims.mnc001.mcc001.deltanet.org
or so i think..
only issue i can clearly see is this:
ue2 phone-context=ims.mnc001.mcc262.3gppnetwork.org@073000002
ue1 phone-context=073000001@073000001
and BOTH are wrong..it should be phone-context=07300000X@ims.mnc001.mcc001.deltanet.org
or so i think..
It would have been an issue but I have handled those scenario ( i think I have) in SCSCF so I dont think thats the issue. The pcap you sent is a bit messy. Can you do one more try and capture the following scenario
- Register two UEs and just place one call and then send me the pcap
In the previous pcap which you sent I see UE sending 200 ok for PRACK outside the IPSec tunnel and this 200 OK is not relayed to other UE resulting in 408 timeout
yes i see now.. here is the file requested
thanks for the traces. I had a look into the trace and I still see UE having IMSI ending with ..002 is sending the 200 OK outside of IPSec tunnel i.e. there is no ESP header
I would suggest to go to Samsung IMS settings through CoIMS, there select IMS Profiles --> Select the profile which has IMS in its name --> SIP --> transport . Here select tcp as the protocol and give it a try and send me the pcap again. Now go back and save the profile changes
volte.tcp.pcapng.zip
i switched both ue's to tcp but sadly i still see the same in wireshark... i think its the second ue problem,.. its acting strangely. I can never see the volte icon on top no matter what i do. It doesn't show up both are samsung both are same android version.
SCSCF:
3(10223) WARNING: tm [t_lookup.c:1504]: t_unref(): script writer didn't release transaction
106(10416) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
107(10420) ERROR: ims_qos [ims_qos_mod.c:935]: w_rx_aar(): No P-Called-Party hdr found in response. Using req URI from dlg - we shouldn't have to do this1
105(10410) ERROR: ims_ipsec_pcscf [cmd.c:837]: ipsec_forward(): Contact doesn't exist
SCSCF: no errors
ICSCF:
2(10509) ERROR: <script>: $ru => sip:073000001;phone-context=ims.mnc001.mcc262.3gppnetwork.org@ims.mnc001.mcc001.deltanet.org;user=phone
Here is with another samsung UE Galaxy A31S
ICSCF: No errors
PCSCF:
103(12129) ERROR: ims_ipsec_pcscf [cmd.c:190]: fill_contact(): Reply No contact headers
103(12129) ERROR: ims_ipsec_pcscf [cmd.c:830]: ipsec_forward(): Error filling in contact data
105(13180) ERROR: ims_ipsec_pcscf [cmd.c:837]: ipsec_forward(): Contact doesn't exist
Here PCSF Crashed. This is when the call was placed.
106(12132) INFO: ims_registrar_pcscf [sec_agree.c:296]: cscf_get_security_verify(): No security-verify parameters found
1(11940) NOTICE: <script>: PCSCF: ACK sip:001010000000001@192.168.101.5:6700;alias=192.168.101.5~6702~2 (tel:073000002 (10.0.20.2:6060) to sip:073000001;phone-context=073000002@073000002;user=phone, Z2_eM5xjQCdf6ajg6Olp-Q..@192.168.101.6)
85(12097) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 1
1(11940) WARNING: tm [t_lookup.c:1504]: t_unref(): script writer didn't release transaction
85(12097) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 1
94(12110) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 17
94(12110) INFO: cdp [authstatemachine.c:425]: auth_client_statefull_sm_process(): state machine: AUTH_EV_RECV_STA about to clean up
94(12110) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 17
94(12110) INFO: cdp [authstatemachine.c:425]: auth_client_statefull_sm_process(): state machine: AUTH_EV_RECV_STA about to clean up
107(12133) NOTICE: <script>: PCSCF MO_reply:
Destination URI: <null>
Request URI: <null>
107(12133) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
107(12133) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI:
107(12133) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
107(12133) NOTICE: <script>: Contact header: <null>
109(12136) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 164
0(11939) ALERT: <core> [main.c:766]: handle_sigs(): child process 12133 exited by a signal 11
0(11939) ALERT: <core> [main.c:769]: handle_sigs(): core was generated
SCSCF: No Errors
Let me explain the setup as clearly and simply as i can to help aid this problem:
There is a single server that has Kamailio + Open5Gs installed on it it has 1 ethernet interface called eno1 and it has the following setup:
IP: 10.0.20.2
Netmask: 255.0.0.0
Gateway: 10.0.0.1
It is connected to a mikrotik router/switch with ip 10.0.0.1
To it connected via SFP+is a ZTE ZXSDR B8200 BBU.
The UE is setup as follows:
UE1: Samsung Galaxy A71
SIM is programmed with the following command:
python pySim-prog.py -p0 -t sysmoISIM-SJA2 -a 68765889 -n DeltaNet -x 001 -y 01 -i 001010000000001 --msisdn=073000001 -k 465B5CE8B199B49FAA5F0A2EE238A6C7 --op E8ED289DEBA952E4283B54E88E6183CA -s 8988211000000446222 --acc 0001 --pcscf=pcscf.ims.mnc001.mcc001.deltanet.org --ims-hdomain=ims.mnc001.mcc001.deltanet.org --impi=001010000000001@ims.mnc001.mcc001.deltanet.org --impu=sip:001010000000001@ims.mnc001.mcc001.deltanet.org
UE2: Samsung galaxy Note 9 N-960F
SIM is programmed with the following command:
python pySim-prog.py -p0 -t sysmoISIM-SJA2 -a 12864246 -n DeltaNet -x 001 -y 01 -i 001010000000002 --msisdn=073000002 -k 465B5CE8B199B49FAA5F0A2EE238A6C8 --op E8ED289DEBA952E4283B54E88E6183CA -s 8988211000000446214 --acc 0001 --pcscf=pcscf.ims.mnc001.mcc001.deltanet.org --ims-hdomain=ims.mnc001.mcc001.deltanet.org --impi=001010000000002@ims.mnc001.mcc001.deltanet.org --impu=sip:001010000000002@ims.mnc001.mcc001.deltanet.org
Here are screenshots from CoIMS, i made it identical on both UE's except for IMPI IPMU:
All the other setup is per your guide.
All the patches from this thread are applied, including the latest diff and the line in kamailio_scscf.cfg.
Included is also the latest trace and pcap. I hope the error is here somewhere.
The ENB Supports VoLTE and all the needed steps are taken to make sure it is supported, if any info is needed or a thing to configure in the enb please let me know.
Also i am very thankful for your time this effort is very much appreciated.
Here PCSF Crashed. This is when the call was placed.
I gave a fix for this yesterday in kamailio source code, please take the latest commit and re-compile the kamailio. This should be fixed
Thanks a lot for detailed explanation, I see the Wifi being enabled on in all the screenshots, please disable the wifi completely before running the VoLTE experiments
Let me re compile it from source and test again. Thank you, wifi is off when i place the calls it was on when taking the screenshots but i was not running a test then,
PCSCF:
ERROR: <script>: event_route[htable:mod-init]
98(17496) ERROR: <script>: Preloading NAT-PING. Rows: 0
103(17501) ERROR: ims_ipsec_pcscf [cmd.c:872]: ipsec_forward(): Contact doesn't exist
104(17502) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
### When Call is placed:
102(17500) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
102(17500) NOTICE: <script>: Contact header: <null>
3(17307) NOTICE: <script>: PCSCF: INVITE sip:001010000000002@192.168.101.3:6200;alias=192.168.101.3~6202~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
1(17305) NOTICE: <script>: PCSCF: INVITE sip:001010000000002@192.168.101.4:6300;alias=192.168.101.4~6302~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
4(17308) NOTICE: <script>: PCSCF: INVITE sip:001010000000002@192.168.101.4:6400;alias=192.168.101.4~6402~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
2(17306) NOTICE: <script>: PCSCF: INVITE sip:001010000000002@192.168.101.4:6500;alias=192.168.101.4~6502~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
1(17305) NOTICE: <script>: PCSCF MT:
Destination URI: sip:192.168.101.4:6302;transport=tcp
Request URI: sip:001010000000002@192.168.101.4:6300
3(17307) NOTICE: <script>: PCSCF MT:
Destination URI: sip:192.168.101.3:6202;transport=tcp
Request URI: sip:001010000000002@192.168.101.3:6200
1(17305) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI: sip:term@pcscf.ims.mnc001.mcc001.deltanet.org;lr
4(17308) NOTICE: <script>: PCSCF MT:
Destination URI: sip:192.168.101.4:6402;transport=tcp
Request URI: sip:001010000000002@192.168.101.4:6400
3(17307) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI: sip:term@pcscf.ims.mnc001.mcc001.deltanet.org;lr
3(17307) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
4(17308) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI: sip:term@pcscf.ims.mnc001.mcc001.deltanet.org;lr
1(17305) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
3(17307) NOTICE: <script>: Contact header: <sip:073000001@192.168.101.2:6100;alias=192.168.101.2~6102~2>;+sip.instance="<urn:gsma:imei:35340811-675669-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;video
4(17308) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
1(17305) NOTICE: <script>: Contact header: <sip:073000001@192.168.101.2:6100;alias=192.168.101.2~6102~2>;+sip.instance="<urn:gsma:imei:35340811-675669-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;video
4(17308) NOTICE: <script>: Contact header: <sip:073000001@192.168.101.2:6100;alias=192.168.101.2~6102~2>;+sip.instance="<urn:gsma:imei:35340811-675669-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;video
2(17306) NOTICE: <script>: PCSCF MT:
Destination URI: sip:192.168.101.4:6502;transport=tcp
Request URI: sip:001010000000002@192.168.101.4:6500
2(17306) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI: sip:term@pcscf.ims.mnc001.mcc001.deltanet.org;lr
2(17306) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
2(17306) NOTICE: <script>: Contact header: <sip:073000001@192.168.101.2:6100;alias=192.168.101.2~6102~2>;+sip.instance="<urn:gsma:imei:35340811-675669-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;video
3(17307) NOTICE: <script>: PCSCF: INVITE sip:001010000000002@192.168.101.4:6100;alias=192.168.101.4~6102~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
3(17307) NOTICE: <script>: PCSCF MT:
Destination URI: sip:192.168.101.4:6102;transport=tcp
Request URI: sip:001010000000002@192.168.101.4:6100
3(17307) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI: sip:term@pcscf.ims.mnc001.mcc001.deltanet.org;lr
3(17307) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
3(17307) NOTICE: <script>: Contact header: <sip:073000001@192.168.101.2:6100;alias=192.168.101.2~6102~2>;+sip.instance="<urn:gsma:imei:35340811-675669-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;video
109(17515) ERROR: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): connect 192.168.101.4:6300 failed
103(17501) NOTICE: <script>: PCSCF MT_reply:
Destination URI: <null>
Request URI: <null>
103(17501) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
103(17501) NOTICE: <script>: Source IP and Port: (192.168.101.4:6100)
Route-URI:
103(17501) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
103(17501) NOTICE: <script>: Contact header: <null>
103(17501) NOTICE: <script>: PCSCF MT_reply:
Destination URI: <null>
Request URI: <null>
103(17501) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
103(17501) NOTICE: <script>: Source IP and Port: (192.168.101.4:6100)
Route-URI:
103(17501) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
103(17501) NOTICE: <script>: Contact header: <sip:073000002@192.168.101.4:6100>;+sip.instance="<urn:gsma:imei:35245510-420381-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting
103(17501) NOTICE: <script>: PCSCF MT_reply:
Destination URI: <null>
Request URI: <null>
103(17501) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
103(17501) NOTICE: <script>: Source IP and Port: (192.168.101.4:6100)
Route-URI:
103(17501) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
103(17501) NOTICE: <script>: Contact header: <sip:073000002@192.168.101.4:6100>;+sip.instance="<urn:gsma:imei:35245510-420381-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting
103(17501) ERROR: ims_qos [ims_qos_mod.c:935]: w_rx_aar(): No P-Called-Party hdr found in response. Using req URI from dlg - we shouldn't have to do this103(17501) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 1
94(17458) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 7
102(17500) NOTICE: <script>: PCSCF MO_reply:
Destination URI: <null>
Request URI: <null>
102(17500) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
102(17500) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI:
102(17500) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
102(17500) NOTICE: <script>: Contact header: <sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2>;+sip.instance="<urn:gsma:imei:35245510-420381-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting
102(17500) ERROR: ims_qos [ims_qos_mod.c:911]: w_rx_aar(): No P-Asserted-Identity hdr found in request. Using From hdr in req - we shouldn't have to do this102(17500) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 1
94(17458) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 7
101(17499) NOTICE: <script>: PCSCF: PRACK sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2 (tel:073000001 (192.168.101.2:6102) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
101(17499) NOTICE: <script>: Within DLG
101(17499) NOTICE: <script>: Within loose route
101(17499) NOTICE: <script>: PCSCF MO_indialog:
Destination URI: sip:mo@10.0.20.2:6060;transport=tcp;r2=on;lr=on;ftag=17d67030;did=dcf.de42
Request URI: sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2
101(17499) NOTICE: <script>: Source IP and Port: (192.168.101.2:6102)
Route-URI: sip:mo@10.0.20.2:6107;transport=tcp;r2=on;lr=on;ftag=17d67030;rm=8;did=dcf.96c1
101(17499) NOTICE: <script>: Received IP and Port: (10.0.20.2:6107)
101(17499) NOTICE: <script>: Contact header: <null>
4(17308) NOTICE: <script>: PCSCF: PRACK sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
4(17308) NOTICE: <script>: Within DLG
4(17308) NOTICE: <script>: Within loose route
4(17308) NOTICE: <script>: PCSCF MT_indialog:
Destination URI: sip:192.168.101.4:6100
Request URI: sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2
4(17308) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI: sip:mt@10.0.20.2;r2=on;lr=on;ftag=17d67030;rm=7;did=dcf.e6c1
4(17308) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
4(17308) NOTICE: <script>: Contact header: <null>
1(17305) NOTICE: <script>: PCSCF: PRACK sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
109(17515) ERROR: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): connect 192.168.101.4:6500 failed
2(17306) NOTICE: <script>: PCSCF: PRACK sip:073000002@192.168.101.4:6100;alias=192.168.101.4~6100~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
3(17307) NOTICE: <script>: PCSCF: ACK sip:001010000000002@192.168.101.3:6200;alias=192.168.101.3~6202~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
3(17307) WARNING: tm [t_lookup.c:1504]: t_unref(): script writer didn't release transaction
4(17308) NOTICE: <script>: PCSCF: ACK sip:001010000000002@192.168.101.4:6400;alias=192.168.101.4~6402~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
1(17305) NOTICE: <script>: PCSCF: ACK sip:001010000000002@192.168.101.4:6300;alias=192.168.101.4~6302~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
4(17308) WARNING: tm [t_lookup.c:1504]: t_unref(): script writer didn't release transaction
2(17306) NOTICE: <script>: PCSCF: ACK sip:001010000000002@192.168.101.4:6500;alias=192.168.101.4~6502~2 (tel:073000001 (10.0.20.2:6060) to sip:073000002;phone-context=073000001@073000001;user=phone, U9CkK3EOAquxKKRImziF5Q..@192.168.101.2)
1(17305) WARNING: tm [t_lookup.c:1504]: t_unref(): script writer didn't release transaction
2(17306) WARNING: tm [t_lookup.c:1504]: t_unref(): script writer didn't release transaction
102(17500) NOTICE: <script>: PCSCF MO_indialog_reply:
Destination URI: <null>
Request URI: <null>
102(17500) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
102(17500) NOTICE: <script>: Source IP and Port: (10.0.20.2:6060)
Route-URI:
102(17500) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
102(17500) NOTICE: <script>: Contact header: <null>
And after this the call says call ended.
After the call drops i get this
98(17496) ERROR: <script>: OPTIONS to sip:001010000000001@192.168.101.2:7000 via sip:192.168.101.2:7000;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000001@192.168.101.2:7100 via sip:192.168.101.2:7100;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000002@192.168.101.4:6400 via sip:192.168.101.4:6400;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000002@192.168.101.4:6300 via sip:192.168.101.4:6300;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000002@192.168.101.3:6200 via sip:192.168.101.3:6200;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000001@192.168.101.2:6100 via sip:192.168.101.2:6100;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000001@192.168.101.2:6900 via sip:192.168.101.2:6900;transport=tcp...
98(17496) ERROR: <script>: OPTIONS to sip:001010000000001@192.168.101.2:6800 via sip:192.168.101.2:6800;transport=tcp...
109(17515) ERROR: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): connect 192.168.101.4:6300 failed
109(17515) ERROR: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): connect 192.168.101.2:6900 failed
109(17515) ERROR: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): connect 192.168.101.2:6800 failed
108(17514) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:6100 completed with code: 200, Type 1
109(17515) ERROR: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): connect 192.168.101.2:7100 failed
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:7000 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:7000: Fail Counter is 3
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:7100 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:7100: Fail Counter is 1
85(17449) ERROR: <script>: request sent to sip:001010000000002@192.168.101.4:6400 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000002@192.168.101.4:6400: Fail Counter is 2
85(17449) ERROR: <script>: request sent to sip:001010000000002@192.168.101.4:6300 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000002@192.168.101.4:6300: Fail Counter is 5
85(17449) ERROR: <script>: request sent to sip:001010000000002@192.168.101.3:6200 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000002@192.168.101.3:6200: Fail Counter is 8
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:6900 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:6900: Fail Counter is 5
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:6800 completed with code: 408, Type 2
85(17449) ERROR: <script>: request sent to sip:001010000000001@192.168.101.2:6800: Fail Counter is 11
94(17458) INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 5
94(17458) INFO: cdp [authstatemachine.c:741]: Send_ASA(): Send_ASA(): sending ASA
94(17458) INFO: cdp [authstatemachine.c:766]: Send_ASA(): sending ASA to peer pcrf.epc.mnc001.mcc001.deltanet.org
94(17458) INFO: cdp [authstatemachine.c:773]: Send_ASA(): success sending ASA
94(17458) ERROR: cdp [routing.c:274]: get_routing_peer(): get_routing_peer(): No connected DefaultRoute peer found for app_id 16777236 and vendor id 0.
94(17458) ERROR: cdp [authstatemachine.c:870]: Send_STR(): unable to get routing peer in Send_STR
91(17455) INFO: ims_qos [ims_qos_mod.c:399]: callback_cdp_request(): Rx request handler(): - Received an IMS_ASR
Here are some simplified logs anc pcaps.
logsandcaps.zip
the zip has 4 files
pcap of ue1 attach
pcap od ue2 attach
log of ue1 attach on pcscf
log of ue2 attach on pcscf
I also compared my pcaps to your sample success pcaps.
i see in your pcap the OPTIONS packets get through while in my pcap as said by the logs the OPTIONS packets fail to reach the ue
also in your pcap all the 200 OK are going through GTP tunnel in my case they are not its just SIP not GTP SIP
could it be ogstun2 related?
i will try to capture ogstun2 traffic.
On the call ipsec to ipsec i see this:
In your pcap before the call i see S1AP E-RAB setup request and bearer setup request and response then the call comes in gtp sip
in my pcap there is no bearer setup before the call.
In ue1 to ue2 call i dont see GTP SIP but just SIP
In ue2 to ue1 call i see the GTP SIP
also in ue2 to ue1 call i see that right after the call fails there is a PDN connectivity request followed by an attach reject EPS services and non EPS services not allowed. and then a context release.
Could this be an eNB issue. I can instead use srsenb with bladerf but i seem to get no downlink to ue like that.
Should i maybe set something in the enb?
Looking forward to your directions
Here is the kernel routing table of the server:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.0.1 0.0.0.0 UG 0 0 0 eno1
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eno1
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 ogstun
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 ogstun2
Ifconfig of server:
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.20.2 netmask 255.0.0.0 broadcast 10.255.255.255
inet6 fe80::21e:c9ff:feb1:554d prefixlen 64 scopeid 0x20<link>
ether 00:1e:c9:b1:55:4d txqueuelen 1000 (Ethernet)
RX packets 184465 bytes 135686718 (135.6 MB)
RX errors 0 dropped 12 overruns 0 frame 0
TX packets 115578 bytes 61717711 (61.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 301375 bytes 63498397 (63.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 301375 bytes 63498397 (63.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ogstun: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.100.1 netmask 255.255.255.0 destination 192.168.100.1
inet6 fd84:6aea:c36e:2b69:: prefixlen 64 scopeid 0x0<global>
inet6 fe80::f48b:cdf9:f7b1:6c32 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 15377 bytes 4907797 (4.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 23519 bytes 22402797 (22.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ogstun2: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.101.1 netmask 255.255.255.0 destination 192.168.101.1
inet6 fe80::bf3d:1e9a:b66c:6c57 prefixlen 64 scopeid 0x20<link>
inet6 fd1f:76f3:da9b:101:: prefixlen 64 scopeid 0x0<global>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 1254 bytes 504127 (504.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1395 bytes 489625 (489.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
iptables -S
iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N rtpengine
-A INPUT -i ogstun2 -j ACCEPT
-A INPUT -i ogstun -j ACCEPT
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain rtpengine (0 references)
target prot opt source destination
Pings:
server to ue2 ims pdn: OK
server to ue2 internet pdn: OK
ue2 to server 192.168.100.1: OK
ue2 to server 192.168.101.1: OK
ue2 to server 10.0.20.2 : OK
server to ue1 ims pdn: OK
server to ue1 internet pdn: OK
ue1 to server 192.168.100.1: OK
ue1 to server 192.168.101.1: OK
ue1 to server 10.0.20.2 : OK
ue1 to ue2 ims: OK
ue1 to ue2 internet: OK
ue2 to ue1 ims: OK
ue2 to ue1 internet: OK
tunsetup.sh
#!/bin/bash
sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sh -c "echo 1 > /proc/sys/net/ipv6/ip_forward"
#ogstun
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 ! -o ogstun -j MASQUERADE
ip6tables -t nat -A POSTROUTING -s fd84:6aea:c36e:2b69::/64 ! -o ogstun -j MASQUERADE
iptables -I INPUT -i ogstun -j ACCEPT
ip6tables -I INPUT -i ogstun -j ACCEPT
#ogstun2
iptables -t nat -A POSTROUTING -s 192.168.101.0/24 ! -o ogstun -j MASQUERADE
#ip6tables -t nat -A POSTROUTING -s fd84:6aea:c36e:2b69::/64 ! -o ogstun -j MASQUERADE
iptables -I INPUT -i ogstun2 -j ACCEPT
ip6tables -I INPUT -i ogstun2 -j ACCEPT
however i noticed something very strange in pcrf.log
here is the log attached:
pcrf.log
Screenshots of HSS:
Any further info i am here,,
#ogstun2
iptables -t nat -A POSTROUTING -s 192.168.101.0/24 ! -o ogstun -j MASQUERADE
#ip6tables -t nat -A POSTROUTING -s fd84:6aea:c36e:2b69::/64 ! -o ogstun -j MASQUERADE
iptables -I INPUT -i ogstun2 -j ACCEPT
ip6tables -I INPUT -i ogstun2 -j ACCEPT
Please remove the above iptables for ogstun2 (although it doesnt affect but just to eliminate the variables)
Also in the pcrf logs i found this, are you using two SMFs?
And, btw can you try reducing the MTU in smf.yaml file to 1300? and then capture the traces on eNB and also on EPC +IMS?
Also, i saw in one of your traces eNB allocating the DRB with Id 15 (means some old bearers are not torn down), its not an issue but I would restart the eNB if possible
I am actually using one smf not sure how it is connecting to 2.. and where can i fix this?
i removed the iptables rule although i added it and it made no changes it was not there yesterday.
I have set the mtu in the file let me capture again.
also i keep stopping and starting the enb all the time so i guess there is a config issue.
I will look into it,
Also here are some traces from srsenb
srsenb.zip
I dont think your ZTE eNB is at fault here, rather I would recommend to use a commercial eNB
I believe the UE is at fault here but I could be wrong here. So lets simplify even more for UE. Goto to below menu in Samsung IMS settings
and uncheck/disable the "VoLTE precondition" and also uncheck/disable "enable IPSec" and then go back and save. Finally retry
This did not go good. PCSCF went into an infitine registering loop.
2(11191) NOTICE: <script>: Expires=600000
2(11191) NOTICE: <script>: Old header - WWW-Authenticate=Digest realm="ims.mnc001.mcc001.deltanet.org", nonce="T6tulQzhzcHjA6/pDjy/TqiGl+MmaAAAYHplZ4jFUcQ=", algorithm=AKAv1-MD5, ck="4443d015ec8aff9bea4b89212ec58280", ik="0966ced8484c4362210c68f776bc5fda", qop="auth,auth-int"
2(11191) NOTICE: <script>: New header - WWW-Authenticate=Digest realm="ims.mnc001.mcc001.deltanet.org", nonce="T6tulQzhzcHjA6/pDjy/TqiGl+MmaAAAYHplZ4jFUcQ=", algorithm=AKAv1-MD5, qop="auth,auth-int"
104(11370) NOTICE: <script>: PCSCF: REGISTER sip:ims.mnc001.mcc001.deltanet.org (sip:001010000000001@ims.mnc001.mcc001.deltanet.org (192.168.101.2:40225) to sip:001010000000001@ims.mnc001.mcc001.deltanet.org, CNR0IjeEws5bS9_vwonbfA..@192.168.101.2)
104(11370) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
104(11370) NOTICE: <script>: PCSCF REGISTER:
Destination URI: <null>
Request URI: sip:ims.mnc001.mcc001.deltanet.org
104(11370) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
104(11370) NOTICE: <script>: Source IP and Port: (192.168.101.2:40225)
Route-URI:
104(11370) NOTICE: <script>: Received IP and Port: (10.0.20.2:5060)
104(11370) NOTICE: <script>: Contact header: <sip:001010000000001@192.168.101.2:5060>;+sip.instance="<urn:gsma:imei:35340811-675669-0>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+g.3gpp.smsip
104(11370) INFO: ims_registrar_pcscf [sec_agree.c:264]: cscf_get_security(): No security parameters found
104(11370) INFO: ims_registrar_pcscf [sec_agree.c:296]: cscf_get_security_verify(): No security-verify parameters found
3(11192) ERROR: ims_ipsec_pcscf [cmd.c:672]: ipsec_create(): No security parameters found in contact
Repeating this over and over and over for both ue;s
here the pcap
noipsec.noprecon.pcapng.zip
SCSCF also didnt look good.
(11408) DEBUG: ims_auth [authorize.c:460]: challenge(): Suspending SIP TM transaction
3(11408) DEBUG: ims_auth [authorize.c:1528]: multimedia_auth_request(): Sending MAR
3(11408) DEBUG: ims_auth [cxdx_mar.c:549]: cxdx_send_mar(): Successfully sent async diameter
20(11440) INFO: ims_auth [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0)
20(11440) DEBUG: ims_auth [authorize.c:1305]: new_auth_vector(): new auth-vector with ck [2b4af4327b00d39c12ad6d823e14540a] with status 0
20(11440) DEBUG: ims_auth [authorize.c:1559]: pack_challenge(): setting QOP str used is [, qop="auth,auth-int"]
20(11440) DEBUG: ims_auth [authorize.c:1561]: pack_challenge(): QOP str used is [, qop="auth,auth-int"]
20(11440) DEBUG: ims_auth [authorize.c:1448]: get_auth_userdata(): Searching auth_userdata for IMPU sip:001010000000001@ims.mnc001.mcc001.deltanet.org (Hash 937)
20(11440) DEBUG: ims_auth [authorize.c:1457]: get_auth_userdata(): Found auth_userdata
20(11440) DEBUG: ims_auth [authorize.c:1681]: add_auth_vector(): Adding auth_vector (status 1) for IMPU sip:001010000000001@ims.mnc001.mcc001.deltanet.org / IMPI 001010000000001@ims.mnc001.mcc001.deltanet.org (Hash 937)
20(11440) DEBUG: ims_auth [cxdx_mar.c:464]: async_cdp_callback(): DBG:UAR Async CDP callback: ... Done resuming transaction
20(11440) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [1]
20(11440) WARNING: tm [t_suspend.c:192]: t_continue_helper(): active transaction not found
20(11440) DEBUG: ims_auth [cxdx_mar.c:87]: free_saved_transaction_data(): Freeing saved transaction data: async
1(11406) NOTICE: <script>: SCSCF: REGISTER sip:scscf.ims.mnc001.mcc001.deltanet.org:6060 (sip:001010000000001@ims.mnc001.mcc001.deltanet.org (10.0.20.2:4060) to sip:001010000000001@ims.mnc001.mcc001.deltanet.org, CNR0IjeEws5bS9_vwonbfA..@192.168.101.2)
1(11406) ERROR: <script>: ALGORITHM IS [AKAv1-MD5] and User-Agent is [SM-A715F-TK1 Samsung IMS 6.0]
1(11406) DEBUG: ims_auth [authorize.c:728]: authenticate(): Running authenticate, is_proxy_auth=0
1(11406) DEBUG: ims_auth [authorize.c:748]: authenticate(): Checking if REGISTER is authorized for realm [ims.mnc001.mcc001.deltanet.org]...
1(11406) DEBUG: ims_auth [utils.c:168]: get_nonce_response(): Calling find_credentials with realm [ims.mnc001.mcc001.deltanet.org]
1(11406) DEBUG: ims_auth [utils.c:57]: ims_find_credentials(): Searching credentials in realm [ims.mnc001.mcc001.deltanet.org]
1(11406) DEBUG: ims_auth [utils.c:92]: ims_find_credentials(): *hook = 0x7fd8b6f8ebc8
1(11406) DEBUG: ims_auth [utils.c:103]: ims_find_credentials(): Credential parsed successfully
1(11406) DEBUG: ims_auth [utils.c:106]: ims_find_credentials(): Comparing realm <ims.mnc001.mcc001.deltanet.org> and <ims.mnc001.mcc001.deltanet.org>
1(11406) DEBUG: ims_auth [utils.c:195]: get_nonce_response(): Found nonce response
1(11406) DEBUG: ims_auth [authorize.c:786]: authenticate(): Nonce or response missing: nonce len [0], response16 len[0]
1(11406) DEBUG: ims_auth [authorize.c:293]: challenge(): Looking for route block [REG_MAR_REPLY]
1(11406) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [-2]
1(11406) DEBUG: ims_auth [authorize.c:317]: challenge(): Need to challenge for realm [ims.mnc001.mcc001.deltanet.org]
1(11406) DEBUG: ims_auth [authorize.c:324]: challenge(): Checking if REGISTER is authorized for realm [ims.mnc001.mcc001.deltanet.org]...
1(11406) DEBUG: ims_auth [authorize.c:1448]: get_auth_userdata(): Searching auth_userdata for IMPU sip:001010000000001@ims.mnc001.mcc001.deltanet.org (Hash 937)
1(11406) DEBUG: ims_auth [authorize.c:1457]: get_auth_userdata(): Found auth_userdata
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
1(11406) DEBUG: ims_auth [authorize.c:1064]: get_auth_vector(): looping through AV status is 1 and were looking for 0
till infinity
I am guessing the UE didnt like disabling IPSec, please enable back only the IPSec
FInally!! Succes!! i managed to get a few test calls through .
With precondition off and mtu 1300 were key here! they solved the problem!!
Here are some pcaps..
However now the call dialed ends just as the other ue starts to ring and if i manage to pick up fast the call is unstabile, delays in audio, and crashes soon. could it be a ping issue or a timing issue?
OK setting MTU 1000 fixed it all. stabile call for 1 minute.
Eternal thankfulness from me for this. You are really a good person.
Hoping i can repay you for this one day.
P.S
I forgot to mention, the infinite loop was my misstake, i inserted 2 isims with the same impi and impu in both ues. not caused by ipsec
success.zip
Here are the traces i forgot.
So my final verdict is this, the air delay between the ue <--> enb <--> IMS+EPC is higher than the SIP protocol timeout.
It takes the packet longer to arrive server <--> ue than the ue and server are set to wait, i guess there is a variable somewhere to increase this? Since the enb is 15km away from the ims epc via 4 Microwave radio links.
Try increasing the following parameters in kamailio_pcsc.cfg
modparam("tm", "fr_timer", 3000)
# default invite retransmission timeout after 1xx: 120sec
modparam("tm", "fr_inv_timer", 120000)
# Increase timer for inbound requests, we may have to do failover:
t_set_fr(120000, 30000);
Its the time for transaction for INVITE and provisional responses in milliseconds. Try experimenting with it