Re: [SR-Users] LCR module dont_strip_or_tag_flag -> dont_strip_or_prefix_flag

[Mikko Lehto]

Annus Fictus :

> modparam("lcr", "dont_strip_or_tag_flag", 10)
> 
> and then restart kamailio, i receive this error:
> 
> ERROR:  [modparam.c:141]: set_mod_param_regex(): parameter
>  of type <2> not found in module 

Hi

Looks like that parameter is now¹ called dont_strip_or_prefix_flag
but module documentation was just not updated.

[1] Change was committed in 2010
https://github.com/kamailio/kamailio/commit/8c0501bfaa27acab9721953e8c1551687c96edf2

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Local messages are malformed in Kamailio 4.4.X

[Mikko Lehto]

Daniel-Constantin Mierla :

> The specs require to be \r\n. Accepting only \n is and
> SER-time-propagated extension in Kamailio from the early days of the
> project when a lot of tests during the development was done by building
> messages inside a text file and injecting it into the network. When a
> response is built by kamailio, the needed headers from request that are
> not changed are just copied. Everything else will get the standard \r\n.
> 
> So this is due to that flexibility and I think we are fine with this
> behaviour given it happens only on very specific corner cases, mainly
> for the testing.

Sure, works for me.

Something like that was my guess as well since new headers
we're CRLF and other as they were in incoming request.

So "problem" was self caused when analyzing traces where I had  -L
(--no-crlf) flag passed to sipsak in some tests.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTP Pyload

[Mikko Lehto]

amar Smart Telecom <a...@smarttel.com.np> wrote:

> We are seeing that some RTP Payload are with 14 bytes and some are with 15
> bytes.
> 
>  
> 
> 1.   14 byte is correct or 15 byte is correct?
> 
> 2.   Is TOC present in all payloads i.e. in all RTP messages?
> 
> Following example with 14 byte payload.
>

> The query is regarding, while using "Payload type: DynamicRTP-Type-111
> (111)"

Hi

Please explain how this relates to Kamailio, hopefully after that
there is less guesswork for potential advice.

Best regards

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Local messages are malformed in Kamailio 4.4.X

[Mikko Lehto]

Same thing with Kamailio version 4.4.4 (c5d3bd)

$ sipsak -H localhost -s sip:127.0.0.1:5060 -v -f test/unit/60-message-sdp4.sip 
--no-crlf

# tcpdump -i lo0 -s 0 -n -v -X port 5060   
03:14:09.247227 IP 127.0.0.1.10564 > 127.0.0.1.5060: SIP: MESSAGE 
sip:bob@example.invalid SIP/2.0
0x:  4500 0248 cdf1  4011  7f00 0001  E..H@...
0x0010:  7f00 0001 2944 13c4 0234 0048 4d45 5353  )D...4.HMESS
0x0020:  4147 4520 7369 703a 626f 6240 6578 616d  AGE.sip:bob@exam
0x0030:  706c 652e 696e 7661 6c69 6420 5349 502f  ple.invalid.SIP/
0x0040:  322e 300a 5669 613a 2053 4950 2f32 2e30  2.0.Via:.SIP/2.0
0x0050:  2f55 4450 2031 3237 2e30 2e30 2e31 3a32  /UDP.127.0.0.1:2
0x0060:  3439 3134 3b62 7261 6e63 683d 7a39 6847  4914;branch=z9hG
0x0070:  3462 4b2e 3533 3732 6539 3066 3b72 706f  4bK.5372e90f;rpo
0x0080:  7274 3b61 6c69 6173 0d0a 4672 6f6d 3a20  rt;alias..From:.
0x0090:  7369 703a 616c 6963 6540 6578 616d 706c  sip:alice@exampl
0x00a0:  652e 696e 7661 6c69 643b 7461 673d 3435  e.invalid;tag=45
0x00b0:  6466 6466 3439 0a54 6f3a 2073 6970 3a62  dfdf49.To:.sip:b
0x00c0:  6f62 4065 7861 6d70 6c65 2e69 6e76 616c  ob@example.inval
0x00d0:  6964 0a43 616c 6c2d 4944 3a20 3131 3732  id.Call-ID:.1172
0x00e0:  3239 3935 3933 610a 4353 6571 3a20 3120  299593a.CSeq:.1.
0x00f0:  4d45 5353 4147 450a 436f 6e74 656e 742d  MESSAGE.Content-
0x0100:  5479 7065 3a20 6170 706c 6963 6174 696f  Type:.applicatio
0x0110:  6e2f 7364 700a 4d61 782d 466f 7277 6172  n/sdp.Max-Forwar
0x0120:  6473 3a20 320a 582d 496e 666f 3a20 7364  ds:.2.X-Info:.sd
0x0130:  706f 7073 2072 656d 6f76 655f 6c69 6e65  pops.remove_line
0x0140:  5f62 795f 7072 6566 6978 2829 2074 6573  _by_prefix().tes
0x0150:  7434 202d 2064 7561 6c20 6d61 7463 6869  t4.-.dual.matchi
0x0160:  6e67 206c 696e 6573 0a0a 763d 300a 6f3d  ng.lines..v=0.o=
0x0170:  2d20 3337 3030 3130 2030 2049 4e20 4950  -.370010.0.IN.IP
0x0180:  3420 3139 322e 3136 382e 3133 2e33 310a  4.192.168.13.31.
0x0190:  733d 4d47 570a 633d 494e 2049 5034 2031  s=MGW.c=IN.IP4.1
0x01a0:  3932 2e31 3638 2e31 332e 3331 0a74 3d30  92.168.13.31.t=0
0x01b0:  2030 0a6d 3d61 7564 696f 2032 3236 3136  .0.m=audio.22616
0x01c0:  2052 5450 2f41 5650 2030 2039 3620 3130  .RTP/AVP.0.96.10
0x01d0:  300a 613d 7274 706d 6170 3a39 3620 7465  0.a=rtpmap:96.te
0x01e0:  6c65 7068 6f6e 652d 6576 656e 742f 3830  lephone-event/80
0x01f0:  3030 0a61 3d72 7470 6d61 703a 3130 3020  00.a=rtpmap:100.
0x0200:  582d 4e53 452f 3830 3030 0a61 3d58 2d63  X-NSE/8000.a=X-c
0x0210:  6170 313a 2031 2061 7564 696f 2052 5450  ap1:.1.audio.RTP
0x0220:  2f41 5650 2031 3030 0a61 3d58 2d63 6170  /AVP.100.a=X-cap
0x0230:  323a 2031 2061 7564 696f 2052 5450 2f41  2:.1.audio.RTP/A
0x0240:  5650 2031 3030 0a0a  VP.100..
03:14:09.247413 IP 127.0.0.1.5060 > 127.0.0.1.10564: SIP: SIP/2.0 200 OK
0x:  4510 0262 9ddd  4011  7f00 0001  E..b@...
0x0010:  7f00 0001 13c4 2944 024e 0062 5349 502f  ..)D.N.bSIP/
0x0020:  322e 3020 3230 3020 4f4b 0d0a 5669 613a  2.0.200.OK..Via:
0x0030:  2053 4950 2f32 2e30 2f55 4450 2031 3237  .SIP/2.0/UDP.127
0x0040:  2e30 2e30 2e31 3a32 3439 3134 3b62 7261  .0.0.1:24914;bra
0x0050:  6e63 683d 7a39 6847 3462 4b2e 3533 3732  nch=z9hG4bK.5372
0x0060:  6539 3066 3b72 706f 7274 3d31 3035 3634  e90f;rport=10564
0x0070:  3b61 6c69 6173 3b72 6563 6569 7665 643d  ;alias;received=
0x0080:  3132 372e 302e 302e 310d 0a46 726f 6d3a  127.0.0.1..From:
0x0090:  2073 6970 3a61 6c69 6365 4065 7861 6d70  .sip:alice@examp
0x00a0:  6c65 2e69 6e76 616c 6964 3b74 6167 3d34  le.invalid;tag=4
0x00b0:  3564 6664 6634 390a 546f 3a20 7369 703a  5dfdf49.To:.sip:
0x00c0:  626f 6240 6578 616d 706c 652e 696e 7661  b...@example.inva
0x00d0:  6c69 643b 7461 673d 6232 3765 3161 3164  lid;tag=b27e1a1d
0x00e0:   3736 3165 3835 3834 3666 6339 3866  33761e85846fc98f
0x00f0:  3566 3361 3765 3538 2e36 3634 650a 4361  5f3a7e58.664e.Ca
0x0100:  6c6c 2d49 443a 2031 3137 3232 3939 3539  ll-ID:.117229959
0x0110:  3361 0a43 5365 713a 2031 204d 4553 5341  3a.CSeq:.1.MESSA
0x0120:  4745 0a43 6f6e 7465 6e74 2d54 7970 653a  GE.Content-Type:
0x0130:  2061 7070 6c69 6361 7469 6f6e 2f73 6470  .application/sdp
0x0140:  0d0a 5365 7276 6572 3a20 6b61 6d61 696c  ..Server:.kamail
0x0150:  696f 2028 342e 342e 3420 2878 3836 5f36  io.(4.4.4.(x86_6
0x0160:  342f 6672 6565 6273 6429 290d 0a43 6f6e  4/freebsd))..Con
0x0170:  7465 6e74 2d4c 656e 6774 683a 2032 3232  tent-Length:.222
0x0180:  0d0a 0d0a 763d 300a 6f3d 2d20 3337 3030  

Re: [SR-Users] Local messages are malformed in Kamailio 4.4.X

[Mikko Lehto]

Helio Okuyama <hok.s...@gmail.com> wrote:

> Local messages are malformed in Kamailio 4.4.X. For example after receiving
> an error response (603) to an INVITE message, the ACK is generated with
> header Max-Forwards concatenated to header CSeq and double CRLF, which is
> wrong.

Funny thing, I just discovered something with line endings as well
when replying locally from config file.

Kamailio seems to reply with mixed line terminators when flag --no-crlf
is used with sipsak.

How to repeat:

kamailio.cfg
---
debug=2
fork=yes
log_stderror=no
children=1
disable_tcp=yes
listen=udp:127.0.0.1:5060
auto_aliases=no
loadpath "modules/"
loadmodule "sl.so"
loadmodule "pv.so"
loadmodule "textops.so"
modparam("sl", "bind_tm", 0)
request_route {
set_reply_body($rb,"application/sdp");
sl_send_reply(200,"OK");
exit;
}
---

$ sipsak -H localhost -s sip:127.0.0.1:5060 -v -f test/unit/60-message-sdp9.sip 
--no-crlf

tcpdump shows following headers and line terminators:
---
200 OKCRLF
Via...CRLF
From...LF
To...LF
Call-ID...LF
CSeq...LF
Content-Type...CRLF
Server...CRLF
Content-Length...CRLF
CRLF
---

Maybe these two findings are related. I tested with master version.

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Wiki update notice

[Mikko Lehto]

Hello

Some wiki work:
1. "What's new in 4.4" -content is no more present in devel version wiki page
2. based on recent mailing list discussion, I added note about github pull 
requests

I think these make sense, please yell if not :)

[1] http://kamailio.org/wiki/features/new-in-devel
[2] http://kamailio.org/wiki/devel/github-contributions?rev=1456916916=diff

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] sdp_remove_line_by_prefix

[Mikko Lehto]

Alberto Sagredo <alberto.sagr...@avanzada7.com>:
 
> Im trying to remove my Asterisk s= line on SDP but when doing:
> 
> sdp_remove_line_by_prefix("s=Asterisk");
> 
> Nothing happens.

Hi Alberto

Did you try with 4.4 yet?
I made some changes to sdpops and I think your example should now work
as well as some other short comings:
https://github.com/kamailio/kamailio/commit/5db4cec2c9e8ab62c711738eae181afa69c1724d

Best regards

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] timeout function

[Mikko Lehto]

Al S <ali...@outlook.com> wrote:

> I am routing call traffic thru proxy to destination A. If destination A is 
> down, we need to reroute to destination B. What function we can use to 
> process timeout so we can reroute the calls to different node?

Hi

Have a look what TM module has to offer:
http://kamailio.org/docs/modules/4.4.x/modules/tm.html#tm.f.t_on_failure
http://kamailio.org/docs/modules/4.4.x/modules/tm.html#tm.f.t_set_fr

In addition, you can also use dispatcher module to automatically
populate new destination addresses:
http://kamailio.org/docs/modules/4.4.x/modules/dispatcher.html#dispatcher.ex.config

Regards
-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] GCC version in use

[Mikko Lehto]

Daniel-Constantin Mierla :

> Anyone with openbsd around?

Sure!

$ uname -srvm
OpenBSD 5.8 GENERIC.MP#1236 amd64
$ gcc -v
Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.8/4.2.1/specs
Target: amd64-unknown-openbsd5.8
Configured with: OpenBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 


I haven't tried to compile Kamailio seriously yet, but first
quick try generates lot of noise. Fortunately there are some
patches in OpenBSD ports tree that I haven't applied.

Hope this helps.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] GCC version in use

[Mikko Lehto]

Daniel-Constantin Mierla :

> > OpenBSD 5.8 GENERIC.MP#1236 amd64
> 
> Thanks! Is this the last version of openbsd?

Yes, 5.8 was released 2015-10-18


Looks like 4.2.1 was introduced in version 4.8 (2010-11-01):
"Gcc 2.95.3 (+ patches), 3.3.5 (+ patches) and 4.2.1 (+patches)"

Support for 2.95.3 was removed in version 5.5 (2014-05-01):
"Gcc 4.2.1 (+ patches) and 3.3.6 (+ patches)"

Just for the sake of completeness, current (5.8/5.9) GCC versions are:
"Gcc 4.2.1 (+ patches) and 3.3.6 (+ patches)"

http://www.openbsd.org/48.html
http://www.openbsd.org/55.html
http://www.openbsd.org/58.html

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Media address family

[Mikko Lehto]

Sergey Okhapkin <s...@sokhapkin.dyndns.org>:

> What is the best way to find out address family (IPV4 or IPV6) of media in 
> SDP? 

Hi, maybe something like this works:

if(sdp_get_line_startswith("$avp(cline)", "c=IN IP6")) {
xlog("c-line: $avp(cline)\n");
}

I did not test, just copy-pasted from documentation:
http://kamailio.org/docs/modules/devel/modules/sdpops.html#sdpops.f.sdp_get_line_startswith

Be aware that SDP can have multiple c-lines, so you propably want
to scan SDP more extensively.


Best regards
-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Need to add extra header in 200 OK message by using kamailio.cfg file

[Mikko Lehto]

Priyaranjan Nayak priyaranjan4...@gmail.com:

 I wanted to send  a extra header(i.e. Security-Server ) in the 200 OK from
 kamailio server. Could you please suggest me how can I add extra header in
 200 OK message by using kamailio.cfg file ?

Hi Priyaranjan

Maybe you are looking for script function append_to_reply() ?

http://www.kamailio.org/docs/modules/4.3.x/modules/textops.html#textops.f.append_to_reply

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Need to add extra header in 200 OK message by using kamailio.cfg file

[Mikko Lehto]

Priyaranjan Nayak priyaranjan4...@gmail.com:
 
 loading modules under config path: /usr/local/lib64/kamailio/modules/
  0(3002) ERROR: core [cfg.y:3282]: yyparse(): misused command
 append_to_reply
  0(3002) : core [cfg.y:3426]: yyerror_at(): parse error in config file
 /usr/local/etc/kamailio/kamailio.cfg, line 982, column 164: Command cannot
 be used in the block

That means that you can not run append_to_reply()
while in onreply_route -block. Quote from documentation:
---
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE,
FAILURE_ROUTE, ERROR_ROUTE.  
---

Maybe you can call append_to_reply() before setting onreply_route
with t_on_reply() ?


 ERROR: bad config file (1 errors)
  0(3002) WARNING: core [ppcfg.c:219]: pp_ifdef_level_check(): different
 number of preprocessor directives: N(#!IF[N]DEF) - N(#!ENDIF) = 1

I don't know about this, propably unrelated to above.

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Strange core.tcp_list / tls.list output

[Mikko Lehto]

Daniel-Constantin Mierla mico...@gmail.com:

 quickly checking the code it seems that the dst_ip is holding the local
 address always, even for outbound connection.
 
 Not being the author of the code, my guess is that the lookup of
 connection is done always on src_ip matching the remote peer address.
 Also, the structure used there is the one specific for holding received
 info for sip packets.
 
 The output is somehow misleading, maybe the fields should be renamed to
 local_ip/port and remote_ip/port in the output of the rpc commands.

Much more clear now, thanks!

It propably is wise to touch only RPC output.
I'll try to look into this again soon and come up with patch.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Strange core.tcp_list / tls.list output

[Mikko Lehto]

Hi, I noticed thath command core.tcp_list in kamcmd gives output that
does not make sense to me:
---
kamcmd core.tcp_list
{
id: 1
type: TLS
state: CONN_OK
timeout: 3599
ref_count: 1
src_ip: 192.168.47.132
src_port: 5061
dst_ip: 10.10.235.9
dst_port: 54769
}
{
id: 2
type: TLS
state: CONN_OK
timeout: 3599
ref_count: 1
src_ip: 192.168.47.132
src_port: 32854
dst_ip: 10.10.235.9
dst_port: 5041
}
---

In my scenario I am connecting via TLS to host 192.168.47.132:5061.
And host 192.168.47.132 is connecting to my proxy host 10.10.235.9:5041.
pcap verifies this. Also tls.list gives similar output.

Values regarding incoming connection (id=2) makes total sense.
It seems that values regarding outgoing connection (id=1) have
dst_* values swapped with src_* values.


To debug, I placed this logging to tcp_main.c:
---
$ git diff tcp_main.c
diff --git a/tcp_main.c b/tcp_main.c
index 5830c8e..3717cf6 100644
--- a/tcp_main.c
+++ b/tcp_main.c
@@ -1207,6 +1207,7 @@ again:
}
from=my_name; /* update from with the real from address */
su2ip_addr(ip, my_name);
+   LM_WARN(after getsockname()  my_name=%s server=%s ip=%s\n,
su2a(my_name, sizeof(my_name)), su2a(server, sizeof(*server)),
ip_addr2a(ip));
 find_socket:
 #ifdef USE_TLS
if (unlikely(type==PROTO_TLS))
@@ -1223,6 +1224,7 @@ find_socket:
else *res_si=sendipv6_tcp;
}
*res_local_addr=*from;
+   LM_WARN(before returnmy_name=%s server=%s ip=%s\n,
su2a(my_name, sizeof(my_name)), su2a(server, sizeof(*server)),
ip_addr2a(ip));
return s;
 error:
if (s!=-1) tcp_safe_close(s);
---

This gives following output:
WARNING: core [tcp_main.c:1210]: tcp_do_connect(): after getsockname() 
my_name=192.168.47.132:5061 server=192.168.47.132:5061 ip=10.10.235.9
WARNING: core [tcp_main.c:1227]: tcp_do_connect(): before return 
my_name=192.168.47.132:5061 server=192.168.47.132:5061 ip=10.10.235.9


Are tcp endpoint values really wrong way around or did I undertand
something wrong about their meaning?

I am running Kamailio 4.2.5 (x86_64/linux) 61d84c-dirty from git.

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] pua_subscribe and force_send_socket trouble

[Mikko Lehto]

Makes sense, I can live with this.

Thanks for clarfication.

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] TLS capture with sip_trace()

[Mikko Lehto]

Hi

I am getting incorrect source port to Homer web while tracking
outgoing request from my proxy to remote SIP server.


Juha Heinanen j...@tutpro.com wrote in another thread:

 in case of tcp (and tls) the source port is always a random one.
 only the destination port can be predetermined.

Interface capture (tcpdump) shows exactly what Juha wrote
i.e. random source port for TLS connection.

I always get local TLS listener address as Homer source_port,
clearly not true when comparing to output of tcpdump.
I am calling sip_trace() from branch_route and onsend_route.

Is it even possbile to use siptrace with TLS so that
it records correct TCP (random) source port to Homer?


I tried briefly printing some structure variables in
siptrace/siptrace.c but it seems that real source port
is not available in struct dest_info at that context.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] pua_subscribe and force_send_socket trouble

[Mikko Lehto]

Juha Heinanen j...@tutpro.com:

 in case of tcp (and tls) the source port is always a random one.
 only the destination port can be predetermined.

OK, thanks. I'll go with that then.

Actually I can see non-random port with TLS...
...but that's with Homer + sip_trace() captured traffic.
I'll write another thread about that.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] pua_subscribe and force_send_socket trouble

[Mikko Lehto]

Some additional information:

OS is Linux Debian Wheezy 7.6 on amd64

pua_subscribe is launched like this:
kamcmd mi pua_subscribe sip:+35812345789@A.B.C.D:5041 sip:myproxy.fqdn.invalid 
presence 3600

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] pua_subscribe and force_send_socket trouble

[Mikko Lehto]

Hi

I am having strange behavior on local port assignment when
proxying out locally generated request. Kamailio is 4.2.1 from git.


I use MI pua_subscribe to create subscription to be handled by
external presence server.

In event_route[tm:local-request] I set $du to point back to proxy itself.

When request hits initial request_route, I add some headers, change
request URI and prepare failure_route for later uac_auth() processing.
So far so good and TLS packets are flying to correct destination.

Here is the trouble:
when I observe outgoing TLS traffic with tcpdump, I can see that local
source port is not following what I set with force_send_socket(). I tried to
place force_send_socket() in request_route, branch_route, and
tm:local-request, but it is always some random high port (3), never
the intended one. I am trying to set it to same as my TLS listening socket.

Is my usage somehow incorrect?
What should I try next to make Kamailio use constant source port?

Relevant config snippet below (IP address and domain part is obscured).
---
mhomed=1
listen=udp:A.B.C.D:5041
listen=tls:A.B.C.D:5041

request_route {
route(REQINIT);
if ( blahblah...  ) {
$ru = sip: + $rU + @domain.part.invalid;transport=tls;
$avp(uac_auth) = 0;
route(PR_HDRS);
route(PR_TRIGGERS);
force_send_socket(A.B.C.D:5041);
t_newtran();
route(RELAY);
}
}
route[PR_HDRS] {
remove_hf(User-Agent);
insert_hf(User-Agent: pua_subscribe\r\n,Call-ID);
}
route[PR_TRIGGERS] {
t_on_branch(PR_BRANCH);
t_on_failure(PR_FAILURE);
}
branch_route[PR_BRANCH] {
force_send_socket(A.B.C.D:5041);
}
failure_route[PR_FAILURE]  {
if ( $avp(uac_auth) == 0  ($T_reply_code == 401 or $T_reply_code == 
407) ) {
uac_auth();
$avp(uac_auth) = 1;
route(PR_TRIGGERS);
route(RELAY);
}
}
event_route [tm:local-request] {
force_send_socket(A.B.C.D:5041);
$du = sip:A.B.C.D:5041;
}
route[RELAY] { is from default config }
---


I found these recent commits, bugs and threads somehow relating
to force_send_socket and tm:local-request:

http://sip-router.org/tracker/index.php?do=detailstask_id=462
http://lists.sip-router.org/pipermail/sr-users/2014-August/084459.html

dbd8ea9b1fa216e59d4c36e2eb4b671202824259
http://lists.sip-router.org/pipermail/sr-dev/2014-September/024984.html

e404d123610b63ddd1c75d39667b373c40071eab
http://lists.sip-router.org/pipermail/sr-dev/2014-September/024977.html

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Non standard TLS port

[Mikko Lehto]

2014-11-11 (Tue) 21:19 UTC +0300  elek...@yandex.ru wrote:

 I'm using Kamailio 4.2 running TLS only connection on non standard port 5065. 
 I added the following line to the kamailio.cfg:
 
 listen=tls:111.222.333.444:5065
 
 Domain SRV record as follows:
 
 _sips._tls.domain.com  port 5065

Hi, try _sips._tcp.domain.com instead.
RFC 3263 gives guidance, also with NAPTR records.

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] channel parameter on SDP

[Mikko Lehto]

Kelvin Chua kel...@gmail.com wrote:

 my provider is being a dick.
 they do not accept doubango's
 
 a=rtpmap:0 PCMU/8000/1
 
 what they wanted was
 
 a=rtpmap:0 PCMU/8000
 
 is there a way of changing this on kamailio?

Maybe it could work if you remove static RTP attribute completely:
---
sdp_remove_line_by_prefix(a=rtpmap:0 PCM);
---

If that does not work, then maybe try subst_body() ?

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Realtime integration: Unregistered clients showing as registered?

[Mikko Lehto]

Olli Heiskanen ohjelmistoarkkite...@gmail.com:

 Thanks for the help, here's what I dug up:
 
 The users are visible in Kamailio, output of kamcmd ul.dump:
 (here 1.1.1.1 is the public ip of my Kamailio+Asterisk server and 2.2.2.2
 is the public ip of my home network)

Looks like problem is not in Kamailio or SIP message flow.
At least I can't spot any problems from registration dance or usrloc sample.

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Record routing transport=tcp and examples/websocket.cfg

[Mikko Lehto]

Hi websocketeers, examples/websocket.cfg starts with this check:

---
request_route {
if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT)
 !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) {
xlog(L_WARN, SIP request received on $Rp\n);
sl_send_reply(403, Forbidden);
exit;
}
---

My in-dialog SIP over TCP requests got 403 treatment because of this.
I believe reason was MY_WS_ADDR in route set, added by record_route().

Above sanity check seems sensible tough, so I fixed advertised route set
with call to force_send_socket() as seen on attached patch.

I wonder if my fix is the best approach.
Should the remaining other two t_relay() calls also be prepared
with force_send_socket()?

-- 
Mikko
diff --git a/examples/websocket.cfg b/examples/websocket.cfg
index 9fa4229..9fc2c5b 100644
--- a/examples/websocket.cfg
+++ b/examples/websocket.cfg
@@ -6,9 +6,15 @@
 #!substdef !DBURL!sqlite:///etc/kamailio/db.sqlite!g
 #!substdef !MY_IP_ADDR!a.b.c.d!g
 #!substdef !MY_DOMAIN!example.com!g
+#!substdef !MY_TCP_PORT!5060!g
+#!substdef !MY_TLS_PORT!5061!g
+#!substdef !MY_SCTP_PORT!5060!g
 #!substdef !MY_WS_PORT!80!g
 #!substdef !MY_WSS_PORT!443!g
 #!substdef !MY_MSRP_PORT!9000!g
+#!substdef !MY_TCP_ADDR!tcp:MY_IP_ADDR:MY_TCP_PORT!g
+#!substdef !MY_TLS_ADDR!tls:MY_IP_ADDR:MY_TLS_PORT!g
+#!substdef !MY_SCTP_ADDR!sctp:MY_IP_ADDR:MY_SCTP_PORT!g
 #!substdef !MY_WS_ADDR!tcp:MY_IP_ADDR:MY_WS_PORT!g
 #!substdef !MY_WSS_ADDR!tls:MY_IP_ADDR:MY_WSS_PORT!g
 #!substdef !MY_MSRP_ADDR!tls:MY_IP_ADDR:MY_MSRP_PORT!g
@@ -221,6 +227,20 @@ request_route {
 }
 
 route[RELAY] {
+
+# try to prevent connection via incorrect (web)socket
+if ( $(du{uri.transport}) == ws || $(du{uri.transport}) == WS ) {
+force_send_socket(MY_WS_ADDR);
+} else if ( $(du{uri.transport}) == wss || $(du{uri.transport}) == WSS ) {
+force_send_socket(MY_WSS_ADDR);
+} else if ( $(du{uri.transport}) == tcp || $(du{uri.transport}) == TCP ) {
+force_send_socket(MY_TCP_ADDR);
+} else if ( $(du{uri.transport}) == tls || $(du{uri.transport}) == TLS ) {
+force_send_socket(MY_TLS_ADDR);
+} else if ( $(du{uri.transport}) == sctp || $(du{uri.transport}) == SCTP ) {
+force_send_socket(MY_SCTP_ADDR);
+}
+
 	if (!t_relay()) {
 		sl_reply_error();
 	}
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] [sr-dev] [sr-users] Problem accessing git repository

[Mikko Lehto]

2013-04-15 (Mon) 23:45 UTC +0200  Daniel-Constantin Mierla mico...@gmail.com:

 try with a new clone and see if it works to pull afterwards.
 
 Otherwise I cannot think of anything else than looking at network
 traffic to see if something is wrong there.

New clone seem to pull fine. Maybe we troubleshoot more if this reoccurs.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] [sr-dev] Problem accessing git repository

[Mikko Lehto]

2013-04-12 (Fri) 16:49 UTC +0200  Henning Westerholt h...@kamailio.org:

 sip-router.org is up again, all services should be available.

Thanks, unfortunately still the same:

---
$ git pull
fatal: read error: Connection reset by peer
$
---

I noticed Juha Heinänen also reported same on sr-dev.

Anything else I can do or should I just use new clone?

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Problem accessing git repository

[Mikko Lehto]

Hi

Yesterday I got fatal: read error: Connection reset by peer to my git pull 
command.
I thought it was only temporary network error, but same problem still exist 
today.

I can however access other remote git repositories succesfully from the same 
host.

--- #sip-router
10.58  mslehto hmm... I get Connection reset by peer to git fetch command
10.59  mslehto propably local issue if you just updated master branch 
succesfully
11.10  iZverg git pull
11.11  iZverg # git pull
11.11  iZverg Already up-to-date.
11.11  iZverg i think all ok with server
13.07  mslehto I don't get it .pcap dumps shows some git traffic to 
git.sip-router.org, but finally I get TCP RST
13.07  mslehto I have remote.origin.url=git://git.sip-router.org/sip-router
13.08  mslehto seems to be same as in 
http://kamailio.org/wiki/install/devel/git
13.13  iZverg url = git://git.sip-router.org/sip-router
13.13  iZverg Already up-to-date.
---

I think this is not local issue, any pointers what I should troubleshoot next?


UPDATE:
I am able to get source code via git clone to fresh directory with no errors, 
confusing.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] documentation update for 3.2.0 and wiki system

[Mikko Lehto]

Daniel-Constantin Mierla wrote:

 More suggestions are welcome here, let us know what will make your life  
 easier in browsing the docs.

Hi Daniel, thanks for asking :)

Sometimes I miss the script function indexes. On the Kamailio wiki there
still are list of functions for 1.5 version, but nothing for newer
versions and nothing in the SIP Router wiki.

If those indexes are easy to create again, it would benefit our purposes.


[1] http://www.kamailio.org/dokuwiki/doku.php/modules:1.5.x:index-functions
-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to test xhttp with wget or curl

[Mikko Lehto]

Hi

I think you are not succeeding because of missing Content-Length header.

Try to add Content-Length to your HTTP request or
you can use tcp_accept_no_cl=no in sip-router.cfg.

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Bug in LDAP module?

[Mikko Lehto]

On Tue, Dec 28, 2010 at 11:50:22AM +0100, Daniel-Constantin Mierla wrote:

 Seemed to be a feature -- ldap module had it this way from its  
 beginning. I committed the update that should create connection to Ldap  
 server from timer processes, so the functions should work now in failure  
 route in all cases.

 The patch was committed on svn branch 1.5 as well, you need to fetch the  
 latest version from there and reinstall in order to try it.

 Let me know if all works fine now.

Hi Pan

Do you have comment on the above patch by Daniel-Constantin?
I plan to use ldap module soon and would like to hear if this issue
you reported is now non existent.

Thanks!

-- 
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] CANCEL with Totag

[Mikko Lehto]

Iñaki Baz Castillo wrote:

 I've asked the client about model and version of his Samsung. I'll
 tell it to you when I get it.

OK, thanks!

For the record, here is the CANCEL we captured:

CANCEL sip:+3589x...@proxy.siplab.fi:5060;user=phone SIP/2.0
From: 
sip:+3589x...@xxx.fi:5060;user=phone;tag=13a7588-26fb446d-13c4-50017-4cf664e7-12afeb6a-4cf664e7
To: sip:+3589x...@proxy.siplab.fi:5060;user=phone
Call-ID: 13a9ff0-26fb446d-13c4-50017-4cf664e7-288b990c-4cf664e7
CSeq: 1 CANCEL
Via: SIP/2.0/UDP 
89.18.XXX.XXX:5060;rport;branch=z9hG4bK-4cf664e7-a27a29d2-2d80c774
Max-Forwards: 70
Supported: replaces
User-Agent: Samsung OfficeServ
Content-Length: 0

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Error in syslog: BUG tm [t_msgbuilder.c:351]: unhandled reason cause -18344

[Mikko Lehto]

Daniel-Constantin Mierla wrote:


Can you try with master or cherry pick the next commit?
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7faa58b0264cb77c991a21bd3b7e3d660596ad85 


I couldn't figure out cherry picking quickly so I tested with master.
Reported log message disapperead, thank you Daniel.

--
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Error in syslog: BUG tm [t_msgbuilder.c:351]: unhandled reason cause -18344

[Mikko Lehto]

Mikko Lehto wrote:


The above error message is found in t_msgbuilder.c on
#ifdef CANCEL_REASON_SUPPORT -block.
Looks like I do not have compiled in support for that new feature as I 
get error when uncommenting local_cancel_reason tm parameter:
ERROR: core [modparam.c:150]: set_mod_param_regex: parameter 
local_cancel_reason not found in module tm


Is this bug as log message suggests?


Hi

Update to my initial report.

1) CANCEL_REASON_SUPPORT is enabled per default.
It just does not show up with -V command line argument.

2) I had double quotes around TM parameter:
modparam(tm, local_cancel_reason, 0)
That was the reason for error during startup, quotes removed.

3) Documentation says local_cancel_reason is boolean, but in the example 
there are quotes around the parameters.


4) The original issue remains regardless of the local_cancel_reason value:
BUG: tm [t_msgbuilder.c:351]: unhandled reason cause -18344

--
Mikko

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Error in syslog: BUG tm [t_msgbuilder.c:351]: unhandled reason cause -18344

[Mikko Lehto]

Hi

I am testing certain UAC behavior on proxy initiated 408 response with 
SIP Router. Call canceling is working fine - UAC gets 408 and GW gets 
CANCEL.


However this error message is seen in syslog after fr_inv_timeout fires:
BUG: tm [t_msgbuilder.c:351]: unhandled reason cause -18344

In script I set t_set_fr before t_relay, otherwise it is default:
route[RELAY] {
  if (is_method(INVITE)) {
t_on_reply(REPLY_ONE);
t_on_failure(FAIL_TEST);
  }
  t_set_fr(4000);
  if (!t_relay()) {
sl_reply_error();
  }
  exit;
}

SIP Router is self compiled from Git:
sip-router 3.1.0 (i386/linux) 34d2f6

Here are TM parameters:
#modparam(tm, local_cancel_reason, 0)
modparam(tm, noisy_ctimer, 1)
modparam(tm, auto_inv_100_reason, tryink)
modparam(tm, failure_reply_mode, 3)
modparam(tm, fr_timer, 3)
modparam(tm, fr_inv_timer, 12)

The above error message is found in t_msgbuilder.c on
#ifdef CANCEL_REASON_SUPPORT -block.
Looks like I do not have compiled in support for that new feature as I 
get error when uncommenting local_cancel_reason tm parameter:
ERROR: core [modparam.c:150]: set_mod_param_regex: parameter 
local_cancel_reason not found in module tm


Is this bug as log message suggests?

--
Mikko Lehto
Setera

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] pdb and carrier id zero in finnish LNP

[Mikko Lehto]

  (Queries seem to work after I changed MIN_PDB_CARRIERID in common.h to 0,
  but unfortunately that configuration just does not make sense.)
 
 Do you refer to the fact that then also the internal logic of the module 
 needs 
 to be changed as well?

Yes, exactly.

 
 Well, the module could be changed, that maybe could also use something like 
 997 or 998 for the not found id could be used.

Those are part of the reserved range around here, but length is four
starting from 9900.
0998 could be not found and 9900 first four digit carrier.

That would work for my case, maybe I'll try mapping zero to something else with
my vintage C skills.


 You're right, it should be only in the carrier name file. I'll fix this. 
 Somehow this is used from german regulation authorities, it stands probably 
 for the country name. We could probably change it, patches are welcome. ;-)

It's OK like that, I'll rather mess with the not found case for now.

Country prefix could actually be useful if one file has carrier names
from multiple countries.


 Great, thank you! I'll add it to the repository, and also fix the german one 
 (some changes in URL)

Nice, I see you like wget more :)

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] pdb and carrier id zero in finnish LNP

[Mikko Lehto]

Hi

I am exploring the applicability of pdb module in finnish number portability 
scheme.
Looks like carrier id 000 cannot be used as zero is already reserved for
the number could not be found result in pdb protocol.

(Queries seem to work after I changed MIN_PDB_CARRIERID in common.h to 0,
but unfortunately that configuration just does not make sense.)

Is there any way out of this other than using internally different
value for carrier 0?
I rather use correct ids if somehow possible to avoid mapping logic in
routing script.


Note about help text consistency:
When going through pdbt.c there is this comment above import_csv function:
/*
 Read a csv list from the given file and build a dtree structure.
 Format of lines in csv file: number prefix;carrier id.
 Format of carrier id: D[0-9][0-9][0-9].
 Returns the number of lines imported or -1 on error.
*/
Isn't the third line incorrect?
Same thing also in help text output of pdbt -h.
docs/data_format.txt mentions letter D only in front of carrier name file.
What is the meaning of D anyway in this context?


Here is my awk pipe contribution to scripts/get_carrier_names_finland.sh:
curl -o - 
http://www2.ficora.fi/numerointi/nure_numbering.asp?nums=totlang=en; | awk 
'/tbody/, /\/tbody/' | awk -F/td -v RS=/tr '{ gsub(/.*/,,$1) 
gsub(/.*/,,$2); gsub(/auml;/,ä,$2); gsub(/Aring;/,Å,$2); 
gsub(/ouml;/,ö,$2); if ( $2 != ) { printf D%.3d %s\n,$1,$2 } }'

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Unable to load IPv6 locations

[Mikko Lehto]

Daniel-Constantin Mierla wrote:

looks like I forgot to backport a patch committed several month ago -- I 
just did it. Please take the last git branch kamailio_3.0. Unfotunately 
you have to delete the broken records from location table by hand (with 
mysql client or so).


Thanks, now there are square brackets in DB socket column.
No problem with deleting, it was just few records.

--
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Unable to load IPv6 locations

[Mikko Lehto]

Hi

I am doing simple registration test with IPv6 enabled SIP phone.
It seems that Kamailio is unable to load back registrations done via v6 socket
after restart.

Here is (some) content of location table before starting proxy:
---
mysql select username,contact,socket from location;
+--+---+-+
| username | contact   | socket
+--+---+-+
| ml6  | sip:m...@[2a00:17b8::55]:5060;line=z79d766z| 
udp:2A00:17B8:0:0:0:0:0:67:5060 | 
| ml4  | sip:m...@89.18.234.88:5060;line=dp77j5yo   | 
udp:89.18.243.167:5060  | 
---

Here are the error messages during startup:
---
1(26374) DEBUG: usrloc [udomain.c:415]: loading records - cycle [1]
1(26374) ERROR: core [main.c:1116]: ERROR: parse_phostport: too many colons 
in udp:2A00:17B8:0:0:0:0:0:67:5060
1(26374) ERROR: usrloc [udomain.c:314]: bad socket 
udp:2A00:17B8:0:0:0:0:0:67:5060
1(26374) ERROR: usrloc [udomain.c:430]: sipping record for ml6 in table location
---

Here are the listen statements from config:
---
listen=udp:[2a00:17b8::67]:5060
listen=udp:89.18.243.167:5060
---

DB is MySQL 5.1, OS is Debian Squeeze.
Kamailio version is 3.0.3 and it is from kamailio.org APT repository.

At least I just found a typo (sipping), but did I also found a bug?

-- 
Mikko Lehto

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users