**Description** We use below config to test the topology hiding function,when kamailio receive “update” message,doesn't send out,it will send to itself with destination port 5060;
**Troubleshooting** loadmodule "ndb_redis.so" loadmodule "topos_redis.so" loadmodule "topos.so" modparam("ndb_redis", "server", "name=srv8;addr=127.0.0.1;port=6381;db=2") modparam("topos", "storage", "redis") modparam("topos", "db_url", "redis://127.0.0.1:6381/2") modparam("topos_redis", "serverid", "srv8")
-------- Call flow UE-----------------PROXY-------------B2bua invite-------------->|------------------>invite 183<----------------|<------------------183 Prack------------ ->|------------------>Prack 200ok<-------------|<-----------------200ok update1---------->|-------------| |update2<---| 404<---------------|
**update1:** UPDATE sip:atpsh-5fc1a2c3-5749-2@172.18.67.40 SIP/2.0 Via: SIP/2.0/UDP 172.18.67.34:5062;branch=z9hG4bK-15000-1-0 From: tel:+8618768860000;tag=1 To: tel:32001232;phone-context=ims.mnc002.mcc460.3gppnetwork.org;tag=BH83c9DQXKgvp Call-ID: 1-15000@172.18.67.34 CSeq: 1002 UPDATE Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE,INFO,PRACK,NOTIFY,MESSAGE,REFER Contact: sip:+8618768860000@172.18.67.34:5062;zte-did=8-11-20481-2871-12-666-65535;Hpt=8ec8_16;CxtId=4;TRC=ffffff-ffffffff;audio;vid ;+sip.instance="urn:gsma:imei:86183004-974965-0";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.pss-srvcc-orig-pre-alerting;+g.3gpp csi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
**update2:**
UPDATE sip:172.18.67.50;r2=on;lr=on;ftag=1;did=874.5af1;vsf=BwwcABoAAQcADwAICAYAcAEHMi4xOC42Ny4zNA-- SIP/2.0 Via: SIP/2.0/UDP 172.18.67.40:55067;branch=z9hG4bK296a.feb7a8004f743a745739026289e0010e.0 From: tel:+8618768860000;tag=1 To: tel:32001232;phone-context=ims.mnc002.mcc460.3gppnetwork.org;tag=BH83c9DQXKgvp Call-ID: 1-15000@172.18.67.34 CSeq: 1002 UPDATE Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE,INFO,PRACK,NOTIFY,MESSAGE,REFER Max-Forwards: 70 Require: precondition Supported: histinfo,replaces,precondition,100rel,timer User-Agent: IM-client/OMA1.0 HW-Rto/V1.0 P-Access-Network-Info: 3GPP-E-UTRAN;utran-cell-id-3gpp=4600039c6b98855b;network-provided;sbc-domain=luypsbc22bzx.0371.101.ha.chinamobi .com P-Charging-Vector: icid-value=No1ZR2PilD-0000a442-0d-0000816e-001;orig-ioi=chinamobile Content-Type: application/sdp Content-Disposition: session Content-Length: 743 Contact: sip:btpsh-5fc1a2c3-5749-2@172.18.67.50
below ip and port are configured for kamailio; 172.18.67.40:55067 172.18.67.50:5060
**Additional Information** version: kamailio 5.4.2 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 20:13:39 Nov 9 2020 with gcc 4.8.5
Closed #2655.
UPDATE requests should be routed fine as requests within active dialogs.
This looks like some misconfiguration or a broken SIP entity somewhere, because the R-URI for UPDATE2 looks like a Route header URI, not a contact URI. That can happen because Kamailio considers the R-URI (after TOPOS processing) points to itself.
You need to get the pcap with the SIP traffic for the entire call, from initial INVITE to the UPDATE requests and email to sr-users@lists.kamailio.org to get assistance, because it does not seem to be about a C code issue. If I am wrong, then this item can be reopen.
I have been testing repeatedly these days, and I think there should be a problem here. I will open a new issue to describe him. Excuse me, I really think this is problematic