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
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
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
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