[OpenSIPS-Users] Topology hiding for presence: NOTIFY/Subscription refresh not successfully matching topology hiding

[Govindaraj, Rajesh]

I triaged this issue further, the root cause was the contact was modified at opensips presence server using fixed_nated_contact API call as it traverses a non sip aware load balancer on the way. Due to this the NOTIFY request URI had a TCP ephemeral port and check_self API call failed and topology hiding match logic was not getting triggered.

Had to force the port to method check_self to 5060 and the issue got resolved. Not sure if there is a cleaner fix for this issue. I think the fact a non sip aware load balancer is in the path is the root cause. Please suggest if there is a way to fix this without any code change.

Thanks,

From: Govindaraj, Rajesh
Sent: Tuesday, December 29, 2020 1:15 PM
To: users at lists.opensips.org
Subject: Topology hiding for presence: NOTIFY/Subscription refresh not successfully matching topology hiding

Hi,

I am facing issues with topology hiding implementation for presence which was necessitated as existing TCP connections have to be used at Presence server and couldn't achieve this with record route routing and having original contact of application server.
Thanks for all your time and help. I am sure I am missing something small but I spent hours searching and reading up on Internet and would solicit your expertise to resolve this.

Objective: TCP transport for presence.

Topology:   opensips presence server <----> opensips proxy <----> IPC's Application Server.

Approach:

Case i: Without topology hiding and using record route:

In this case opensips proxy was adding two record route one for itself with sip:<ip>;transport=tcp<sip:%3cip%3e;transport=tcp> and via header carried rport. Opensips presence server while sending NOTIFY was throwing as TCP error,
Read through forum and understood that initial tcp request has to be re-used. Studied if alias can be used and also experimented with force_tcp_alias, but no luck.

Case ii: With topology hiding, no record route, use new contact:

With this approach able to get back initial NOTIFY
NOTIFY sip:172.29.109.119:40968;transport=tcp;thinfo=VG8tbzAdIFskPyccJRwmBhBQY31mX2RBckxiT2FkblpgWnpPJBMyPScfPx03SSUFI2gjAyMcIB00XGVmZltjCXVBMwdlaCcGIA4zBCMEICA9AD4GJ0kxESN+YxUjAC8aYlEiJTMcaxgvByMHMDowUiMGM1lhFzlqOx4qBjQXaAs+RVQaNB95RWBPYWNgQWFXcVpiVmlmZFlg SIP/2.0

With thinfo in request URI. Contact header of opensips sip server is present.

Now as per docs, tried to do topology_hiding_match by calling topology_hiding_match(), get this response,

DID NOT found,

I tried to add DID_NONE but don't see any log in the syslog.

The NOTIFY with contact header of opensip sip server is sent to Application Server. Record_route is called on this NOTIFY and record route is added without DID param.

When the subscription response comes back, the sample request below,(having the contact of opensips presence server no thinfo from 200ok for subscribe) the topology_hiding_match fails and the request does not go out.
I tried to load dialog module, call create_dialog but I understand that for subscribe the dialog would not be created. Please correct me if I am wrong. I also read about route header being used in opensips 2.1 per this thread,
https://opensips.org/pipermail/users/2017-December/038606.html but this is not being used in opensips version 2.4.7.

Not sure what am I missing. Please advise.

10.204.182.27 - Server running opensips proxy and application server.

10.29.109.130 - Opensips presence server

NOTIFY sent to application server:

NOTIFY sip:10.204.182.27:5059;transport=tcp;thinfo=VG8sbzAdIFskPyccJRwmBhBQY31mX2RBckxiT2FkblpgWnpPJBMyPScfPx03SSUFI2gjAyMcIB00XGVmZltjCXVBMwdlaCcGIA4zBCMEICA9AD4GJ0kxESN+JhYxXiZDYgNrJT4BaxgvByMHMDowUiMGM1lnFCJrbVY1WiBANldFUyELIFVyRH5TY2d6XmhdbUZnW2ZjYl8- SIP/2.0
Record-Route: <sip:10.204.182.27;r2=on;lr>
Record-Route: <sip:10.204.182.27;transport=tcp;r2=on;lr>
Via: SIP/2.0/UDP 10.204.182.27:5060;branch=z9hG4bK354b.18876e240190157c6feb29c18068a57a.0;i=685d8901
Via: SIP/2.0/TCP 10.42.3.115:5060;received=172.29.109.130;branch=z9hG4bK354b.faa91951.0
To: <sip:9797 at 10.204.182.27>;tag=19867159
From: <sip:9797-1 at ipc11.com>;tag=ab40-e3d19262d5e041c285ec0e9b00967d4b
CSeq: 1 NOTIFY
Call-ID: wlss-29dc9ccc-3d09899a4a9e634d0256bdf3c2cf8f0b at 10.204.182.27<mailto:wlss-29dc9ccc-3d09899a4a9e634d0256bdf3c2cf8f0b at 10.204.182.27>
Max-Forwards: 69
Content-Length: 566
User-Agent: OpenSIPS (2.4.8 (x86_64/linux))
Event: presence
Contact: <sip:sa at 10.29.109.130:5060;transport=tcp>
Subscription-State: active;expires=300
Content-Type: application/pidf+xml

Refresh subscribe:

Received SUBSCRIBE sip:sa at 10.29.109.130:5060;transport=tcp SIP/2.0^M
Content-Length: 0^M
CSeq: 2 SUBSCRIBE^M
Expires: 300^M
Route: <sip:10.204.182.27;r2=on;lr>^M
Route: <sip:10.204.182.27;transport=tcp;r2=on;lr>^M
Contact: <sip:wlssuser at 10.204.182.27:5059;transport=udp;wlsscid=65243f65cf6;sipappsessionid=app-7sa7kf2qbv51;wlssfcid=sip-1xgt8c89zz6kk>^M
Call-ID: wlss-af3350b7-c077bdf207ff802e84fa32ed40d47aed at 10.204.182.27^M<mailto:wlss-af3350b7-c077bdf207ff802e84fa32ed40d47aed at 10.204.182.27%5eM>
Max-Forwards: 70^M
From: <sip:9797 at 10.204.182.27>;tag=3427a3ff^M
To: <sip:9797-1 at ipc11.com>;tag=ab40-f97bec0eac0c0e4c851f049586838577^M
Event: presence^M
Via: SIP/2.0/UDP 10.204.182.27:5059;wlsscid=65243f65cf6;branch=z9hG4bK186c9181e96cf3053271dcd2b59330cd

Thanks,




DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. 
If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have received it in error. 
Unintended recipients are prohibited from taking action on the basis of information in this e-mail. 
E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, 
deleted or interfered with without the knowledge of the sender or the intended recipient. 
If you are not comfortable with the risks associated with e-mail messages, 
you may decide not to use e-mail to communicate with IPC. IPC reserves the right, 
to the extent and under circumstances permitted by applicable law, 
to retain, monitor and intercept e-mail messages to and from its systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210104/cc4bf1e2/attachment-0001.html>