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 );
Helio Okuyama hok.sh10@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.
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@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@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 ..
On 01/12/2016 02:05, Mikko Lehto wrote:
Helio Okuyama hok.sh10@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.
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
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 miconda@gmail.com:
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.com
tel: (+38067) 403-62-54
2016-12-01 10:52 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.com
tel: (+38067) 403-62-54
2016-12-01 10:52 GMT+02:00 Daniel-Constantin Mierla miconda@gmail.com:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Helio Okuyama -
Mikko Lehto -
Sergey Basov