30 Nov
2016
30 Nov
'16
8:40 p.m.
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.
Via: SIP/2.0/TLS 173.16.10.61:5061
;branch=z9hG4bKc782.5b960c7c48a4363a0126963daa797eb0.0;i=7
From: "22861"<sip:22861@173.16.10.61;transport=tls>;tag=snl_OIPEOzJUNy
Call-ID: 61b500a71b510a1Pj61qq1k9dPW
To: <sip:551138174108@174.16.4.108:5061;transport=tls>;tag=435012226
CSeq: 2351 ACKMax-Forwards: 70
User-Agent:...
The fix for that seems to be just the order of append_str in function
build_local() from tm\t_msgbuilder.c.
append_str( p, method, method_len );
+ append_str( p, CRLF, CRLF_LEN );
append_str( p, MAXFWD_HEADER, MAXFWD_HEADER_LEN );
- append_str( p, CRLF, CRLF_LEN );
1 Dec
1 Dec
6:05 a.m.
Helio Okuyama <hok.sh10(a)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
6:19 a.m.
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
0x0000: 4500 0248 cdf1 0000 4011 0000 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(a)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
0x0000: 4510 0262 9ddd 0000 4011 0000 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 bob(a)example.inva
0x00d0: 6c69 643b 7461 673d 6232 3765 3161 3164 lid;tag=b27e1a1d
0x00e0: 3333 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 ....v=0.o=-.3700
0x0190: 3130 2030 2049 4e20 4950 3420 3139 322e 10.0.IN.IP4.192.
0x01a0: 3136 382e 3133 2e33 310a 733d 4d47 570a 168.13.31.s=MGW.
0x01b0: 633d 494e 2049 5034 2031 3932 2e31 3638 c=IN.IP4.192.168
0x01c0: 2e31 332e 3331 0a74 3d30 2030 0a6d 3d61 .13.31.t=0.0.m=a
0x01d0: 7564 696f 2032 3236 3136 2052 5450 2f41 udio.22616.RTP/A
0x01e0: 5650 2030 2039 3620 3130 300a 613d 7274 VP.0.96.100.a=rt
0x01f0: 706d 6170 3a39 3620 7465 6c65 7068 6f6e pmap:96.telephon
0x0200: 652d 6576 656e 742f 3830 3030 0a61 3d72 e-event/8000.a=r
0x0210: 7470 6d61 703a 3130 3020 582d 4e53 452f tpmap:100.X-NSE/
0x0220: 3830 3030 0a61 3d58 2d63 6170 313a 2031 8000.a=X-cap1:.1
0x0230: 2061 7564 696f 2052 5450 2f41 5650 2031 .audio.RTP/AVP.1
0x0240: 3030 0a61 3d58 2d63 6170 323a 2031 2061 00.a=X-cap2:.1.a
0x0250: 7564 696f 2052 5450 2f41 5650 2031 3030 udio.RTP/AVP.100
0x0260: 0a0a ..
--
Mikko
4:09 p.m.
On 01/12/2016 02:05, Mikko Lehto wrote:
Helio Okuyama <hok.sh10(a)gmail.com> wrote:
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.
Cheers,
Daniel
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.
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
5:42 p.m.
Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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
1:52 p.m.
Hello,
have you set modparams for tm module related to reparsing the invite or
on dns failover?
The build_local() should be used only in some specific cases and want to
be sure it doesn't get executed somehow when it shouldn't be.
Cheers,
Daniel
On 30/11/2016 16:40, Helio Okuyama 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.
Via: SIP/2.0/TLS
173.16.10.61:5061;branch=z9hG4bKc782.5b960c7c48a4363a0126963daa797eb0.0;i=7
From: "22861"<sip:22861@173.16.10.61
<mailto:sip%3A22861@173.16.10.61>;transport=tls>;tag=snl_OIPEOzJUNy
Call-ID: 61b500a71b510a1Pj61qq1k9dPW
To: <sip:551138174108@174.16.4.108:5061;transport=tls>;tag=435012226
CSeq: 2351 ACKMax-Forwards: 70
User-Agent:...
The fix for that seems to be just the order of append_str in function
build_local() from tm\t_msgbuilder.c.
append_str( p, method, method_len );
+append_str( p, CRLF, CRLF_LEN );
append_str( p, MAXFWD_HEADER, MAXFWD_HEADER_LEN );
-append_str( p, CRLF, CRLF_LEN );
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
3:31 p.m.
Hello.
I make test, currently on kamailio 4.4.0, but as I see in git - tm
module does not changes from that time.
I have normal line termination.
See a dump in attach.
in that dump 10.56.41.33 and 10.56.42.33 is the my mhomed kamailio.
--
Best regards,
Sergey Basov e-mail: sergey.v.basov(a)gmail.com
tel: (+38067) 403-62-54
2016-12-01 10:52 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
have you set modparams for tm module related to reparsing the invite or on
dns failover?
The build_local() should be used only in some specific cases and want to be
sure it doesn't get executed somehow when it shouldn't be.
Cheers,
Daniel
On 30/11/2016 16:40, Helio Okuyama 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.
Via: SIP/2.0/TLS
173.16.10.61:5061;branch=z9hG4bKc782.5b960c7c48a4363a0126963daa797eb0.0;i=7
From: "22861"<sip:22861@173.16.10.61;transport=tls>;tag=snl_OIPEOzJUNy
Call-ID: 61b500a71b510a1Pj61qq1k9dPW
To: <sip:551138174108@174.16.4.108:5061;transport=tls>;tag=435012226
CSeq: 2351 ACKMax-Forwards: 70
User-Agent:...
The fix for that seems to be just the order of append_str in function
build_local() from tm\t_msgbuilder.c.
append_str( p, method, method_len );
+ append_str( p, CRLF, CRLF_LEN );
append_str( p, MAXFWD_HEADER, MAXFWD_HEADER_LEN );
- append_str( p, CRLF, CRLF_LEN );
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:14 p.m.
Hello,
if you haven't changed the tm parameters that refer to reparsing
outgoing requests for building local hop-by-hop messages, then you
should not be affected by the issue reported by Helio Okuyama. The
function that needs to be patched should not used with default values of
tm parameters -- that's the reason I asked Helio to see if those
parameters were changed, to be sure it is no other case when the
function is used with default tm parameters.
Cheers,
Daniel
On 01/12/2016 11:31, Sergey Basov wrote:
Hello.
I make test, currently on kamailio 4.4.0, but as I see in git - tm
module does not changes from that time.
I have normal line termination.
See a dump in attach.
in that dump 10.56.41.33 and 10.56.42.33 is the my mhomed kamailio.
--
Best regards,
Sergey Basov e-mail: sergey.v.basov(a)gmail.com
tel: (+38067) 403-62-54
2016-12-01 10:52 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
> Hello,
>
> have you set modparams for tm module related to reparsing the invite or on
> dns failover?
>
> The build_local() should be used only in some specific cases and want to be
> sure it doesn't get executed somehow when it shouldn't be.
>
> Cheers,
> Daniel
>
>
> On 30/11/2016 16:40, Helio Okuyama 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.
>
> Via: SIP/2.0/TLS
> 173.16.10.61:5061;branch=z9hG4bKc782.5b960c7c48a4363a0126963daa797eb0.0;i=7
> From:
"22861"<sip:22861@173.16.10.61;transport=tls>;tag=snl_OIPEOzJUNy
> Call-ID: 61b500a71b510a1Pj61qq1k9dPW
> To: <sip:551138174108@174.16.4.108:5061;transport=tls>;tag=435012226
> CSeq: 2351 ACKMax-Forwards: 70
>
> User-Agent:...
>
>
> The fix for that seems to be just the order of append_str in function
> build_local() from tm\t_msgbuilder.c.
>
> append_str( p, method, method_len );
> + append_str( p, CRLF, CRLF_LEN );
> append_str( p, MAXFWD_HEADER, MAXFWD_HEADER_LEN );
> - append_str( p, CRLF, CRLF_LEN );
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
2713
days inactive
2714
days old
7 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Helio Okuyama -
Mikko Lehto -
Sergey Basov