[SR-Users] NAT pinging after service restart

[Jacob Greene]

Hello everyone!

When I restart the Kamailio service, NAT pinging for all existing
location records stops and does not start until the UA registers again. I'm
using db_mode 2, and all of the registrations will be there, but for some
reason Kamailio wont restart the pinging cycle. Is it possible to configure
Kamailio to restart NAT pinging in the event of a service restart?

Thanks for reading!

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

Re: [SR-Users] Kamailio like SBC with Teams

[Sergiu Pojoga]

Suggest reading Fred's article about configuring Kamailio with Letsencrypt

https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/

On Fri, Apr 17, 2020 at 3:00 AM sip user  wrote:

> Hi Sergiu..
>
> I've made many test and many change...
>
> In tls.cfg I have this:
>
> [server:default]
> method = TLSv1.2
> verify_certificate = yes
> require_certificate = yes
> private_key = /etc/letsencrypt/ssl/cert.key
> certificate = /etc/letsencrypt/ssl/cert.crt
> ca_list = /etc/letsencrypt/ssl/ca.crt
>
> [client:default]
> method = TLSv1.2
> verify_certificate = yes
> require_certificate = yes
> private_key = /etc/letsencrypt/ssl/cert.key
> certificate = /etc/letsencrypt/ssl/cert.crt
> ca_list = /etc/letsencrypt/ssl/ca.crt
>
> But when I make Kamcmd tls.list I have not response.. Not show me anything.
>
> Problem with certificated??
>
> Thanks
>
> El jue., 16 abr. 2020 a las 20:31, Sergiu Pojoga ()
> escribió:
>
>> Hi SIP User/anonymous/one-time-visitor/,
>>
>> Your TLS config isn't correct. The article clearly says
>> verify/require_certificate must be set to 'yes'
>>
>> *kamcmd tls.list*
>> Does it show any 'established' connections with MS proxy?
>>
>> Good luck,
>>
>> --Sergiu
>>
>> On Thu, Apr 16, 2020 at 11:41 AM Ovidiu Sas 
>> wrote:
>>
>>> The tutorial is pretty clear:
>>> You need to add the Contact header only for OPTIONS pings.
>>> You need to use the proper Record-Route headers based on the direction
>>> of the call.
>>> There's no out of the box solution because each setup is different.
>>>
>>> If you understand how loose routing works in SIP, then you know how to
>>> adjust the config to use record_route_preset(), just as explained in
>>> the tutorial. There is also an example of an INVITE that has the right
>>> Record-Route headers in the tutorial.
>>>
>>> You can choose to use the FQDN for the Record-Route header facing MS
>>> and the IP for the Record-Route header facing the carrier or use the
>>> FQDN for both Record-Route headers (just like in the tutorialexample).
>>> Alternatively, one can try to advertise the FQDN in the listen
>>> directive in the config and then the Record-Route headers should be
>>> populated automatically.
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> On Thu, Apr 16, 2020 at 10:50 AM sip user  wrote:
>>> >
>>> > Hi Nasida.. Thanks for answerd to me...
>>> >
>>> > I've activarted the debugger module, and I see the same:
>>> >
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 52.114.7.24
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 4160, type 3
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 171:1857:1187, 30
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa1f240, 23, 2,
>>> 0x7f90f2438f80), fd_no=17
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa1f240, 23, -1, 0x0)
>>> fd_no=18 called
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 1
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>>> [tcp_main.c:3902]: send2child(): selected tcp worker 1 10(23159) for
>>> activity on [tls:SBC_IP:5061], 0x7f90f2438f80
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [tcp_read.c:1507]: handle_io(): received n=8 con=0x7f90f2438f80, fd=9
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls
>>> [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSs
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls
>>> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c=
>>> 0x7f90f2438f80 n=1468 fd=9
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: #026#003#003
>>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9c1700, 9, 2,
>>> 0x7f90f2438f80), fd_no=1
>>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [tcp_read.c:296]: tcp_read_data(): EOF on 0x7f90f2438f80, FD 9
>>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [tcp_read.c:1291]: tcp_read_req(): tcp_read_req: EOF
>>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>>> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9c1700, 9, -1, 0x10)
>>> fd_no=2 called

Re: [SR-Users] TCP/TLS connection (id: 0) for WebSocket could not be found

[Daniel-Constantin Mierla]

That's quite strange, the registrar/usrloc are not related to websocket
in storing the connection id, they see it as a tcp/tls connection. I
checked on a test server and all tcp/tls contacts have connection id and
socket field set.

Do you get any error messages when processing the REGISTER?

If not, give here the parameters you set for registrar and usrloc
modules along with all debug messages with debug-3 in cfg when
processing the REGISTER (just replace any sensitive data).

Cheers,
Daniel

On 17.04.20 14:34, Mack Hendricks wrote:
> Here is what one of my registrations look like
>
>               id: 148
>          ruid: uloc-5e999161-1782-1
>      username: 2000
>        domain: ws-test.com 
>       contact: sips:2000@df7jal23ls0d.invalid
> ;rtcweb-breaker=no;transport=wss
>      received: sip:98.209.240.245:63356;transport=ws
>          path: NULL
>       expires: 2020-04-17 12:30:14
>             q: -1.00
>        callid: 73beb50f-65de-a461-be26-187c9aaa53c1
>          cseq: 48179
> last_modified: 2020-04-17 12:26:54
>         flags: 0
>        cflags: 524352
>    user_agent: IM-client/OMA1.0 sipML5-v1.2016.03.04
>     *   socket: NULL*
>       methods: NULL
>      instance: NULL
>        reg_id: 0
>     server_id: 0
> *connection_id: -1*
>     keepalive: 1
>     partition: 18
>
>> On Apr 17, 2020, at 8:30 AM, Mack Hendricks > > wrote:
>>
>> Hello,
>>
>> I upgrade to 5.3 and got the same result.  But, I noticed that
>> changing the connection_id in the database to the connection_id of
>> the web socket  connection listed by ws.dump made it work.
>>
>> So, it looks like the socket or the connection_id is not being set
>> when the record is stored by usrloc.  I think this is the true issue.
>>  Any suggestions where to look?
>>
>>
>>
>>> On Apr 16, 2020, at 2:44 AM, Daniel-Constantin Mierla
>>> mailto:mico...@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>> did you print the log message just before t_relay()?
>>>
>>> Can you also print the tcp and tls connections via rpc? I am not
>>> sure if the websocket keeps a separate list of connections, but
>>> tcp/tls should have the lists used for routing.
>>>
>>> It would be better to upgrade to 5.3, because 5.1 is out of
>>> maintenance and if there is still an issue, it is easier to
>>> troubleshoot and fix. Then you can backport locally to 5.1, if you
>>> have to run that version on specific systems.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 16.04.20 05:10, Mack Hendricks wrote:
 Hey Daniel,

 It returns:

  [LOCATION] ru: sips:2000@df7jal23ls0d.invalid
 ;rtcweb-breaker=no;transport=wss,
 *nh(u): sip:98.209.240.245:50453;transport=ws*
 *
 *
 This matches the output from

 kamcmd ws.dump


 connections: {
 29: wss:*98.209.240.245:50453* -> wss:134.122.27.49:4443 (state:
 OPEN,  last used 22s ago, sub-protocol: sip)
 }
 info: {
 wscounter: 1
 truncated: no
 }
 }

 I can grade to 5.3 if you think that’s best.


 *
 *

> On Apr 15, 2020, at 12:11 PM, Daniel-Constantin Mierla
> mailto:mico...@gmail.com>> wrote:
>
> Hello,
>
> when id is 0, then the search of the connection is done by target
> address. For some reason, the destination is not matching the
> connection. Try to print $nh(u) before relaying to see where it is
> supposed to be sent.
>
> Cheers,
> Daniel
>
> On 15.04.20 16:54, Mack Hendricks wrote:
>> Hello,
>>
>> I’m running kamailio 5.1.10 (x86_64/linux)
>>
>> The connection_id in usrloc is -1 for some reason so the id
>> doesn’t match for sure.  But, I thought that it would match on
>> the received address of the WS client because the output from
>> ws.dump shows that the connection address and port matches the
>> received address and port in usrloc.
>>
>> Any suggestions?
>>
>>
>>
>>
>>> On Apr 15, 2020, at 10:48 AM, Daniel-Constantin Mierla
>>> mailto:mico...@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>> what version of Kamailio do you use?
>>>
>>> That message is printed when the connection is not found by id
>>> or by destination address.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 15.04.20 07:11, Mack Hendricks wrote:
 Hey All,



 I get this message when trying to route request to a WebSocket
 client:


 Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]:
 DEBUG:  [core/msg_translator.c:1762]: check_boundaries():
 no multi-part body
 Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]:
 DEBUG:  [core/msg_translator.c:429]: clen_builder():
 content-length: 651 (651)
 Apr 15 04:59:37 dSIP060entNightly-0 

Re: [SR-Users] TCP/TLS connection (id: 0) for WebSocket could not be found

[Mack Hendricks]

Here is what one of my registrations look like

  id: 148
 ruid: uloc-5e999161-1782-1
 username: 2000
   domain: ws-test.com
  contact: sips:2000@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=wss
 received: sip:98.209.240.245:63356;transport=ws
 path: NULL
  expires: 2020-04-17 12:30:14
q: -1.00
   callid: 73beb50f-65de-a461-be26-187c9aaa53c1
 cseq: 48179
last_modified: 2020-04-17 12:26:54
flags: 0
   cflags: 524352
   user_agent: IM-client/OMA1.0 sipML5-v1.2016.03.04
   socket: NULL
  methods: NULL
 instance: NULL
   reg_id: 0
server_id: 0
connection_id: -1
keepalive: 1
partition: 18

> On Apr 17, 2020, at 8:30 AM, Mack Hendricks  wrote:
> 
> Hello,
> 
> I upgrade to 5.3 and got the same result.  But, I noticed that changing the 
> connection_id in the database to the connection_id of the web socket  
> connection listed by ws.dump made it work.
> 
> So, it looks like the socket or the connection_id is not being set when the 
> record is stored by usrloc.  I think this is the true issue.  Any suggestions 
> where to look?
> 
> 
> 
>> On Apr 16, 2020, at 2:44 AM, Daniel-Constantin Mierla > > wrote:
>> 
>> Hello,
>> 
>> did you print the log message just before t_relay()?
>> 
>> Can you also print the tcp and tls connections via rpc? I am not sure if the 
>> websocket keeps a separate list of connections, but tcp/tls should have the 
>> lists used for routing.
>> 
>> It would be better to upgrade to 5.3, because 5.1 is out of maintenance and 
>> if there is still an issue, it is easier to troubleshoot and fix. Then you 
>> can backport locally to 5.1, if you have to run that version on specific 
>> systems.
>> 
>> Cheers,
>> Daniel
>> 
>> On 16.04.20 05:10, Mack Hendricks wrote:
>>> Hey Daniel,
>>> 
>>> It returns:
>>> 
>>>  [LOCATION] ru: sips:2000@df7jal23ls0d.invalid 
>>> ;rtcweb-breaker=no;transport=wss, nh(u): 
>>> sip:98.209.240.245:50453;transport=ws 
>>> 
>>> 
>>> This matches the output from
>>> 
>>> kamcmd ws.dump
>>> 
>>> 
>>> connections: {
>>> 29: wss:98.209.240.245:50453 -> wss:134.122.27.49:4443 
>>>  (state: OPEN,  last used 22s ago, sub-protocol: 
>>> sip)
>>> }
>>> info: {
>>> wscounter: 1
>>> truncated: no
>>> }
>>> }
>>> 
>>> I can grade to 5.3 if you think that’s best.
>>> 
>>> 
>>> 
>>> 
 On Apr 15, 2020, at 12:11 PM, Daniel-Constantin Mierla >>> > wrote:
 
 Hello,
 
 when id is 0, then the search of the connection is done by target address. 
 For some reason, the destination is not matching the connection. Try to 
 print $nh(u) before relaying to see where it is supposed to be sent.
 
 Cheers,
 Daniel
 
 On 15.04.20 16:54, Mack Hendricks wrote:
> Hello,
> 
> I’m running kamailio 5.1.10 (x86_64/linux)
> 
> The connection_id in usrloc is -1 for some reason so the id doesn’t match 
> for sure.  But, I thought that it would match on the received address of 
> the WS client because the output from ws.dump shows that the connection 
> address and port matches the received address and port in usrloc.
> 
> Any suggestions?
> 
> 
> 
> 
>> On Apr 15, 2020, at 10:48 AM, Daniel-Constantin Mierla 
>> mailto:mico...@gmail.com>> wrote:
>> 
>> Hello,
>> 
>> what version of Kamailio do you use?
>> 
>> That message is printed when the connection is not found by id or by 
>> destination address.
>> 
>> Cheers,
>> Daniel
>> 
>> On 15.04.20 07:11, Mack Hendricks wrote:
>>> Hey All,
>>> 
>>> 
>>> 
>>> I get this message when trying to route request to a WebSocket client:
>>> 
>>> 
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: 
>>>  [core/msg_translator.c:1762]: check_boundaries(): no multi-part 
>>> body
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: 
>>>  [core/msg_translator.c:429]: clen_builder(): content-length: 651 
>>> (651)
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: WARNING: 
>>>  [core/msg_translator.c:2786]: via_builder(): TCP/TLS connection 
>>> (id: 0) for WebSocket could not be found
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: 
>>>  [core/msg_translator.c:2002]: build_req_buf_from_sip_req(): 
>>> could not create Via header
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: 
>>> tm [t_fwd.c:476]: prepare_new_uac(): could not build request
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: 
>>> tm [t_fwd.c:1738]: t_forward_nonack(): failure to add branches
>>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: 
>>> tm 

Re: [SR-Users] TCP/TLS connection (id: 0) for WebSocket could not be found

[Mack Hendricks]

Hello,

I upgrade to 5.3 and got the same result.  But, I noticed that changing the 
connection_id in the database to the connection_id of the web socket  
connection listed by ws.dump made it work.

So, it looks like the socket or the connection_id is not being set when the 
record is stored by usrloc.  I think this is the true issue.  Any suggestions 
where to look?



> On Apr 16, 2020, at 2:44 AM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> did you print the log message just before t_relay()?
> 
> Can you also print the tcp and tls connections via rpc? I am not sure if the 
> websocket keeps a separate list of connections, but tcp/tls should have the 
> lists used for routing.
> 
> It would be better to upgrade to 5.3, because 5.1 is out of maintenance and 
> if there is still an issue, it is easier to troubleshoot and fix. Then you 
> can backport locally to 5.1, if you have to run that version on specific 
> systems.
> 
> Cheers,
> Daniel
> 
> On 16.04.20 05:10, Mack Hendricks wrote:
>> Hey Daniel,
>> 
>> It returns:
>> 
>>  [LOCATION] ru: sips:2000@df7jal23ls0d.invalid 
>> ;rtcweb-breaker=no;transport=wss, nh(u): 
>> sip:98.209.240.245:50453;transport=ws 
>> 
>> This matches the output from
>> 
>> kamcmd ws.dump
>> 
>> 
>>  connections: {
>>  29: wss:98.209.240.245:50453 -> wss:134.122.27.49:4443 
>>  (state: OPEN,  last used 22s ago, sub-protocol: 
>> sip)
>>  }
>>  info: {
>>  wscounter: 1
>>  truncated: no
>>  }
>> }
>> 
>> I can grade to 5.3 if you think that’s best.
>> 
>> 
>> 
>> 
>>> On Apr 15, 2020, at 12:11 PM, Daniel-Constantin Mierla >> > wrote:
>>> 
>>> Hello,
>>> 
>>> when id is 0, then the search of the connection is done by target address. 
>>> For some reason, the destination is not matching the connection. Try to 
>>> print $nh(u) before relaying to see where it is supposed to be sent.
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> On 15.04.20 16:54, Mack Hendricks wrote:
 Hello,
 
 I’m running kamailio 5.1.10 (x86_64/linux)
 
 The connection_id in usrloc is -1 for some reason so the id doesn’t match 
 for sure.  But, I thought that it would match on the received address of 
 the WS client because the output from ws.dump shows that the connection 
 address and port matches the received address and port in usrloc.
 
 Any suggestions?
 
 
 
 
> On Apr 15, 2020, at 10:48 AM, Daniel-Constantin Mierla  > wrote:
> 
> Hello,
> 
> what version of Kamailio do you use?
> 
> That message is printed when the connection is not found by id or by 
> destination address.
> 
> Cheers,
> Daniel
> 
> On 15.04.20 07:11, Mack Hendricks wrote:
>> Hey All,
>> 
>> 
>> 
>> I get this message when trying to route request to a WebSocket client:
>> 
>> 
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: 
>>  [core/msg_translator.c:1762]: check_boundaries(): no multi-part 
>> body
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: 
>>  [core/msg_translator.c:429]: clen_builder(): content-length: 651 
>> (651)
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: WARNING: 
>>  [core/msg_translator.c:2786]: via_builder(): TCP/TLS connection 
>> (id: 0) for WebSocket could not be found
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: 
>>  [core/msg_translator.c:2002]: build_req_buf_from_sip_req(): could 
>> not create Via header
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: tm 
>> [t_fwd.c:476]: prepare_new_uac(): could not build request
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: tm 
>> [t_fwd.c:1738]: t_forward_nonack(): failure to add branches
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: tm 
>> [t_funcs.c:337]: t_relay_to(): t_forward_nonack returned error -2 (-2)
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: DEBUG: tm 
>> [t_funcs.c:355]: t_relay_to(): -2 error reply generation delayed
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: exec: *** 
>> cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio.cfg] l=1176 
>> a=24 n=sl_reply_error
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: ERROR: sl 
>> [sl_funcs.c:362]: sl_reply_error(): stateless error reply used: No error 
>> (2/SL)
>> Apr 15 04:59:37 dSIP060entNightly-0 /usr/sbin/kamailio[22071]: exec: *** 
>> cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio.cfg] l=1178 a=2 
>> n=exit
>> 
>> 
>> 
>> Here is what my location table looks like.  It should try to send the 
>> call to  sip:98.209.240.245:56291;transport=ws 
>> 

[SR-Users] Kamailio in osm

[Pavithra M]

Hi,
Do anybody have worked orchestrating kamailio as an IMS server through osm
by launching vnfs in openstack . If so kindly reply me as I need some
inputs on that.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dealing with mobile client state while using Push Notification and TSILO

[Federico Cabiddu]

Hi,
it's hard to track the actual state of the client in mobile scenarios. You
can achieve a better precision if you use tcp (tls) and
Kamailio's tcpops functionalities to track socket status and trigger
deletion of the usrloc entry, but even this is not 100% reliable. The
simplest solution, imho, is to relay the INVITE to the contacts you have in
your usrloc table AND send the push notification request as well. As you
said, if the client is already registered the push won't trigger a new
registration but the client will receive the INVITE on the "straight" path.
On the other hand ,if it is not the push will trigger a REGISTER and the
first branch you sent out will either be cancelled if the new branch
triggered by registration is answered, either it will timeout as in a
normal scenario.
Hope this helps.

Cheers,

Federico

On Fri, Apr 17, 2020 at 8:46 AM Hubert Odziemczyk 
wrote:

> Hello!
>
> We are trying to setup a call-flow with TSILO and Push Notifications for
> solution with a mobile SIP client (Linphone), based on presentation by 
> Federico
> Cabiddu (http://www.kamailio.org/events/2015-KamailioWorld/Day2/20-
> Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf).
>
> We have an issue with "managing" state of the client (active or not) when
> there is a call coming. To be more specific, lookup in location table
> doesn't always give a proper answer, as contact expiration is different
> from actual lifetime of the app (which also differs between iOS and
> Android).
> One of proposed solutions is setting Expires=1 for REGISTER and then
> always rely on Push Notifications, but this scenario seems to be unreliable
> with some clients that are in foreground, as Push Notification doesn't
> trigger REGISTER again.
>
> Question is: did you perceive similar problems? What are your solutions to
> deal with them?
>
> Thank you in advance!
>
> Best regards,
> Hubert
> ___
> 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] Kamailio like SBC with Teams

[sip user]

Hi Sergiu..

I've made many test and many change...

In tls.cfg I have this:

[server:default]
method = TLSv1.2
verify_certificate = yes
require_certificate = yes
private_key = /etc/letsencrypt/ssl/cert.key
certificate = /etc/letsencrypt/ssl/cert.crt
ca_list = /etc/letsencrypt/ssl/ca.crt

[client:default]
method = TLSv1.2
verify_certificate = yes
require_certificate = yes
private_key = /etc/letsencrypt/ssl/cert.key
certificate = /etc/letsencrypt/ssl/cert.crt
ca_list = /etc/letsencrypt/ssl/ca.crt

But when I make Kamcmd tls.list I have not response.. Not show me anything.

Problem with certificated??

Thanks

El jue., 16 abr. 2020 a las 20:31, Sergiu Pojoga ()
escribió:

> Hi SIP User/anonymous/one-time-visitor/,
>
> Your TLS config isn't correct. The article clearly says
> verify/require_certificate must be set to 'yes'
>
> *kamcmd tls.list*
> Does it show any 'established' connections with MS proxy?
>
> Good luck,
>
> --Sergiu
>
> On Thu, Apr 16, 2020 at 11:41 AM Ovidiu Sas  wrote:
>
>> The tutorial is pretty clear:
>> You need to add the Contact header only for OPTIONS pings.
>> You need to use the proper Record-Route headers based on the direction
>> of the call.
>> There's no out of the box solution because each setup is different.
>>
>> If you understand how loose routing works in SIP, then you know how to
>> adjust the config to use record_route_preset(), just as explained in
>> the tutorial. There is also an example of an INVITE that has the right
>> Record-Route headers in the tutorial.
>>
>> You can choose to use the FQDN for the Record-Route header facing MS
>> and the IP for the Record-Route header facing the carrier or use the
>> FQDN for both Record-Route headers (just like in the tutorialexample).
>> Alternatively, one can try to advertise the FQDN in the listen
>> directive in the config and then the Record-Route headers should be
>> populated automatically.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Thu, Apr 16, 2020 at 10:50 AM sip user  wrote:
>> >
>> > Hi Nasida.. Thanks for answerd to me...
>> >
>> > I've activarted the debugger module, and I see the same:
>> >
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 52.114.7.24
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 4160, type 3
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 171:1857:1187, 30
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa1f240, 23, 2,
>> 0x7f90f2438f80), fd_no=17
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa1f240, 23, -1, 0x0)
>> fd_no=18 called
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 1
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
>> [tcp_main.c:3902]: send2child(): selected tcp worker 1 10(23159) for
>> activity on [tls:SBC_IP:5061], 0x7f90f2438f80
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_read.c:1507]: handle_io(): received n=8 con=0x7f90f2438f80, fd=9
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls
>> [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSs
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls
>> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c=
>> 0x7f90f2438f80 n=1468 fd=9
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: #026#003#003
>> > Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9c1700, 9, 2,
>> 0x7f90f2438f80), fd_no=1
>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_read.c:296]: tcp_read_data(): EOF on 0x7f90f2438f80, FD 9
>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_read.c:1291]: tcp_read_req(): tcp_read_req: EOF
>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9c1700, 9, -1, 0x10)
>> fd_no=2 called
>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_read.c:1434]: release_tcpconn(): releasing con 0x7f90f2438f80, state
>> -1, fd=9, id=30
>> > Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
>> [tcp_read.c:1435]: release_tcpconn():  extra_data 0x7f90f2432b40
>> > Apr 15 11:11:42 vps793907 

Re: [SR-Users] kamailio integration with MS teams.

[Yuriy Nasida]

Thanks for the answer Sergiu, Ovidiu

I don't know your setup but I use kamailio as load balancer with FS nodes
(instead of kamailio's media proxy).
That is why I have FS node IP in the contact header of 200 OK
message which go to MS teams (it's outbound call from MS to kam).
Like we all know MS doesn't like IP address at all (in contact and
record-route). Thus I have to replace (at kamailio) FS node IP to fqdn of
trunk I use with MS.
Also I had to comment record_route() for invites from MS.
You mentioned that I should not change contact header but... really MS
ignore my 200 OK for all other cases.
Also you mentioned that you have record route header in 200 OK, but again -
MS do not ignore 200 OK only in case I have only one record route header
which was in initial INVITE from MS.
You said it is working for you. Not sure why really. May be you use
kamalio rtpproxy and that is why have correct contact at once.
As for record route header - I have no ideas why MS doesn't ignore several
record route headter in 200 OK for your case.

With my changes i got ACK from MS. And also got voice call but obviously it
is dopped in ~30 sec because kamialio do not know destination for ACK from
MS (it has kamailio FQDN in URI)

Normally with my setup, 200 OK keeps ip address of FS node and MS should
send ACK to kamilio IP but with FS IP address in URI. We all know that MS
do not respect RFC and can not do so. They just said in docs  (we do not
support sip proxy).

So... Now I should to think how re-direct such ACK to FS node. Should be
possible to all this begin to be more and more complicated.

Any advice are welcome!


On Wed, 15 Apr 2020 at 05:39, Sergiu Pojoga  wrote:

> Also, you might want to check out this discussion from just a few days ago
> with a fellow comrade about a similar MS Teams problem:
>
> https://lists.kamailio.org/pipermail/sr-users/2020-April/108868.html
>
> On Tue, Apr 14, 2020 at 4:23 PM Sergiu Pojoga  wrote:
>
>> Well... most likely you didn't fix it, at least not properly. There's no
>> such requirement to have a single RR in the 200 OK, especially only the one
>> from the sender's original invite.
>> By this logic, Kamailio can't insert it's own RR to keep itself in the
>> call's path. I can assure you that's not the case in reality.
>>
>> On Tue, Apr 14, 2020 at 3:12 PM Nasida Yuriy  wrote:
>>
>>> Yes, sure, need to fix Record-Route. The question was how exactly :)
>>> Well.  I just fixed it by the way. 200 OK had to have only one
>>> record-route (which MS sent in initial invite). Otherwise MS ignore it
>>> without any response.
>>>
>>>
>>>
>>> --
>>> *От:* sr-users  от имени Ovidiu
>>> Sas 
>>> *Отправлено:* 14 апреля 2020 г. 20:32
>>> *Кому:* Kamailio (SER) - Users Mailing List >> >
>>> *Тема:* Re: [SR-Users] kamailio integration with MS teams.
>>>
>>> The instructions are pretty clear in the sense that you need to fix
>>> the Record-Route header.
>>> You don't need to touch the Contact header for in-dialog
>>> requests/replies.
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>>
>>> On Tue, Apr 14, 2020 at 12:19 PM Nasida Yuriy  wrote:
>>> >
>>> > Hi guys,
>>> >
>>> >
>>> > Do you have some expirience with kamailio integration with MS teams ?
>>> >
>>> >
>>> > I follow the instructon from here
>>> > https://skalatan.de/en/blog/kamailio-sbc-teams
>>> >
>>> > TLS part is configured correctly. I also got OPTIONS pings working
>>> between MS teams and kamailio by following of  this instruction. That is
>>> very good.
>>> >
>>> >  But... There is issues with outbound calls from MS teams to kamailo.
>>> >
>>> >
>>> > MS side send INVITE, kamailio responds with 180 and 200 OK, but looks
>>> like MS ignores us. I know that I probably should use record_route_preset
>>> function here to modify Record-Route headers to satisfy MS wishes.
>>> >
>>> > But nothing helps. I also tried to modify contact header in 200 OK
>>> like it was done for OPTIONS - no luck.
>>> >
>>> > Anyone has a working example of kamailio files for MS team ?
>>> > Or at least sucessful pcap with them.
>>> >
>>> > I can be wrong but looks like MS doesn't respect RFC at all.
>>> >
>>> >
>>> > Thanks.
>>> >
>>> >
>>> >
>>> >
>>> > Regards,
>>> > Team lead
>>> >
>>> > ___
>>> > Kamailio (SER) - Users Mailing List
>>> > sr-users@lists.kamailio.org
>>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> ___
>>> 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
> 

Re: [SR-Users] Kamailio like SBC with Teams

[Yuriy Nasida]

Wow, so many people want to configure kamailio with MS. First of all i
think you need to get sip debug  between kamailio and MS. Kamilio has
module to save sip traces. This way you will get sip debug decrypted.

On Thu, 16 Apr 2020 at 10:26, sip user  wrote:

> Hello good morning ... I am new to this list and I was starting to mess
> with Kamailio, mainly to set it up as SBC against Teams, in this case.
>
> But I can't get it to work for me. If I launch a call from the Teams, in
> the Kamailio I see:
>
> 1.- In syslog:
>
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 52.114.7.24
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 4160, type 3
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 171:1857:1187, 30
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa1f240, 23, 2,
> 0x7f90f2438f80), fd_no=17
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa1f240, 23, -1, 0x0)
> fd_no=18 called
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 1
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [tcp_main.c:3902]: send2child(): selected tcp worker 1 10(23159) for
> activity on [tls:SBC_IP:5061], 0x7f90f2438f80
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_read.c:1507]: handle_io(): received n=8 con=0x7f90f2438f80, fd=9
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls
> [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSs
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls
> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c=
> 0x7f90f2438f80 n=1468 fd=9
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=
> Apr 15 11:11:41 vps793907 kamailio[23122]: #026#003#003
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9c1700, 9, 2,
> 0x7f90f2438f80), fd_no=1
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_read.c:296]: tcp_read_data(): EOF on 0x7f90f2438f80, FD 9
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_read.c:1291]: tcp_read_req(): tcp_read_req: EOF
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9c1700, 9, -1, 0x10)
> fd_no=2 called
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_read.c:1434]: release_tcpconn(): releasing con 0x7f90f2438f80, state
> -1, fd=9, id=30
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG: 
> [tcp_read.c:1435]: release_tcpconn():  extra_data 0x7f90f2432b40
> Apr 15 11:11:42 vps793907 kamailio[23122]: 13(23167) DEBUG: 
> [tcp_main.c:3331]: handle_tcp_child(): handle_tcp_child: reader response=
> 7f90f2438f80, -1 from 1
> Apr 15 11:11:42 vps793907 kamailio[23122]: 13(23167) DEBUG: tls
> [tls_server.c:604]: tls_h_close(): Closing SSL connection 0x7f90f2432b40
>
> 2.- With TCPDUMP:
>
> 11:13:09.311797 IP SBC_IP .1024 > SBC_IP .eu.sip-tls: Flags [S], seq
> 261244614, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK],
> length 0
> 11:13:09.311898 IP  SBC_IP .eu.sip-tls > 52.114.76.76.1024: Flags [S.],
> seq 812357247, ack 261244615, win 29200, options [mss
> 1460,nop,nop,sackOK,nop,wscale 7], length 0
> 11:13:09.340358 IP 52.114.76.76.1024 >  SBC_IP .eu.sip-tls: Flags [.], ack
> 1, win 2053, length 0
> 11:13:09.340560 IP 52.114.76.76.1024 > SBC_IP .eu.sip-tls: Flags [P.], seq
> 1:187, ack 1, win 2053, length 186
> 11:13:09.340578 IP SBC_IP .eu.sip-tls > 52.114.76.76.1024: Flags [.], ack
> 187, win 237, length 0
> 11:13:09.341361 IP SBC_IP .eu.sip-tls > 52.114.76.76.1024: Flags [P.], seq
> 1:1469, ack 187, win 237, length 1468
> 11:13:09.369606 IP 52.114.76.76.1024 > SBC_IP .eu.sip-tls: Flags [.], ack
> 1469, win 2053, length 0
> 11:13:12.451498 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [S], seq
> 309084204, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK],
> length 0
> 11:13:12.451587 IP SBC_IP .eu.sip-tls > 52.114.7.24.1216: Flags [S.], seq
> 3275066862, ack 309084205, win 29200, options [mss
> 1460,nop,nop,sackOK,nop,wscale 7], length 0
> 11:13:12.707119 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [.], ack
> 1, win 2053, length 0
> 11:13:12.707311 IP 52.114.7.24.1216 > SBC_IP .eu.sip-tls: Flags [P.], 

[SR-Users] Dealing with mobile client state while using Push Notification and TSILO

[Hubert Odziemczyk]

Hello!

We are trying to setup a call-flow with TSILO and Push Notifications for 
solution with a mobile SIP client (Linphone), based on presentation by Federico 
Cabiddu 
(http://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf).

We have an issue with "managing" state of the client (active or not) when there 
is a call coming. To be more specific, lookup in location table doesn't always 
give a proper answer, as contact expiration is different from actual lifetime 
of the app (which also differs between iOS and Android).
One of proposed solutions is setting Expires=1 for REGISTER and then always 
rely on Push Notifications, but this scenario seems to be unreliable with some 
clients that are in foreground, as Push Notification doesn't trigger REGISTER 
again.

Question is: did you perceive similar problems? What are your solutions to deal 
with them?

Thank you in advance!

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