Re: [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@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:;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: 
Record-Route: 
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: ;tag=19867159
From: ;tag=ab40-e3d19262d5e041c285ec0e9b00967d4b
CSeq: 1 NOTIFY
Call-ID: 
wlss-29dc9ccc-3d09899a4a9e634d0256bdf3c2cf8f0b@10.204.182.27
Max-Forwards: 69
Content-Length: 566
User-Agent: OpenSIPS (2.4.8 (x86_64/linux))
Event: presence
Contact: 
Subscription-State: active;expires=300
Content-Type: application/pidf+xml

Refresh subscribe:

Received SUBSCRIBE sip:sa@10.29.109.130:5060;transport=tcp SIP/2.0^M
Content-Length: 0^M
CSeq: 2 SUBSCRIBE^M
Expires: 300^M
Route: ^M
Route: ^M
Contact: 
^M
Call-ID: 
wlss-af3350b7-c077bdf207ff802e84fa32ed40d47aed@10.204.182.27^M
Max-Forwards: 70^M
From: ;tag=3427a3ff^M
To: ;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 dis

Re: [OpenSIPS-Users] Quality Routing Module in Opensips_3.1

[Saurabh Chopra]

Hi Tony/Opensips Team,

Happy New Year,

I have tried to test with default values in my configuration file but no
luck.The call is still going to the first gateway i.e. 104.XX.XX.XX. If
possible could you please help us at configuration side, what parameters
should be allowed to test this Qrouting module. Below is the output
for opensips-cli -x mi qr_status:-

"Carrier": {
"CRID": "cr1",
"Gateways": [
{
"GWID": "gw1",
"ASR": "-1.00/9",
"CCR": "-1.00/9",
"PDD": "-1.00/7",
"AST": "-1.00/7",
"ACD": "-1.00/7"
},
{
"GWID": "gw2",
"ASR": "-1.00/0",
"CCR": "-1.00/0",
"PDD": "-1.00/0",
"AST": "-1.00/0",
"ACD": "-1.00/0"
}
]


Best Regards
Saurabh Chopra
+918861979979


On Mon, Dec 21, 2020 at 4:18 PM Saurabh Chopra  wrote:

> Hi Tony/Opensips Team,
>
> Will test it with default values as per your suggestion and will post the
> result of statistics for each of the gateways.
>
>
> Best Regards
> Saurabh Chopra
> +918861979979
>
>
> On Sun, Dec 20, 2020 at 3:09 PM Tomi Hakkarainen 
> wrote:
>
>> Hi,
>>
>> never used myself but as reading the doc and your config, here some of my
>> thoughts.
>>
>> I see you are setting min_samples to zero and My guess is that that way
>> they will stay healthy forever?
>> Maybe adjust the config of min_samples to something like default or 15
>> and look how it behaves...
>> also have you viewed what the statistics show while testing? ( opensips-cli
>> -x mi qr_status )
>> Would like to hear how it goes :)
>>
>> Tomi
>>
>> On 18. Dec 2020, at 15.03, Saurabh Chopra  wrote:
>>
>> 
>> Hi All,
>>
>> Kindly update me on the query raised on Qrouting.
>>
>> Best Regards
>> Saurabh Chopra
>> +918861979979
>>
>>
>> On Thu, Dec 17, 2020 at 3:43 PM Saurabh Chopra 
>> wrote:
>>
>>> Hi All,
>>>
>>> I want to test the new quality routing module, previously i have tested
>>> the dynamic routing and it works for me. But somehow, qrouting module is
>>> not running as per my expectation. My understanding is qrouting module
>>> helps us to choose a better gateway at run time as per statistics like
>>> ASR,PDD,AST etc. I took two asterisk gateways
>>> 1:- 162.243.XX.XXX
>>> 2:- 104.131.XXX.XXX
>>>
>>> I have deliberately given 15sec wait on 104.131.XXX.XXX asterisk after
>>> this it will send 200 OK response for the call. So as per qrouting module,
>>> AST statistics for 104.131.XXX.XXX gateway would somewhat be lower than
>>> this 162.243.XX.XXX.
>>>
>>> So,I am expecting the call should mostly be reached to 162.243.XX.XXX
>>> gateway instead of 104.131.XXX.XXX, but this is not happening as calls are
>>> reaching to 104.131.XXX.XXX gateway which has poor statistics i.e AST.
>>>
>>> *Configuration done at mysql is given below:-*
>>> mysql> select * from dr_rules;
>>>
>>> ++-++-+--+-+---+--+--+---++
>>> | ruleid | groupid | prefix | timerec | priority | routeid | gwlist |
>>> sort_alg | sort_profile | attrs | description|
>>>
>>> ++-++-+--+-+---+--+--+---++
>>> |  1 | 1   || |0 | |
>>> gw2=50,gw1=50 | Q|1 |   | XXX_gateway |
>>>
>>> ++-++-+--+-+---+--+--+---++
>>> 1 row in set (0.00 sec)
>>>
>>> mysql> select * from dr_gateways;
>>>
>>> ++--+--+--+---++---++---++--+
>>> | id | gwid | type | address  | strip | pri_prefix | attrs |
>>> probe_mode | state | socket | description |
>>>
>>> ++--+--+--+---++---++---++--+
>>> |  1 | gw1  |3 | 162.243.XX.XXX:5080  | 0 || NULL  |
>>>  0 | 0 | NULL   | 0|
>>> |  2 | gw2  |3 | 104.131.XXX.XXX:5080 | 0 || NULL  |
>>>  0 | 0 | NULL   | testing gateway2 |
>>>
>>> ++--+--+--+---++---++---++--+
>>

Re: [OpenSIPS-Users] Transparent TLS

[Răzvan Crainea]

Hi, Yavari!

Happy new year!
No, this is not possible - OpenSIPS is only able to route packages based 
on SIP packets - if you create an end-to-end connection between the 
client and media servers, OpenSIPS will not be able to decrypt the 
packages to know where to send what. OpenSIPS (and the entire SIP stack, 
by specifications) is not connection oriented, so packets can't be 
routed based on a previously established connection, only by SIP headers.


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 12/31/20 2:57 AM, H Yavari via Users wrote:

Hi to all,

Happy holidays.

In a distributed scenario, is it possible to have a TLS transparent with 
Opensips?
I mean clients make TLS connection with the nodes behind the proxy 
server/load balancer and next time they can connect to the other nodes 
but TLS connection is end to end between client and media server (AS/FS 
etc.).

Please advise.

Regards,
HYavari




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users