Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]* * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347* * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0 * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm
[t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
I have enabled all debug logs and i traced it and I found that as you said it is keep on looping the invite in pcscf instead of going to other UE . I couldn't able to find the reason.Can you please give me some input on this.
Debug logs of pcscf : 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060 ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: sip:bob@sip.example.com;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: sip:alice@sip.example.com;transport=UDP;tag=cdbaae3f#015#012Call-ID: I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite Proxy-CSCF#015#012Content-Length: 0
As you see here , continuously invite is going on looping in 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the needful.
On Wed, Apr 15, 2020, 2:19 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm
[t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
That usually happens when you don’t set a next hop, or destination where the packet should go, so the packet of forwarded to the same destination, which is the proxy again.
On Thu, 16 Apr 2020 at 06:56, Pavithra M pavimohan3096@gmail.com wrote:
Hi,
I have enabled all debug logs and i traced it and I found that as you said it is keep on looping the invite in pcscf instead of going to other UE . I couldn't able to find the reason.Can you please give me some input on this.
Debug logs of pcscf : 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060 ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: sip:bob@sip.example.com;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: sip:alice@sip.example.com;transport=UDP;tag=cdbaae3f#015#012Call-ID: I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite Proxy-CSCF#015#012Content-Length: 0
As you see here , continuously invite is going on looping in 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the needful.
On Wed, Apr 15, 2020, 2:19 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm
[t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hi ,
I am getting the call connected and got 200 ok from the client . But the INVITE packet goes multiple times between terminating pcscf and s-cscf and gives too many hops error .Even After that call goes perfectly fine with 200 ok message. What would be the reason . I am not getting any errors in my logs with debug log level 6 .
Kindly tell me what could be the issue .
On Thu, Apr 16, 2020, 2:16 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
That usually happens when you don’t set a next hop, or destination where the packet should go, so the packet of forwarded to the same destination, which is the proxy again.
On Thu, 16 Apr 2020 at 06:56, Pavithra M pavimohan3096@gmail.com wrote:
Hi,
I have enabled all debug logs and i traced it and I found that as you said it is keep on looping the invite in pcscf instead of going to other UE . I couldn't able to find the reason.Can you please give me some input on this.
Debug logs of pcscf : 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060 ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: sip:bob@sip.example.com;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: sip:alice@sip.example.com;transport=UDP;tag=cdbaae3f#015#012Call-ID: I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite Proxy-CSCF#015#012Content-Length: 0
As you see here , continuously invite is going on looping in 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the needful.
On Wed, Apr 15, 2020, 2:19 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm
[t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
You need to trace sip. There’s a loop somewhere. Use tshark (wireshark) or sngrep or ngrep, or some similar network tracing tool.
On Fri, 17 Apr 2020 at 11:34, Pavithra M pavimohan3096@gmail.com wrote:
Hi ,
I am getting the call connected and got 200 ok from the client . But the INVITE packet goes multiple times between terminating pcscf and s-cscf and gives too many hops error .Even After that call goes perfectly fine with 200 ok message. What would be the reason . I am not getting any errors in my logs with debug log level 6 .
Kindly tell me what could be the issue .
On Thu, Apr 16, 2020, 2:16 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
That usually happens when you don’t set a next hop, or destination where the packet should go, so the packet of forwarded to the same destination, which is the proxy again.
On Thu, 16 Apr 2020 at 06:56, Pavithra M pavimohan3096@gmail.com wrote:
Hi,
I have enabled all debug logs and i traced it and I found that as you said it is keep on looping the invite in pcscf instead of going to other UE . I couldn't able to find the reason.Can you please give me some input on this.
Debug logs of pcscf : 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060 ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: sip:bob@sip.example.com;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: sip:alice@sip.example.com;transport=UDP;tag=cdbaae3f#015#012Call-ID: I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite Proxy-CSCF#015#012Content-Length: 0
As you see here , continuously invite is going on looping in 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the needful.
On Wed, Apr 15, 2020, 2:19 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm
[t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
Hi,
Most likely this is because of the change. Revert back the changes (uncomment the section I told you), turn on debug in scscf.cfg, restart all nodes and test once again. Then have a look on the scscf logs.
Regards, Pavel Siderov _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hi, In Wireshark , I couldn't able to see the looping packets .In debug logs of pcscf , I am able to see the looping occurs . But how then the call gets connected . That's where I am struck .
On Fri, Apr 17, 2020, 4:11 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You need to trace sip. There’s a loop somewhere. Use tshark (wireshark) or sngrep or ngrep, or some similar network tracing tool.
On Fri, 17 Apr 2020 at 11:34, Pavithra M pavimohan3096@gmail.com wrote:
Hi ,
I am getting the call connected and got 200 ok from the client . But the INVITE packet goes multiple times between terminating pcscf and s-cscf and gives too many hops error .Even After that call goes perfectly fine with 200 ok message. What would be the reason . I am not getting any errors in my logs with debug log level 6 .
Kindly tell me what could be the issue .
On Thu, Apr 16, 2020, 2:16 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
That usually happens when you don’t set a next hop, or destination where the packet should go, so the packet of forwarded to the same destination, which is the proxy again.
On Thu, 16 Apr 2020 at 06:56, Pavithra M pavimohan3096@gmail.com wrote:
Hi,
I have enabled all debug logs and i traced it and I found that as you said it is keep on looping the invite in pcscf instead of going to other UE . I couldn't able to find the reason.Can you please give me some input on this.
Debug logs of pcscf : 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060 ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: sip:bob@sip.example.com;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: sip:alice@sip.example.com;transport=UDP;tag=cdbaae3f#015#012Call-ID: I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite Proxy-CSCF#015#012Content-Length: 0
As you see here , continuously invite is going on looping in 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the needful.
On Wed, Apr 15, 2020, 2:19 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
Hi , Yes , I have tried uncommenting that part . It is actually checking for hostname (sip.example.com:5060) in my scscf node. I am not sure why it is looking for sip.example.com instead of scscf.sip.example.com:4080
I have added one more alias in my scscf.cfg file .Now Domain not served issue has gone. After that I am facing 483 Too Many Hops Error.
I have added scscf debug logs.
Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed from ims_registrar_scscf: lookup.c: lookup(103) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1041 a=16 n=if
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && [10.45.6.75] == [10.45.6.73]*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/socket_info.c:635]: grep_sock_info(): checking if port 4080 (advertise 0) matches port 32347*
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core>
[core/forward.c:412]: check_self(): host != me* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1050 a=5 n=route Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=821 a=16 n=if Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] l=818 a=25 n=is_present_hf Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] l=1052 a=24 n=t_relay Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global id=2/7139 T start=(nil) Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0
- Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm
[t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) called from tm: h_table.c: build_cell(330)
I am facing host is not me error . Here 10.45.6.73 -> scscf and 10.45.6.75 -> UE (bob user) I am not sure what alias it is asking for . Kindly help.
On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote:
> Hi, > > Most likely this is because of the change. Revert back the changes > (uncomment the section I told you), turn on debug in scscf.cfg, restart all > nodes and test once again. Then have a look on the scscf logs. > > Regards, > Pavel Siderov > _______________________________________________ > Kamailio (SER) - Development Mailing List > sr-dev@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev > _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
It doesn’t make a lot of sense to see looping calls “connected”. If they connect, then they’re not looping, unless there is some counter somewhere that answers the call when it sees a loop.
That’s very weird.
Use sngrep and trace on ALL interfaces.
On Fri, 17 Apr 2020 at 11:46, Pavithra M pavimohan3096@gmail.com wrote:
Hi, In Wireshark , I couldn't able to see the looping packets .In debug logs of pcscf , I am able to see the looping occurs . But how then the call gets connected . That's where I am struck .
On Fri, Apr 17, 2020, 4:11 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You need to trace sip. There’s a loop somewhere. Use tshark (wireshark) or sngrep or ngrep, or some similar network tracing tool.
On Fri, 17 Apr 2020 at 11:34, Pavithra M pavimohan3096@gmail.com wrote:
Hi ,
I am getting the call connected and got 200 ok from the client . But the INVITE packet goes multiple times between terminating pcscf and s-cscf and gives too many hops error .Even After that call goes perfectly fine with 200 ok message. What would be the reason . I am not getting any errors in my logs with debug log level 6 .
Kindly tell me what could be the issue .
On Thu, Apr 16, 2020, 2:16 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
That usually happens when you don’t set a next hop, or destination where the packet should go, so the packet of forwarded to the same destination, which is the proxy again.
On Thu, 16 Apr 2020 at 06:56, Pavithra M pavimohan3096@gmail.com wrote:
Hi,
I have enabled all debug logs and i traced it and I found that as you said it is keep on looping the invite in pcscf instead of going to other UE . I couldn't able to find the reason.Can you please give me some input on this.
Debug logs of pcscf : 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060 ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: sip:bob@sip.example.com;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: sip:alice@sip.example.com;transport=UDP;tag=cdbaae3f#015#012Call-ID: I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite Proxy-CSCF#015#012Content-Length: 0
As you see here , continuously invite is going on looping in 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the needful.
On Wed, Apr 15, 2020, 2:19 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
You should be tracing, you’re probably not, otherwise you would see the server is probably forwarding the INVITE to itself (removing one hop every time as it must) and thus creating a loop.
On Wed, 15 Apr 2020 at 09:42, Pavithra M pavimohan3096@gmail.com wrote:
> Hi , > Yes , I have tried uncommenting that part . It is actually checking > for hostname (sip.example.com:5060) in my scscf node. I am not sure > why it is looking for sip.example.com instead of > scscf.sip.example.com:4080 > > I have added one more alias in my scscf.cfg file .Now Domain not > served issue has gone. > After that I am facing 483 Too Many Hops Error. > > I have added scscf debug logs. > > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> > [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, > 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> > [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed > from ims_registrar_scscf: lookup.c: lookup(103) > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** > cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] > l=1041 a=16 n=if > * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> > [core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && > [10.45.6.75] == [10.45.6.73]* > * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> > [core/socket_info.c:635]: grep_sock_info(): checking if port 4080 > (advertise 0) matches port 32347* > * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> > [core/forward.c:412]: check_self(): host != me* > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** > cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] > l=1050 a=5 n=route > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** > cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] > l=821 a=16 n=if > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** > cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] > l=818 a=25 n=is_present_hf > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** > cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] > l=1052 a=24 n=t_relay > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm > [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global > id=2/7139 T start=(nil) > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm > [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0 > * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm > [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - > via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm > [t_lookup.c:675]: t_lookup_request(): no transaction found > Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> > [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) > called from tm: h_table.c: build_cell(330) > > I am facing host is not me error . Here 10.45.6.73 -> scscf and > 10.45.6.75 -> UE (bob user) > I am not sure what alias it is asking for . Kindly help. > > On Wed, Apr 15, 2020 at 1:36 PM Pafel pafels@gmail.com wrote: > >> Hi, >> >> Most likely this is because of the change. Revert back the changes >> (uncomment the section I told you), turn on debug in scscf.cfg, restart all >> nodes and test once again. Then have a look on the scscf logs. >> >> Regards, >> Pavel Siderov >> _______________________________________________ >> Kamailio (SER) - Development Mailing List >> sr-dev@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >> > _______________________________________________ > Kamailio (SER) - Development Mailing List > sr-dev@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-
David Villasmil -
Pafel -
Pavithra M