[SR-Users] Source Port on TLS OPTIONS from Dispatcher

[Charles Phillips]

Hello all.  As they say in radio, “long time listener, first time caller”

Anyway, I am having trouble getting past the following road block and any help 
would be greatly appreciated.

Kamailio version is 5.4.3 

When attempting to use dispatcher to send OPTIONS packets to several TLS 
destinations, the packets are leaving the Kamailio server on random ports.  
This is a problem because the servers I am sending the OPTIONS to (MS Teams) 
are enforcing rport so the responses are returned to a port that Kamailio is 
not listening on.  I have tried to force the socket in the event route 
(relevant parts of snippet below) but it does not appear to help.  I should 
also mention that I am not behind NAT and the TLS socket is specified in the 
dispatcher attrs. 

event_route[tm:local-request] {
sip_trace();


$fs = “tls:**ip-address**:5061”;


}

I have used Kamailio as a TLS server for many projects, but this is my first 
time as a client.  I am sure I am missing something.

- Charles




___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

[Charles Phillips]

Thanks for the quick response Joel.  Yes, I have read the article and I have 
tested and confirmed that I am correctly appending the contact header (I 
probably should have left that in the snippet for clarity).  Below is an 
example of Kamailio setting up the connection.  It is going out port 46245 this 
time, but it is random.

07:59:23.572319 IP *my.kamailio.server*.46245 > *ms.teams.server*.sip-tls: 
Flags [P.], seq 1:518, ack 1, win 502, length 517
07:59:23.802458 IP *ms.teams.server*.sip-tls > *my.kamailio.server*.46245: 
Flags [P.], seq 1:3767, ack 518, win 2051, length 3766

The TLS connection shows as successful in the logs.


- Charles 


Date: Thu, 7 Jan 2021 19:12:10 -0800
From: Joel Serrano mailto:j...@textplus.com>>
To: "Kamailio (SER) - Users Mailing List"
mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher
Message-ID:
mailto:CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5jd7sl4cvybyx...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Hi Charles,

I don't think your issue is rport, make sure you are setting the Contact
header correctly.

Have you checked this blog post:
https://skalatan.de/en/blog/kamailio-sbc-teams 
<https://skalatan.de/en/blog/kamailio-sbc-teams> ?

There is a specific section that talks about how to tell Kamailio to send
the OPTIONS like MS Teams wants them.

Good luck,
Joel.


> On Jan 7, 2021, at 7:31 PM, Charles Phillips  wrote:
> 
> Hello all.  As they say in radio, “long time listener, first time caller”
> 
> Anyway, I am having trouble getting past the following road block and any 
> help would be greatly appreciated.
> 
> Kamailio version is 5.4.3 
> 
> When attempting to use dispatcher to send OPTIONS packets to several TLS 
> destinations, the packets are leaving the Kamailio server on random ports.  
> This is a problem because the servers I am sending the OPTIONS to (MS Teams) 
> are enforcing rport so the responses are returned to a port that Kamailio is 
> not listening on.  I have tried to force the socket in the event route 
> (relevant parts of snippet below) but it does not appear to help.  I should 
> also mention that I am not behind NAT and the TLS socket is specified in the 
> dispatcher attrs. 
> 
> event_route[tm:local-request] {
> sip_trace();
> 
> 
> $fs = “tls:**ip-address**:5061”;
> 
> 
> }
> 
> I have used Kamailio as a TLS server for many projects, but this is my first 
> time as a client.  I am sure I am missing something.
> 
> - Charles
> 
> 
> 
> 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

[Charles Phillips]

Thanks Daniel, I needed some certainty to get unstuck.  It appears that the 
problem is actually related to the TLS config.  I am using multiple TLS 
configs, so it looks like the problem may be that the server_name server_id are 
not being set, so the reply is returning to the default TLS config.  Not to 
mention that when I set the testing domains certs under the default config, it 
works...

This is observed in the logs:

tls_get_connect_server_name(): xavp with outbound server name not found
tls_get_connect_server_id(): xavp with outbound server id not found
tls_complete_init(): Using initial TLS domain TLSc 

Is there a way to set this with xavp_cfg in the event_route?  I have read that 
section and tried may combinations, but since the OPTIONs packets from the 
dispatcher module do not seem to traverse the standard routes, I am not sure 
how to handle this.

Any advice would be greatly appreciated!


- Charles Phillips




> On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> there is an option that you can set to reuse the port for tcp/tls 
> connections, but even so it is a best effort and it is not going to ensured 
> -- all these are practically flags set to the sockets and the kernel (tcp 
> stack) decides after all.
> 
> Anyhow, the rport is mainly useful for connectionless communication, like 
> UDP. For tcp/tls, the SIP specs demand to reuse the existing connections. As 
> I did several Kamailio-MSTeams interconnectivity deployments, I can tell that 
> the source port was never a problem. The TLS connection is kept open and 
> MSTeams sends back traffic on it.
> 
> Cheers,
> Daniel
> 
> On 08.01.21 14:32, Charles Phillips wrote:
>> Thanks for the quick response Joel.  Yes, I have read the article and I have 
>> tested and confirmed that I am correctly appending the contact header (I 
>> probably should have left that in the snippet for clarity).  Below is an 
>> example of Kamailio setting up the connection.  It is going out port 46245 
>> this time, but it is random.
>> 
>> 07:59:23.572319 IP *my.kamailio.server*.46245 > *ms.teams.server*.sip-tls: 
>> Flags [P.], seq 1:518, ack 1, win 502, length 517
>> 07:59:23.802458 IP *ms.teams.server*.sip-tls > *my.kamailio.server*.46245: 
>> Flags [P.], seq 1:3767, ack 518, win 2051, length 3766
>> 
>> The TLS connection shows as successful in the logs.
>> 
>> 
>> - Charles 
>> 
>> 
>> Date: Thu, 7 Jan 2021 19:12:10 -0800
>> From: Joel Serrano mailto:j...@textplus.com>>
>> To: "Kamailio (SER) - Users Mailing List"
>>  mailto:sr-users@lists.kamailio.org>>
>> Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher
>> Message-ID:
>>  > <mailto:CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5jd7sl4cvybyx...@mail.gmail.com>>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Hi Charles,
>> 
>> I don't think your issue is rport, make sure you are setting the Contact
>> header correctly.
>> 
>> Have you checked this blog post:
>> https://skalatan.de/en/blog/kamailio-sbc-teams 
>> <https://skalatan.de/en/blog/kamailio-sbc-teams> ?
>> 
>> There is a specific section that talks about how to tell Kamailio to send
>> the OPTIONS like MS Teams wants them.
>> 
>> Good luck,
>> Joel.
>> 
>> 
>>> On Jan 7, 2021, at 7:31 PM, Charles Phillips >> <mailto:char...@rustybike.com>> wrote:
>>> 
>>> Hello all.  As they say in radio, “long time listener, first time caller”
>>> 
>>> Anyway, I am having trouble getting past the following road block and any 
>>> help would be greatly appreciated.
>>> 
>>> Kamailio version is 5.4.3 
>>> 
>>> When attempting to use dispatcher to send OPTIONS packets to several TLS 
>>> destinations, the packets are leaving the Kamailio server on random ports.  
>>> This is a problem because the servers I am sending the OPTIONS to (MS 
>>> Teams) are enforcing rport so the responses are returned to a port that 
>>> Kamailio is not listening on.  I have tried to force the socket in the 
>>> event route (relevant parts of snippet below) but it does not appear to 
>>> help.  I should also mention that I am not behind NAT and the TLS socket is 
>>> specified in the dispatcher attrs. 
>>> 
>>> event_route[tm:local-request] {
>>> sip_trace();
>>> 
>>> 
>>> $fs = “tls:**ip-address**:5061”;
>>> 
>>> 
>>> }
>>> 
>>> I have used Kamailio as a TLS server for many projects, b

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

[Charles Phillips]

That is what I figured was happening.  I have tried sending it back to a 
standard routing block, but perhaps I am doing it incorrectly.

When I try to send it back to a regular routing block I get the following error:

CRITICAL: tm [tm.c:1754]: _w_t_relay_to(): unsupported route type: 64

Config:

event_route[tm:local-request] {
sip_trace();
if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com") {
$var(domain) = $fd;
append_hf("Contact: \r\n");
xlog("L_INFO", “TEAMS Contact: $var(domain)\r\n");
route(TEAMS_SEND);
}
xlog("L_INFO", "Sent out tm request: $mb\n");
}

route[TEAMS_SEND] {
$var(domain) = $fd;
$xavp(tls=>server_name) = $var(domain);
$xavp(tls[0]=>server_id) = $var(domain);
$du = "sip:$var(domain):5061;transport=tls"; 
t_relay();
}


For testing, I also tried generating the packets in a normal route using 
t_uac_send and controlling it with rtimer.  As ugly a hack that this approach 
is, it did manage to create the packets and set the xavp as required (although, 
it certainly wouldn’t help dispatcher know if a gateway is offline…).  
Additional trouble is that if a second domain attempts to send OPTIONS packets 
in the while loop (see below) it goes out the same TLS connection, so it is 
rejected.

Config:

route["PING-TEAMS"] {
sql_query("db", "select domain from domain;", "domain_list");
$var(i) = 0;
while ($dbr(domain_list=>[$var(i),0]) != $null) {
$var(domain) = $dbr(domain_list=>[$var(i),0]);
xlog(“OPTIONS from domain name $var(domain)");
$xavp(tls=>server_name) = $var(domain);
$xavp(tls[0]=>server_id) = $var(domain);
$du = "sip:$var(domain):5061;transport=tls"; 
t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls", 
"sip:sip3.pstnhub.microsoft.com;transport=tls", "", "From: 
sip:$var(domain)\r\nTo: 
sip:sip3.pstnhub.microsoft.com;transport=tls\r\nContact: 
\r\n", "");
sleep(2);
t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls", 
"sip:sip2.pstnhub.microsoft.com;transport=tls", "", "From: 
sip:$var(domain)\r\nTo: 
sip:sip2.pstnhub.microsoft.com;transport=tls\r\nContact: 
\r\n", "");
sleep(2);
t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls", 
"sip:sip.pstnhub.microsoft.com;transport=tls", "", "From: 
sip:$var(domain)\r\nTo: sip:sip.pstnhub.microsoft.com;transport=tls\r\nContact: 
\r\n", "");
sleep(5);
$var(i) = $var(i) + 1; 
   
}
}

200 from MS on domain 0:

2021/01/11 08:48:31.291048 52.114.7.24:5061 -> *myip*:52606
SIP/2.0 200 OK
FROM: ;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
TO: 
CSEQ: 10 OPTIONS
CALL-ID: 0f37a09f409a4e41-24410@127.0.0.1
VIA: SIP/2.0/TLS 
*myip*:5061;branch=z9hG4bK9306.42d92227.0
CONTENT-LENGTH: 0
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0


403 from MS on domain 1:

2021/01/11 08:49:39.755005 52.114.7.24:5061 -> *myip*:52606
SIP/2.0 403 Forbidden
FROM: ;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
TO: 
CSEQ: 10 OPTIONS
CALL-ID: 0f37a09f409a4e44-24410@127.0.0.1
VIA: SIP/2.0/TLS 
*myip*:5061;branch=z9hG4bK4306.973e15620000.0
REASON: Q.850;cause=63;text="00cce062-66c6-45a4-8b5c-ccd48b71a9f6;Provided 
Trunk FQDN '101.sbc.*mydomain*.net' is not allowed. Connection allows
ollowing fqdns: 100.sbc.*mydomain*.net, 100.sbc.*mydomain*.net."
CONTENT-LENGTH: 0
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0



- Charles Phillips




> On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> the xavp_cfg set in the event_route is not propagated (kept) to the moment 
> when the message is sent out to tls. The event_route[tm:local-request] is 
> executed when the local request is constructed, terminated before sending 
> out, so whatever avp/xavp is set in the event route are deleted when the 
> block execution is terminated.
> 
> It requires another solution here, I am thinking about what can be done and 
> will be added soon in the master branch.
> 
> Meanwhile, a workaround is to look traffic back to kamailio so the routing 
> happens over request_route block, where you can set the xavp.
> 
> Cheers,
> Daniel
> 
> On 08.01.21 22:23, Charles Phillips wrote:
>> Thanks Daniel, I needed some certainty to get unstuck.  It appears that the 
>> problem is actually related to the TLS config.  I am using multiple TLS 
>> configs, so it looks

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

[Charles Phillips]

It is my understanding that for outbound connections, subsequent transactions 
to the same destination IP:port reuse an existing TLS socket (if one exists) by 
design.  By the logs, it appears that this matching takes place early in the 
processing so there is no regard for a new outbound transaction that has 
different SNI.  Is this correct? Is there a way to force a new outbound TLS 
connection for a new transaction based on some other identifier? 


- Charles Phillips




> On Jan 11, 2021, at 9:00 AM, Charles Phillips  wrote:
> 
> That is what I figured was happening.  I have tried sending it back to a 
> standard routing block, but perhaps I am doing it incorrectly.
> 
> When I try to send it back to a regular routing block I get the following 
> error:
> 
> CRITICAL: tm [tm.c:1754]: _w_t_relay_to(): unsupported route type: 64
> 
> Config:
> 
> event_route[tm:local-request] {
> sip_trace();
> if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com 
> <http://pstnhub.microsoft.com/>") {
> $var(domain) = $fd;
> append_hf("Contact:  >\r\n");
> xlog("L_INFO", “TEAMS Contact: $var(domain)\r\n");
> route(TEAMS_SEND);
> }
> xlog("L_INFO", "Sent out tm request: $mb\n");
> }
> 
> route[TEAMS_SEND] {
> $var(domain) = $fd;
> $xavp(tls=>server_name) = $var(domain);
> $xavp(tls[0]=>server_id) = $var(domain);
> $du = "sip:$var(domain):5061;transport=tls 
> "; 
> t_relay();
> }
> 
> 
> For testing, I also tried generating the packets in a normal route using 
> t_uac_send and controlling it with rtimer.  As ugly a hack that this approach 
> is, it did manage to create the packets and set the xavp as required 
> (although, it certainly wouldn’t help dispatcher know if a gateway is 
> offline…).  Additional trouble is that if a second domain attempts to send 
> OPTIONS packets in the while loop (see below) it goes out the same TLS 
> connection, so it is rejected.
> 
> Config:
> 
> route["PING-TEAMS"] {
> sql_query("db", "select domain from domain;", "domain_list");
> $var(i) = 0;
> while ($dbr(domain_list=>[$var(i),0]) != $null) {
> $var(domain) = $dbr(domain_list=>[$var(i),0]);
> xlog(“OPTIONS from domain name $var(domain)");
> $xavp(tls=>server_name) = $var(domain);
> $xavp(tls[0]=>server_id) = $var(domain);
> $du = "sip:$var(domain):5061;transport=tls 
> "; 
> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls 
> ", 
> "sip:sip3.pstnhub.microsoft.com;transport=tls 
> ", "", "From: sip:$var(domain) 
> \r\nTo: sip:sip3.pstnhub.microsoft.com;transport=tls 
> \r\nContact: 
>  >\r\n", "");
> sleep(2);
> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls 
> ", 
> "sip:sip2.pstnhub.microsoft.com;transport=tls 
> ", "", "From: sip:$var(domain) 
> \r\nTo: sip:sip2.pstnhub.microsoft.com;transport=tls 
> \r\nContact: 
>  >\r\n", "");
> sleep(2);
> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls 
> ", 
> "sip:sip.pstnhub.microsoft.com;transport=tls 
> ", "", "From: sip:$var(domain) 
> \r\nTo: sip:sip.pstnhub.microsoft.com;transport=tls 
> \r\nContact: 
>  >\r\n", "");
> sleep(5);
> $var(i) = $var(i) + 1; 
>
> }
> }
> 
> 200 from MS on domain 0:
> 
> 2021/01/11 08:48:31.291048 52.114.7.24:5061 -> *myip*:52606
> SIP/2.0 200 OK
> FROM:  >;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
> TO: >
> CSEQ: 10 OPTIONS
> CALL-ID: 0f37a09f409a4e41-24410@127.0.0.1 
> <mailto:0f37a09f409a4e41-24410@127.0.0.1>
> VIA: SIP/2.0/TLS 
> *myip*:5061;branch=z9hG4bK9306.42d92227.0
> CONTENT-LENGTH: 0
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
> 
> 
> 403 from MS on domain 1:
> 
> 2021/01/11 08:49:39.755005 52.114.7.24:5061 -> *myip*:52606
> SIP/2.0 403 Forbidden
> FROM:  >;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
> TO: >
> CSEQ: 10 OPTIONS
> CALL-ID: 0f37a09f409a4e44-24410@127.0.0.1 
> <mailto:0f37a09f409a4e44-24410@127.0.0.1>
> VIA: SIP/2.0/TLS 
> *myip*:5061;branch=z9hG4bK4306.973e1562.0
> REASON: Q.850;cause=63;text="00cce062-66c6-45a4-8b5c-ccd48b71a9f6;Provided 
> Trunk FQDN '101.sbc.*

[SR-Users] Dialog Tracking with Inconsistent RR

[Charles Phillips]

I am working to track concurrent channels with the dialog module, but I have 
run in to an issue.  Due to the nature of my required configuration, I have a 
need to strip the record route headers from packets that are sent to the 
upstream proxy.  This leaves no way for the dialog module to track the state of 
the call.  I was hoping that DID_FALLBACK or DID_NONE modes would track by call 
id or some other constant, but it does not appear to.  

So, before I start down the path of using htable to store and reinsert the did 
when a packet returns, is there something I am missing with dialog?  Is there 
some more efficient way to do this?


- Charles




___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dialog Tracking with Inconsistent RR

[Charles Phillips]

Thanks Daniel!

Ended up just using htable alone.  Since I do not need dialog for any other 
functionality, I took a tip from you (from a long time ago) and went the 
lightweight route. 

- Charles




> On Jan 20, 2021, at 1:37 PM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> if you do not have SIP signaling spirals, look at topos module, it may help 
> for what you need. It should work together with dialog module.
> 
> Cheers,
> Daniel
> 
> On Wed, Jan 20, 2021 at 6:16 PM Charles Phillips  <mailto:char...@rustybike.com>> wrote:
> I am working to track concurrent channels with the dialog module, but I have 
> run in to an issue.  Due to the nature of my required configuration, I have a 
> need to strip the record route headers from packets that are sent to the 
> upstream proxy.  This leaves no way for the dialog module to track the state 
> of the call.  I was hoping that DID_FALLBACK or DID_NONE modes would track by 
> call id or some other constant, but it does not appear to.  
> 
> So, before I start down the path of using htable to store and reinsert the 
> did when a packet returns, is there something I am missing with dialog?  Is 
> there some more efficient way to do this?
> 
> 
> - Charles
> 
> 
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
> 
> -- 
> Daniel-Constantin Mierla - https://www.asipto.com <https://www.asipto.com/>
> https://twitter.com/miconda <https://twitter.com/miconda> - 
> https://www.linkedin.com/in/miconda <https://www.linkedin.com/in/miconda>
> Kamailio Advanced Training - https://www.asipto.com/u/kat 
> <https://www.asipto.com/u/kat>___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Unregister with Multiple Contacts

[Charles Phillips]

Happy Friday!

To clean up contacts that have sent requests to unregister (Expires: 0) I am 
executing the following after a 200 OK response from the upstream server:

reg_fetch_contacts("location", "$fu", "un_reg");
xlog("L_INFO", "Removing unregistered contact From: $si To: $tu Ruid: 
$ulc(un_reg=>ruid)\n");
unregister("location", "$fu", "$ulc(un_reg=>ruid)”);

This produces the desired result when there is only one contact per AoR, but 
when multiple contacts are present, it seems to delete the first ruid (which 
makes sense as I am only providing the $fu).  

So, the question, can I select the contact by call-id or some other unique 
identifier specific to the desired contact that I can grab from the 
transaction?  Reading the reg_fetch_contact and unregister docs, they do not 
seem to provide for selection beyond uri.


- Charles




___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Unregister with Multiple Contacts

[Charles Phillips]

Sorted it.  I needed to loop through the contacts, then select the correct ruid 
based on $ci

For completeness, here is my solution:

reg_fetch_contacts("location", "$fu", "un_reg");
$var(i) = 0;
while ($var(i) < $(ulc(un_reg=>count))) {
$var(ul_callid) = $(ulc(un_reg=>callid)[$var(i)]);
$var(ul_ruid) = $(ulc(un_reg=>ruid)[$var(i)]);
if ($var(ul_callid) == $ci) {
xlog("L_INFO", "Unregistering contact $tu Ruid: $var(ul_ruid)\n");
unregister("location", "$fu", "$var(ul_ruid)");
$sht(regs=>$fU@$fd~$ci)=$null;
    }
    $var(i) = $var(i) + 1;
} 

- Charles 




> On Feb 19, 2021, at 9:43 AM, Charles Phillips  wrote:
> 
> Happy Friday!
> 
> To clean up contacts that have sent requests to unregister (Expires: 0) I am 
> executing the following after a 200 OK response from the upstream server:
> 
> reg_fetch_contacts("location", "$fu", "un_reg");
> xlog("L_INFO", "Removing unregistered contact From: $si To: $tu Ruid: 
> $ulc(un_reg=>ruid)\n");
> unregister("location", "$fu", "$ulc(un_reg=>ruid)”);
> 
> This produces the desired result when there is only one contact per AoR, but 
> when multiple contacts are present, it seems to delete the first ruid (which 
> makes sense as I am only providing the $fu).  
> 
> So, the question, can I select the contact by call-id or some other unique 
> identifier specific to the desired contact that I can grab from the 
> transaction?  Reading the reg_fetch_contact and unregister docs, they do not 
> seem to provide for selection beyond uri.
> 
> 
> - Charles
> 
> 
> 
> 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Unregister with Multiple Contacts

[Charles Phillips]

With the below, we loop through all of the contacts that match $fu, but only 
unregister the one matching the $ci of the 200 OK that is associated with the 
unregister (Expires: 0) request from the upstream server. 

It actually has 3 parts.  For completeness, I probably should have added them 
all.  Below:


route[REGISTRAR] {

….
do stuff
….

if (search_hf("Expires", "^0$", "a")) {

….
do stuff
….

t_on_reply("UNREGISTER");
xlog("L_INFO", "Processing unregister event from $si To: 
$tu\n");
route(RELAY);
exit;
}
….
do stuff
….

}


onreply_route[UNREGISTER] {
if (t_check_status("200")) {
route(UNREG);
}
}


route[UNREG] {
reg_fetch_contacts("location", "$fu", "un_reg");
$var(i) = 0;
while ($var(i) < $(ulc(un_reg=>count))) {
$var(ul_callid) = $(ulc(un_reg=>callid)[$var(i)]);
$var(ul_ruid) = $(ulc(un_reg=>ruid)[$var(i)]);
if ($var(ul_callid) == $ci) {
xlog("L_INFO", "Unregistering contact $tu Ruid: $var(ul_ruid)\n");
unregister("location", "$fu", "$var(ul_ruid)");
$sht(regs=>$fU@$fd~$ci)=$null;
}
$var(i) = $var(i) + 1;
}
}

- Charles




> On Feb 21, 2021, at 8:45 AM, David Villasmil  
> wrote:
> 
> Beware that since you’re removing all contacts, if any are valid and if any 
> of the contacts that did not unregister is called, Kamailio won’t find them.
> 
> If what you need is not force only one contact per user, maybe look at 
> http://www.kamailio.net/docs/modules/5.4.x/modules/registrar.html#registrar.f.save
>  
> <http://www.kamailio.net/docs/modules/5.4.x/modules/registrar.html#registrar.f.save>
> 
> On Sun, 21 Feb 2021 at 13:14, Charles Phillips  <mailto:char...@rustybike.com>> wrote:
> Sorted it.  I needed to loop through the contacts, then select the correct 
> ruid based on $ci
> 
> For completeness, here is my solution:
> 
> reg_fetch_contacts("location", "$fu", "un_reg");
> $var(i) = 0;
> while ($var(i) < $(ulc(un_reg=>count))) {
> $var(ul_callid) = $(ulc(un_reg=>callid)[$var(i)]);
> $var(ul_ruid) = $(ulc(un_reg=>ruid)[$var(i)]);
> if ($var(ul_callid) == $ci) {
>     xlog("L_INFO", "Unregistering contact $tu Ruid: $var(ul_ruid)\n");
> unregister("location", "$fu", "$var(ul_ruid)");
> $sht(regs=>$fU@$fd~$ci)=$null;
> }
> $var(i) = $var(i) + 1;
> } 
> 
> 
> - Charles 
> 
> 
> 
> 
>> On Feb 19, 2021, at 9:43 AM, Charles Phillips > <mailto:char...@rustybike.com>> wrote:
>> 
>> Happy Friday!
>> 
>> To clean up contacts that have sent requests to unregister (Expires: 0) I am 
>> executing the following after a 200 OK response from the upstream server:
>> 
>> reg_fetch_contacts("location", "$fu", "un_reg");
>> xlog("L_INFO", "Removing unregistered contact From: $si To: $tu Ruid: 
>> $ulc(un_reg=>ruid)\n");
>> unregister("location", "$fu", "$ulc(un_reg=>ruid)”);
>> 
>> This produces the desired result when there is only one contact per AoR, but 
>> when multiple contacts are present, it seems to delete the first ruid (which 
>> makes sense as I am only providing the $fu).  
>> 
>> So, the question, can I select the contact by call-id or some other unique 
>> identifier specific to the desired contact that I can grab from the 
>> transaction?  Reading the reg_fetch_contact and unregister docs, they do not 
>> seem to provide for selection beyond uri.
>> 
>> 
>> - Charles
>> 
>> 
>> 
>> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Regards,
> 
> David Villasmil
> email: david.villasmil.w...@gmail.com <mailto:david.villasmil.w...@gmail.com>
> phone: +34669448337
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] UAC changing port for same registration

[Charles Phillips]

If using TCP or TLS, you can use Tcpconn-Id in usrloc with the tcpops module 
find stale connections.

- Charles




> On Mar 2, 2021, at 11:19 AM, Sergiu Pojoga  wrote:
> 
> Are you supporting a single Contact per AoR? Otherwise, I don't see how you 
> can keep track of "changes in location and detect if an agent is online".
> 
> If so, just set the 0x04 registrar flag and you'll always have the latest 
> registered Contact address in Location.
> 
> https://kamailio.org/docs/modules/devel/modules/registrar.html#registrar.f.save
>  
> 
> 
> Regards,
> --Sergiu
> 
> On Tue, Mar 2, 2021 at 8:26 AM Michal Popovic  > wrote:
> Hello everybody,
> 
> let's have a situation where UAC is behind the NAT and router suddenly change 
> the external port.
> 
> Kamailio in this case creates two location entries one with old port and one 
> with the new one.
> 
> Now UAC unregister from the new one and old location remains active until it 
> expires and our support system that is listening to locations changes keep 
> the agent online for other services.
> 
> Is there any way besides the regular OPTIONS ping from UAS to UAC how to 
> solve this issue?
> 
> Thanks.
> Michal
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users