[Kamailio-Users] uac_replace_from check
if i have understood correctly, if uac_replace_from() is called in "auto" mode, encoded from uri is added into an extra param of r-r header when the request is forwarded towards uas. does the module check that reply to the request from uas really includes the added parameter in its r-r header or is correct operation of in-dialog requests at the mercy of the uas? -- juha
Hello Im trying to use the presence X-Lite 3.0 where you can see if the other person is away, on the phone, offline, etc But everytime I run X-Lite I get this error in Kamailio: [7055]: LOG: route 2 [7055]: LOG: R2 - SUBSCRIBE [7055]: ERROR:presence:handle_subscribe: Missing or unsupported event header field value [7055]: ERROR:presence:handle_subscribe: event= message-summary In main routing, I call route 2: if( is_method("PUBLISH|SUBSCRIBE")) route(2); route[2] { log(3, "LOG: route 2 \n"); if (!t_newtran()) { log(3, "LOG: R2 - t_newtran\n"); sl_reply_error(); exit; }; if(is_method("PUBLISH")) { log(3, "LOG: R2 - PUBLISH \n"); handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { log(3, "LOG: R2 - SUBSCRIBE\n"); handle_subscribe(); t_release(); } exit; # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==null) { log(3, "LOG: R2 - PUBLISH \n"); sl_send_reply("404", "Not here"); exit; } return; } What could be missing? Thanks Regards Joao Pereira
Joao Gomes Pereira writes:
But everytime I run X-Lite I get this error in Kamailio:
[7055]: LOG: route 2 [7055]: LOG: R2 - SUBSCRIBE [7055]: ERROR:presence:handle_subscribe: Missing or unsupported event header field value [7055]: ERROR:presence:handle_subscribe: event= message-summary
check with ngrep or wireshark how the subscribe message looks like. also check that you have loaded presence_mwi.so module. -- juha
I didn't knew this module was necessary. I was just using presence.so or presence_xml.so I have to compile it and I will try it. Thanks a lot Joao Pereira Juha Heinanen wrote:
Joao Gomes Pereira writes:
But everytime I run X-Lite I get this error in Kamailio:
[7055]: LOG: route 2 [7055]: LOG: R2 - SUBSCRIBE [7055]: ERROR:presence:handle_subscribe: Missing or unsupported event header field value [7055]: ERROR:presence:handle_subscribe: event= message-summary
check with ngrep or wireshark how the subscribe message looks like. also check that you have loaded presence_mwi.so module.
-- juha
-- StarTel - A Rede Livre Joao Gomes Pereira www.startel.pt +351 304500650 sip: gomespereira@startel.pt
Now I have "presence_mwi.so" module, but the presence ( busy, on the phone, idle ) isnt working. The only error Im getting is this (when I do logout with X-Lite): [20800]: ERROR:presence:get_stored_info: record not found in hash_table [20800]: ERROR:presence:handle_subscribe: getting stored info Here is the code: if( is_method("PUBLISH|SUBSCRIBE")) route(2); route[2] { log(3, "LOG: route 2 \n"); if (!t_newtran()) { log(3, "LOG: R2 - t_newtran\n"); sl_reply_error(); exit; }; if(is_method("PUBLISH")) { log(3, "LOG: R2 - PUBLISH \n"); handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { log(3, "LOG: R2 - SUBSCRIBE\n"); handle_subscribe(); t_release(); } exit; # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==null) { log(3, "LOG: R2 - PUBLISH \n"); sl_send_reply("404", "Not here"); exit; } return; } Thanks Regards Joao Pereira Joao Gomes Pereira wrote:
I didn't knew this module was necessary. I was just using presence.so or presence_xml.so
I have to compile it and I will try it. Thanks a lot Joao Pereira
Juha Heinanen wrote:
Joao Gomes Pereira writes:
But everytime I run X-Lite I get this error in Kamailio:
[7055]: LOG: route 2 [7055]: LOG: R2 - SUBSCRIBE [7055]: ERROR:presence:handle_subscribe: Missing or unsupported event header field value [7055]: ERROR:presence:handle_subscribe: event= message-summary
check with ngrep or wireshark how the subscribe message looks like. also check that you have loaded presence_mwi.so module.
-- juha
-- StarTel - A Rede Livre Joao Gomes Pereira www.startel.pt +351 304500650 sip: gomespereira@startel.pt
Joao Gomes Pereira writes:
Now I have "presence_mwi.so" module, but the presence ( busy, on the phone, idle ) isnt working.
The only error Im getting is this (when I do logout with X-Lite):
[20800]: ERROR:presence:get_stored_info: record not found in hash_table [20800]: ERROR:presence:handle_subscribe: getting stored info
i have no experience with xlite. start from scratch (empty records in presence tables, restart kamailio) and then start a sip ua that sends a publish request and another that subscribes to it. -- juha
Juha Heinanen writes:
does the module check that reply to the request from uas really includes the added parameter in its r-r header or is correct operation of in-dialog requests at the mercy of the uas?
answering to myself, i read the source code and looks like restore_from_reply function does not check that the r-r param that was added when request was processed, was copied by uas to the reply or that the reply contains the r-r header that the proxy added to the request. isn't this a security risk? even without the from replacing business, shouldn't proxy ALWAYS check that the reply contains the r-r header that it added? if it does not, the uac can be fooled to send in-dialog requests to somewhere else (unless it is configured to always use this proxy as its next hop). so if proxy receives a request that contains a (possibly missing) r-r header: r-r: a,b and it adds itself (c) there r-r: a,b,c when reply comes back, shouldn't the proxy check that the r-r header in the reply starts with r-r: a,b,c if not, what am i missing here? -- juha
Hello Juha, On 04/01/2009 10:05 AM, Juha Heinanen wrote:
Juha Heinanen writes:
does the module check that reply to the request from uas really includes the added parameter in its r-r header or is correct operation of in-dialog requests at the mercy of the uas?
answering to myself, i read the source code and looks like restore_from_reply function does not check that the r-r param that was added when request was processed, was copied by uas to the reply or that the reply contains the r-r header that the proxy added to the request.
isn't this a security risk? even without the from replacing business, shouldn't proxy ALWAYS check that the reply contains the r-r header that it added? if it does not, the uac can be fooled to send in-dialog requests to somewhere else (unless it is configured to always use this proxy as its next hop).
so if proxy receives a request that contains a (possibly missing) r-r header:
r-r: a,b
and it adds itself (c) there
r-r: a,b,c
when reply comes back, shouldn't the proxy check that the r-r header in the reply starts with
r-r: a,b,c
if not, what am i missing here?
Indeed, there can be an extra check there. Not sure how much protection it adds here. When X calls Y, if caller is trusted (e.g., auth user, trusted peer) then either call goes to costly resource (PSTN) that is also trusted, to a local user or untrusted destination, case in which you route only if does not cost you anything. If local users are not trustable and use "custom UA", then replies can go to first Via, skipping the rest of Via stack, ignoring negative replies after 200ok. Unless there is symmetric nat and they are forced to use the proxy, the safest will be a b2bua. Say you get a 200OK to an INVITE with spoofed r-r, should it be dropped? Cheers, Daniel -- Daniel-Constantin Mierla
Daniel-Constantin Mierla writes:
Indeed, there can be an extra check there. Not sure how much protection it adds here. When X calls Y, if caller is trusted (e.g., auth user, trusted peer) then either call goes to costly resource (PSTN) that is also trusted, to a local user or untrusted destination, case in which you route only if does not cost you anything. If local users are not trustable and use "custom UA", then replies can go to first Via, skipping the rest of Via stack, ignoring negative replies after 200ok. Unless there is symmetric nat and they are forced to use the proxy, the safest will be a b2bua.
i don't understand, how the above relates to the security issue that i brought up. it has nothing to do with cost, but a possibility to make uac send in-dialog requests so that they by-pass the proxy. nasty things documented earlier can happen if that is not prevented.
Say you get a 200OK to an INVITE with spoofed r-r, should it be dropped?
definitely yes. there could, for example, be a flag that tells if the check needs to be done, so that you don't waste resources needlessly if uas is trusted. -- juha
Juha Heinanen writes:
definitely yes. there could, for example, be a flag that tells if the check needs to be done, so that you don't waste resources needlessly if uas is trusted.
another possibility might be to write a new function into rr module check_rr_header() that could be called in reply_route and that would make the check that i proposed earlier. -- juha
On 04/01/2009 01:56 PM, Juha Heinanen wrote:
Juha Heinanen writes:
definitely yes. there could, for example, be a flag that tells if the check needs to be done, so that you don't waste resources needlessly if uas is trusted.
another possibility might be to write a new function into rr module
check_rr_header()
that could be called in reply_route and that would make the check that i proposed earlier.
ok, as it has to check the uac buffer from the branch of transaction, needs to bind to tm. Cheers, Daniel -- Daniel-Constantin Mierla
On 04/01/2009 01:35 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Indeed, there can be an extra check there. Not sure how much protection it adds here. When X calls Y, if caller is trusted (e.g., auth user, trusted peer) then either call goes to costly resource (PSTN) that is also trusted, to a local user or untrusted destination, case in which you route only if does not cost you anything. If local users are not trustable and use "custom UA", then replies can go to first Via, skipping the rest of Via stack, ignoring negative replies after 200ok. Unless there is symmetric nat and they are forced to use the proxy, the safest will be a b2bua.
i don't understand, how the above relates to the security issue that i brought up. it has nothing to do with cost, but a possibility to make uac send in-dialog requests so that they by-pass the proxy. nasty things documented earlier can happen if that is not prevented.
I meant protection so that proxy does not lose control of the call. If proper R-R processing according to specs is avoided on purpose or not by UA, it is hard to correct something on a proxy.
Say you get a 200OK to an INVITE with spoofed r-r, should it be dropped?
definitely yes. there could, for example, be a flag that tells if the check needs to be done, so that you don't waste resources needlessly if uas is trusted.
It is more complex that it looks, proper ending in that stage will be: - drop 200ok - send negative reply upstream - ack downstream - bye downstream - catch 200ok for by If simply drop te 200ok, there will be retransmission flowing around. Cheers, Daniel -- Daniel-Constantin Mierla
Daniel-Constantin Mierla writes:
It is more complex that it looks, proper ending in that stage will be: - drop 200ok - send negative reply upstream - ack downstream - bye downstream - catch 200ok for by
If simply drop te 200ok, there will be retransmission flowing around.
yes, it is not simple, but should be done anyway. what does proxy currently do, when it receives a malformed reply that fails parsing and cannot be forward to uac? i consider incorrect r-r header to be the same case. if the proxy is able to handle the former, it should be able to handle the latter. -- juha
Hello, I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem. But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header... Any idea? What did I forget? Olivier
Hello, On 04.11.2009 11:58 Uhr, olivier.taylor@gmail.com wrote:
Hello,
I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem.
But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header...
Any idea? What did I forget?
if you do record routing and the bye from callee does not have it, then seems to be a broken UA at the callee side. Have you tried with different UAs? Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/
Hi Daniel, long time, I am on Kamailio(1.5) now :) ok, first of all, sorry I forgot the record-route :(( Now I have it, but the proxy doenst do anything when the Bye arrives from the callee. What action do I have to take if any? What I receive for the BYE: BYE sip:997321079@xxx.xxx.67.183:5060 SIP/2.0. Via: SIP/2.0/UDP yyy.yyy.123.88:5060;branch=z9hG4bK4dd17330;rport. Route: <sip:0485336302@yyy.yyy.123.83:5060;nat=yes;ftag=5672;lr=on>,<sip:xxx.xxx.67.183;lr=on;ftag=5672;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWhhVSzE4Mw-->. From: <sip:0485336302@xxx.xxx.67.183>;tag=as3e2ef419. To: "997321079" <sip:997321073@my.be>;tag=5672. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324791-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 70. Content-Length: 0. Daniel-Constantin Mierla a écrit :
Hello,
On 04.11.2009 11:58 Uhr, olivier.taylor@gmail.com wrote:
Hello,
I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem.
But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header...
Any idea? What did I forget?
if you do record routing and the bye from callee does not have it, then seems to be a broken UA at the callee side.
Have you tried with different UAs?
Cheers, Daniel
Hello Olivier, On 04.11.2009 12:25 Uhr, olivier.taylor@gmail.com wrote:
Hi Daniel, long time, I am on Kamailio(1.5) now :) not for long time :-) , 3.0 is around the corner...
ok, first of all, sorry I forgot the record-route :(( Now I have it, but the proxy doenst do anything when the Bye arrives from the callee. What action do I have to take if any?
You have to do loose_route() and if true then relay. The default config file has sample routing of in-dialog requests (when to tag is set). Cheers, Daniel
What I receive for the BYE:
BYE sip:997321079@xxx.xxx.67.183:5060 SIP/2.0. Via: SIP/2.0/UDP yyy.yyy.123.88:5060;branch=z9hG4bK4dd17330;rport. Route: <sip:0485336302@yyy.yyy.123.83:5060;nat=yes;ftag=5672;lr=on>,<sip:xxx.xxx.67.183;lr=on;ftag=5672;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWhhVSzE4Mw-->.
From: <sip:0485336302@xxx.xxx.67.183>;tag=as3e2ef419. To: "997321079" <sip:997321073@my.be>;tag=5672. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324791-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 70. Content-Length: 0.
Daniel-Constantin Mierla a écrit :
Hello,
On 04.11.2009 11:58 Uhr, olivier.taylor@gmail.com wrote:
Hello,
I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem.
But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header...
Any idea? What did I forget?
if you do record routing and the bye from callee does not have it, then seems to be a broken UA at the callee side.
Have you tried with different UAs?
Cheers, Daniel
-- Daniel-Constantin Mierla * http://www.asipto.com/
hi again, now I get a ERROR:tm:sip_msg_cloner: no more share memory on loose-route... I must say GRRR ;) Olivier Daniel-Constantin Mierla a écrit :
Hello Olivier,
On 04.11.2009 12:25 Uhr, olivier.taylor@gmail.com wrote:
Hi Daniel, long time, I am on Kamailio(1.5) now :) not for long time :-) , 3.0 is around the corner...
ok, first of all, sorry I forgot the record-route :(( Now I have it, but the proxy doenst do anything when the Bye arrives from the callee. What action do I have to take if any?
You have to do loose_route() and if true then relay. The default config file has sample routing of in-dialog requests (when to tag is set).
Cheers, Daniel
What I receive for the BYE:
BYE sip:997321079@xxx.xxx.67.183:5060 SIP/2.0. Via: SIP/2.0/UDP yyy.yyy.123.88:5060;branch=z9hG4bK4dd17330;rport. Route: <sip:0485336302@yyy.yyy.123.83:5060;nat=yes;ftag=5672;lr=on>,<sip:xxx.xxx.67.183;lr=on;ftag=5672;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWhhVSzE4Mw-->.
From: <sip:0485336302@xxx.xxx.67.183>;tag=as3e2ef419. To: "997321079" <sip:997321073@my.be>;tag=5672. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324791-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 70. Content-Length: 0.
Daniel-Constantin Mierla a écrit :
Hello,
On 04.11.2009 11:58 Uhr, olivier.taylor@gmail.com wrote:
Hello,
I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem.
But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header...
Any idea? What did I forget?
if you do record routing and the bye from callee does not have it, then seems to be a broken UA at the callee side.
Have you tried with different UAs?
Cheers, Daniel
well, I am lost, but not yet drunk. In fact : I Ihave a kamailio used to receive calls from an IP with no identification. I detect the IP, query the DB to know who have to be billed. Then I use uac_replace_from and also uac_auth to have the caller authorisation on the main server. No problems to setup the call. the only problem is the hangup when the callee send a BYE, the BYE is never forwarded to the caller... Here is my cfg # ------------------ module loading ---------------------------------- mpath="/usr/local/lib/kamailio/modules/" loadmodule "avpops.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "rr.so" modparam("rr", "enable_full_lr", 1) loadmodule "tm.so" loadmodule "uac.so" modparam("uac","credential","username:domain:password") modparam("uac", "auth_username_avp", "$avp(i:1)") modparam("uac", "auth_password_avp", "$avp(i:2)") modparam("uac","auth_realm_avp","$avp(i:3)") modparam("uac","from_restore_mode","auto") modparam("uac","rr_store_param","my_param") modparam("uac","from_passwd","") # for testing purpose loadmodule "db_mysql.so" modparam("avpops","db_url","mysql://openser:openserrw@sql.XXX.be/openser") modparam("avpops","avp_table","preferences") modparam("avpops","attribute_column","pref_name") modparam("avpops","value_column","pref_value") modparam("avpops","uuid_column","pref_id") # ----------------- setting module-specific parameters --------------- # -- tm params -- # set time for which ser will be waiting for a final response; # fr_inv_timer sets value for INVITE transactions, fr_timer # for all others #modparam("tm", "fr_inv_timer", 15 ) #modparam("tm", "fr_timer", 10 ) # ------------------------- request routing logic ------------------- # main routing logic route{ # for testing purposes, simply okay all REGISTERs if (method=="REGISTER") { log("REGISTER"); sl_send_reply("200", "ok"); exit; }; if (is_method("INVITE")) { record_route(); uac_replace_from("sip:997321073@xxxxxx.be"); rewritehost("xxxxxx.be"); } if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); t_relay(); if (!t_relay()) { sl_reply_error(); } exit; } } } t_on_failure("1"); t_relay(); } failure_route[1] { if (t_check_status("407")) { avp_db_query("SELECT username, password, 'finalcut.be' FROM subscriber WHERE username = 'zzzzzzzz'", "$avp(i:1);$avp(i:2);$avp(i:3)"); uac_auth(); append_branch(); t_relay(); } }
hello, do you have bit shared memory consumers? e.g., many records in user location, lot of traffic... if yes, increase the shared memory size via command line parameter: -m 128 The value is in megabytes. Cheers, Daniel On 04.11.2009 13:04 Uhr, olivier.taylor@gmail.com wrote:
hi again,
now I get a ERROR:tm:sip_msg_cloner: no more share memory on loose-route...
I must say GRRR ;)
Olivier
Daniel-Constantin Mierla a écrit :
Hello Olivier,
On 04.11.2009 12:25 Uhr, olivier.taylor@gmail.com wrote:
Hi Daniel, long time, I am on Kamailio(1.5) now :) not for long time :-) , 3.0 is around the corner...
ok, first of all, sorry I forgot the record-route :(( Now I have it, but the proxy doenst do anything when the Bye arrives from the callee. What action do I have to take if any?
You have to do loose_route() and if true then relay. The default config file has sample routing of in-dialog requests (when to tag is set).
Cheers, Daniel
What I receive for the BYE:
BYE sip:997321079@xxx.xxx.67.183:5060 SIP/2.0. Via: SIP/2.0/UDP yyy.yyy.123.88:5060;branch=z9hG4bK4dd17330;rport. Route: <sip:0485336302@yyy.yyy.123.83:5060;nat=yes;ftag=5672;lr=on>,<sip:xxx.xxx.67.183;lr=on;ftag=5672;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWhhVSzE4Mw-->.
From: <sip:0485336302@xxx.xxx.67.183>;tag=as3e2ef419. To: "997321079" <sip:997321073@my.be>;tag=5672. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324791-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 70. Content-Length: 0.
Daniel-Constantin Mierla a écrit :
Hello,
On 04.11.2009 11:58 Uhr, olivier.taylor@gmail.com wrote:
Hello,
I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem.
But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header...
Any idea? What did I forget?
if you do record routing and the bye from callee does not have it, then seems to be a broken UA at the callee side.
Have you tried with different UAs?
Cheers, Daniel
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla * http://www.asipto.com/
have done that :) it seems I have a loop somewhere and the shm is fastly out :( Olivier Daniel-Constantin Mierla a écrit :
hello,
do you have bit shared memory consumers? e.g., many records in user location, lot of traffic... if yes, increase the shared memory size via command line parameter: -m 128
The value is in megabytes.
Cheers, Daniel
On 04.11.2009 13:04 Uhr, olivier.taylor@gmail.com wrote:
hi again,
now I get a ERROR:tm:sip_msg_cloner: no more share memory on loose-route...
I must say GRRR ;)
Olivier
Daniel-Constantin Mierla a écrit :
Hello Olivier,
On 04.11.2009 12:25 Uhr, olivier.taylor@gmail.com wrote:
Hi Daniel, long time, I am on Kamailio(1.5) now :) not for long time :-) , 3.0 is around the corner...
ok, first of all, sorry I forgot the record-route :(( Now I have it, but the proxy doenst do anything when the Bye arrives from the callee. What action do I have to take if any?
You have to do loose_route() and if true then relay. The default config file has sample routing of in-dialog requests (when to tag is set).
Cheers, Daniel
What I receive for the BYE:
BYE sip:997321079@xxx.xxx.67.183:5060 SIP/2.0. Via: SIP/2.0/UDP yyy.yyy.123.88:5060;branch=z9hG4bK4dd17330;rport. Route: <sip:0485336302@yyy.yyy.123.83:5060;nat=yes;ftag=5672;lr=on>,<sip:xxx.xxx.67.183;lr=on;ftag=5672;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWhhVSzE4Mw-->.
From: <sip:0485336302@xxx.xxx.67.183>;tag=as3e2ef419. To: "997321079" <sip:997321073@my.be>;tag=5672. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324791-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 70. Content-Length: 0.
Daniel-Constantin Mierla a écrit :
Hello,
On 04.11.2009 11:58 Uhr, olivier.taylor@gmail.com wrote:
Hello,
I use uac_replace_from to setup a call and everythings are ok. When the caller send a Bye, no problem. When the caller send a CANCEL, no problem.
But when callee send a BYE to stop the call after the call has been setup, the bye is never sent back to caller... I also don't see any record-route header...
Any idea? What did I forget?
if you do record routing and the bye from callee does not have it, then seems to be a broken UA at the callee side.
Have you tried with different UAs?
Cheers, Daniel
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
well, I am lost, but not yet drunk. In fact : I Ihave a kamailio used to receive calls from an IP with no identification. I detect the IP, query the DB to know who have to be billed. Then I use uac_replace_from and also uac_auth to have the caller authorisation on the main server. No problems to setup the call. the only problem is the hangup when the callee send a BYE, the BYE is never forwarded to the caller... Here is my cfg # ------------------ module loading ---------------------------------- mpath="/usr/local/lib/kamailio/modules/" loadmodule "avpops.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "rr.so" modparam("rr", "enable_full_lr", 1) loadmodule "tm.so" loadmodule "uac.so" modparam("uac","credential","username:domain:password") modparam("uac", "auth_username_avp", "$avp(i:1)") modparam("uac", "auth_password_avp", "$avp(i:2)") modparam("uac","auth_realm_avp","$avp(i:3)") modparam("uac","from_restore_mode","auto") modparam("uac","rr_store_param","my_param") modparam("uac","from_passwd","") # for testing purpose loadmodule "db_mysql.so" modparam("avpops","db_url","mysql://openser:openserrw@sql.XXX.be/openser") modparam("avpops","avp_table","preferences") modparam("avpops","attribute_column","pref_name") modparam("avpops","value_column","pref_value") modparam("avpops","uuid_column","pref_id") # ----------------- setting module-specific parameters --------------- # -- tm params -- # set time for which ser will be waiting for a final response; # fr_inv_timer sets value for INVITE transactions, fr_timer # for all others #modparam("tm", "fr_inv_timer", 15 ) #modparam("tm", "fr_timer", 10 ) # ------------------------- request routing logic ------------------- # main routing logic route{ # for testing purposes, simply okay all REGISTERs if (method=="REGISTER") { log("REGISTER"); sl_send_reply("200", "ok"); exit; }; if (is_method("INVITE")) { record_route(); uac_replace_from("sip:997321073@xxxxxx.be"); rewritehost("xxxxxx.be"); } if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); t_relay(); if (!t_relay()) { sl_reply_error(); } exit; } } } t_on_failure("1"); t_relay(); } failure_route[1] { if (t_check_status("407")) { avp_db_query("SELECT username, password, 'finalcut.be' FROM subscriber WHERE username = 'zzzzzzzz'", "$avp(i:1);$avp(i:2);$avp(i:3)"); uac_auth(); append_branch(); t_relay(); } }
if (is_method("INVITE")) { record_route(); uac_replace_from("sip:997321073@xxxxxx.be"); rewritehost("xxxxxx.be"); }
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); t_relay();
I think there are too many t_relay(). Just one will suffice. if(has_totag()){ if(is_method("BYE")){ xlog(......); } t_relay(); #relay all in-dialog messages (also BYEs) exit; } Can you try with smth like this? Cheers Marius
doing that, I get a loop :( if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; } seems that kamailio is sending the request back to himself... Thanks anyway Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29730]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29735]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29735]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29730]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29729]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29728]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29734]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29735]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29729]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29728]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29734]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29734]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29730]: ------------------> LOOSE route marius zbihlei a écrit :
if (is_method("INVITE")) { record_route(); uac_replace_from("sip:997321073@xxxxxx.be"); rewritehost("xxxxxx.be"); }
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); t_relay();
I think there are too many t_relay(). Just one will suffice. if(has_totag()){ if(is_method("BYE")){ xlog(......); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
Can you try with smth like this?
Cheers Marius
On 04.11.2009 15:32 Uhr, olivier.taylor@gmail.com wrote:
doing that, I get a loop :(
if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; } you need to do loose_route() for BYE, otherwise the Route header is not consumed.
Cheers, Daniel
seems that kamailio is sending the request back to himself...
Thanks anyway
Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29730]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29735]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29735]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29730]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29729]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29728]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29734]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29735]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29729]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29728]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29734]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29734]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29731]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29733]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29732]: ------------------> LOOSE route Nov 4 17:21:53 localhost /usr/local/sbin/kamailio[29730]: ------------------> LOOSE route
marius zbihlei a écrit :
if (is_method("INVITE")) { record_route(); uac_replace_from("sip:997321073@xxxxxx.be"); rewritehost("xxxxxx.be"); }
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); t_relay();
I think there are too many t_relay(). Just one will suffice. if(has_totag()){ if(is_method("BYE")){ xlog(......); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
Can you try with smth like this?
Cheers Marius
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla * http://www.asipto.com/
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
doing that, I get a loop :(
if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
seems that kamailio is sending the request back to himself...
Oliver, why don't you check and study the default config file please?
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
dear Iñaki
I have a server up and running at this time, my only problem is when I use uac_replace_from and receive a Bye from the callee. That's for another server. The default config doesn't help for that, or maybe I am stupid, that's another possibility :)
Your code is not correct: if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; } You must use loose_route() before the t_relay(). If not the Route header are not removed so you get a loop. This is well explained in the default config file.
your message is very helpfull, thanks,
Thanks.
On 04.11.2009 16:54 Uhr, olivier.taylor@gmail.com wrote:
If you follow the thread, you will see that I was using :
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); if (!t_relay()) { sl_reply_error(); } exit; } } }
and not if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
Wich was proposed by another user...
Anyway, using that, I get :
Nov 4 18:48:37 localhost /usr/local/sbin/kamailio[30514]: ------------------> LOOSE route Nov 4 18:48:38 localhost /usr/local/sbin/kamailio[30511]: ------------------> LOOSE route Nov 4 18:48:40 localhost /usr/local/sbin/kamailio[30514]: ------------------> LOOSE route Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
What is the max datagram size in your system? Are you using freebsd? 'sysctl -a' to see all and search for inet or ipv4 and dgram or so ... Cheers, Daniel
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:tm:msg_send: udp_send failed Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:tm:t_forward_nonack: sending request failed Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30516]: ------------------> LOOSE route Nov 4 18:48:48 localhost /usr/local/sbin/kamailio[30513]: ------------------> LOOSE route Nov 4 18:48:50 localhost /usr/local/sbin/kamailio[30513]: ------------------> LOOSE route Nov 4 18:48:52 localhost /usr/local/sbin/kamailio[30512]: ------------------> LOOSE route
and so on...
Then, using Loose-route doesn't help.
I am sure I made a mistake somewhere, but I don't know where.
In the previous mail you will find my full CFG
kind regards,
Olivier
Iñaki Baz Castillo a écrit :
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
dear Iñaki
I have a server up and running at this time, my only problem is when I use uac_replace_from and receive a Bye from the callee. That's for another server. The default config doesn't help for that, or maybe I am stupid, that's another possibility :)
Your code is not correct:
if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
You must use loose_route() before the t_relay(). If not the Route header are not removed so you get a loop. This is well explained in the default config file.
your message is very helpfull, thanks,
Thanks.
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla * http://www.asipto.com/
centos 5.3 new install sysctl -a | grep dgram net.unix.max_dgram_qlen = 10 sysctl -a | grep inet net.ipv4.inet_peer_gc_maxtime = 120 net.ipv4.inet_peer_gc_mintime = 10 net.ipv4.inet_peer_maxttl = 600 net.ipv4.inet_peer_minttl = 120 net.ipv4.inet_peer_threshold = 65664 sysctl -a | grep ipv4 net.ipv4.conf.eth0.promote_secondaries = 0 net.ipv4.conf.eth0.force_igmp_version = 0 net.ipv4.conf.eth0.disable_policy = 0 net.ipv4.conf.eth0.disable_xfrm = 0 net.ipv4.conf.eth0.arp_accept = 0 net.ipv4.conf.eth0.arp_ignore = 0 net.ipv4.conf.eth0.arp_announce = 0 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.tag = 0 net.ipv4.conf.eth0.log_martians = 0 net.ipv4.conf.eth0.bootp_relay = 0 net.ipv4.conf.eth0.medium_id = 0 net.ipv4.conf.eth0.proxy_arp = 0 net.ipv4.conf.eth0.accept_source_route = 0 net.ipv4.conf.eth0.send_redirects = 1 net.ipv4.conf.eth0.rp_filter = 1 net.ipv4.conf.eth0.shared_media = 1 net.ipv4.conf.eth0.secure_redirects = 1 net.ipv4.conf.eth0.accept_redirects = 1 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.eth0.forwarding = 0 net.ipv4.conf.lo.promote_secondaries = 0 net.ipv4.conf.lo.force_igmp_version = 0 net.ipv4.conf.lo.disable_policy = 1 net.ipv4.conf.lo.disable_xfrm = 1 net.ipv4.conf.lo.arp_accept = 0 net.ipv4.conf.lo.arp_ignore = 0 net.ipv4.conf.lo.arp_announce = 0 net.ipv4.conf.lo.arp_filter = 0 net.ipv4.conf.lo.tag = 0 net.ipv4.conf.lo.log_martians = 0 net.ipv4.conf.lo.bootp_relay = 0 net.ipv4.conf.lo.medium_id = 0 net.ipv4.conf.lo.proxy_arp = 0 net.ipv4.conf.lo.accept_source_route = 1 net.ipv4.conf.lo.send_redirects = 1 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.lo.shared_media = 1 net.ipv4.conf.lo.secure_redirects = 1 net.ipv4.conf.lo.accept_redirects = 1 net.ipv4.conf.lo.mc_forwarding = 0 net.ipv4.conf.lo.forwarding = 0 net.ipv4.conf.default.promote_secondaries = 0 net.ipv4.conf.default.force_igmp_version = 0 net.ipv4.conf.default.disable_policy = 0 net.ipv4.conf.default.disable_xfrm = 0 net.ipv4.conf.default.arp_accept = 0 net.ipv4.conf.default.arp_ignore = 0 net.ipv4.conf.default.arp_announce = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.default.tag = 0 net.ipv4.conf.default.log_martians = 0 net.ipv4.conf.default.bootp_relay = 0 net.ipv4.conf.default.medium_id = 0 net.ipv4.conf.default.proxy_arp = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.shared_media = 1 net.ipv4.conf.default.secure_redirects = 1 net.ipv4.conf.default.accept_redirects = 1 net.ipv4.conf.default.mc_forwarding = 0 net.ipv4.conf.default.forwarding = 0 net.ipv4.conf.all.promote_secondaries = 0 net.ipv4.conf.all.force_igmp_version = 0 net.ipv4.conf.all.disable_policy = 0 net.ipv4.conf.all.disable_xfrm = 0 net.ipv4.conf.all.arp_accept = 0 net.ipv4.conf.all.arp_ignore = 0 net.ipv4.conf.all.arp_announce = 0 net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.tag = 0 net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.all.bootp_relay = 0 net.ipv4.conf.all.medium_id = 0 net.ipv4.conf.all.proxy_arp = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.send_redirects = 1 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.all.shared_media = 1 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.accept_redirects = 1 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.all.forwarding = 0 net.ipv4.neigh.eth0.base_reachable_time_ms = 30000 net.ipv4.neigh.eth0.retrans_time_ms = 1000 net.ipv4.neigh.eth0.locktime = 99 net.ipv4.neigh.eth0.proxy_delay = 79 net.ipv4.neigh.eth0.anycast_delay = 99 net.ipv4.neigh.eth0.proxy_qlen = 64 net.ipv4.neigh.eth0.unres_qlen = 3 net.ipv4.neigh.eth0.gc_stale_time = 60 net.ipv4.neigh.eth0.delay_first_probe_time = 5 net.ipv4.neigh.eth0.base_reachable_time = 30 net.ipv4.neigh.eth0.retrans_time = 99 net.ipv4.neigh.eth0.app_solicit = 0 net.ipv4.neigh.eth0.ucast_solicit = 3 net.ipv4.neigh.eth0.mcast_solicit = 3 net.ipv4.neigh.lo.base_reachable_time_ms = 30000 net.ipv4.neigh.lo.retrans_time_ms = 1000 net.ipv4.neigh.lo.locktime = 99 net.ipv4.neigh.lo.proxy_delay = 79 net.ipv4.neigh.lo.anycast_delay = 99 net.ipv4.neigh.lo.proxy_qlen = 64 net.ipv4.neigh.lo.unres_qlen = 3 net.ipv4.neigh.lo.gc_stale_time = 60 net.ipv4.neigh.lo.delay_first_probe_time = 5 net.ipv4.neigh.lo.base_reachable_time = 30 net.ipv4.neigh.lo.retrans_time = 99 net.ipv4.neigh.lo.app_solicit = 0 net.ipv4.neigh.lo.ucast_solicit = 3 net.ipv4.neigh.lo.mcast_solicit = 3 net.ipv4.neigh.default.base_reachable_time_ms = 30000 net.ipv4.neigh.default.retrans_time_ms = 1000 net.ipv4.neigh.default.gc_thresh3 = 1024 net.ipv4.neigh.default.gc_thresh2 = 512 net.ipv4.neigh.default.gc_thresh1 = 128 net.ipv4.neigh.default.gc_interval = 30 net.ipv4.neigh.default.locktime = 99 net.ipv4.neigh.default.proxy_delay = 79 net.ipv4.neigh.default.anycast_delay = 99 net.ipv4.neigh.default.proxy_qlen = 64 net.ipv4.neigh.default.unres_qlen = 3 net.ipv4.neigh.default.gc_stale_time = 60 net.ipv4.neigh.default.delay_first_probe_time = 5 net.ipv4.neigh.default.base_reachable_time = 30 net.ipv4.neigh.default.retrans_time = 99 net.ipv4.neigh.default.app_solicit = 0 net.ipv4.neigh.default.ucast_solicit = 3 net.ipv4.neigh.default.mcast_solicit = 3 net.ipv4.udp_wmem_min = 4096 net.ipv4.udp_rmem_min = 4096 net.ipv4.udp_mem = 195552 260736 391104 net.ipv4.cipso_rbm_strictvalid = 1 net.ipv4.cipso_rbm_optfmt = 0 net.ipv4.cipso_cache_bucket_size = 10 net.ipv4.cipso_cache_enable = 1 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_dma_copybreak = 4096 net.ipv4.tcp_workaround_signed_windows = 0 net.ipv4.tcp_base_mss = 512 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_abc = 0 net.ipv4.tcp_congestion_control = bic net.ipv4.tcp_tso_win_divisor = 3 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.ipfrag_max_dist = 64 net.ipv4.ipfrag_secret_interval = 600 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_frto = 0 net.ipv4.tcp_tw_reuse = 0 net.ipv4.icmp_ratemask = 6168 net.ipv4.icmp_ratelimit = 1000 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_app_win = 31 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_wmem = 4096 16384 4194304 net.ipv4.tcp_mem = 98304 131072 196608 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_ecn = 0 net.ipv4.tcp_reordering = 3 net.ipv4.tcp_fack = 1 net.ipv4.tcp_orphan_retries = 0 net.ipv4.inet_peer_gc_maxtime = 120 net.ipv4.inet_peer_gc_mintime = 10 net.ipv4.inet_peer_maxttl = 600 net.ipv4.inet_peer_minttl = 120 net.ipv4.inet_peer_threshold = 65664 net.ipv4.igmp_max_msf = 10 net.ipv4.igmp_max_memberships = 20 net.ipv4.route.rt_cache_rebuild_count = 4 net.ipv4.route.secret_interval = 600 net.ipv4.route.min_adv_mss = 256 net.ipv4.route.min_pmtu = 552 net.ipv4.route.mtu_expires = 600 net.ipv4.route.gc_elasticity = 8 net.ipv4.route.error_burst = 5000 net.ipv4.route.error_cost = 1000 net.ipv4.route.redirect_silence = 20480 net.ipv4.route.redirect_number = 9 net.ipv4.route.redirect_load = 20 net.ipv4.route.gc_interval = 60 net.ipv4.route.gc_timeout = 300 net.ipv4.route.gc_min_interval_ms = 500 net.ipv4.route.gc_min_interval = 0 net.ipv4.route.max_size = 524288 net.ipv4.route.gc_thresh = 32768 net.ipv4.route.max_delay = 10 net.ipv4.route.min_delay = 2 net.ipv4.icmp_errors_use_inbound_ifaddr = 0 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_echo_ignore_all = 0 net.ipv4.ip_local_port_range = 32768 61000 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_rfc1337 = 0 net.ipv4.tcp_stdurg = 0 net.ipv4.tcp_abort_on_overflow = 0 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_fin_timeout = 60 net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200 net.ipv4.ipfrag_time = 30 net.ipv4.ip_dynaddr = 0 net.ipv4.ipfrag_low_thresh = 196608 net.ipv4.ipfrag_high_thresh = 262144 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_max_orphans = 32768 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syn_retries = 5 net.ipv4.ip_nonlocal_bind = 0 net.ipv4.ip_no_pmtu_disc = 0 net.ipv4.ip_default_ttl = 64 net.ipv4.ip_forward = 0 net.ipv4.tcp_retrans_collapse = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 Daniel-Constantin Mierla a écrit :
On 04.11.2009 16:54 Uhr, olivier.taylor@gmail.com wrote:
If you follow the thread, you will see that I was using :
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); if (!t_relay()) { sl_reply_error(); } exit; } } }
and not if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
Wich was proposed by another user...
Anyway, using that, I get :
Nov 4 18:48:37 localhost /usr/local/sbin/kamailio[30514]: ------------------> LOOSE route Nov 4 18:48:38 localhost /usr/local/sbin/kamailio[30511]: ------------------> LOOSE route Nov 4 18:48:40 localhost /usr/local/sbin/kamailio[30514]: ------------------> LOOSE route Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
What is the max datagram size in your system? Are you using freebsd? 'sysctl -a' to see all and search for inet or ipv4 and dgram or so ...
Cheers, Daniel
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:tm:msg_send: udp_send failed Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:tm:t_forward_nonack: sending request failed Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30516]: ------------------> LOOSE route Nov 4 18:48:48 localhost /usr/local/sbin/kamailio[30513]: ------------------> LOOSE route Nov 4 18:48:50 localhost /usr/local/sbin/kamailio[30513]: ------------------> LOOSE route Nov 4 18:48:52 localhost /usr/local/sbin/kamailio[30512]: ------------------> LOOSE route
and so on...
Then, using Loose-route doesn't help.
I am sure I made a mistake somewhere, but I don't know where.
In the previous mail you will find my full CFG
kind regards,
Olivier
Iñaki Baz Castillo a écrit :
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
dear Iñaki
I have a server up and running at this time, my only problem is when I use uac_replace_from and receive a Bye from the callee. That's for another server. The default config doesn't help for that, or maybe I am stupid, that's another possibility :)
Your code is not correct:
if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
You must use loose_route() before the t_relay(). If not the Route header are not removed so you get a loop. This is well explained in the default config file.
your message is very helpfull, thanks,
Thanks.
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
maybe this can help? U xxx.xxx.123.83:5060 -> yyy.yyy.67.183:5060 BYE sip:997321079@yyy.yyy.67.183:5060 SIP/2.0. Record-Route: <sip:xxx.xxx.123.83;ftag=as5f0cc351;lr=on>. Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWhhVSzE4Mw-->. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 16. Content-Length: 0. . # U yyy.yyy.67.183:5060 -> xxx.xxx.123.83:5060 SIP/2.0 477 Send failed (477/TM). Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0. olivier.taylor@gmail.com a écrit :
centos 5.3 new install
sysctl -a | grep dgram net.unix.max_dgram_qlen = 10
sysctl -a | grep inet net.ipv4.inet_peer_gc_maxtime = 120 net.ipv4.inet_peer_gc_mintime = 10 net.ipv4.inet_peer_maxttl = 600 net.ipv4.inet_peer_minttl = 120 net.ipv4.inet_peer_threshold = 65664
sysctl -a | grep ipv4 net.ipv4.conf.eth0.promote_secondaries = 0 net.ipv4.conf.eth0.force_igmp_version = 0 net.ipv4.conf.eth0.disable_policy = 0 net.ipv4.conf.eth0.disable_xfrm = 0 net.ipv4.conf.eth0.arp_accept = 0 net.ipv4.conf.eth0.arp_ignore = 0 net.ipv4.conf.eth0.arp_announce = 0 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.tag = 0 net.ipv4.conf.eth0.log_martians = 0 net.ipv4.conf.eth0.bootp_relay = 0 net.ipv4.conf.eth0.medium_id = 0 net.ipv4.conf.eth0.proxy_arp = 0 net.ipv4.conf.eth0.accept_source_route = 0 net.ipv4.conf.eth0.send_redirects = 1 net.ipv4.conf.eth0.rp_filter = 1 net.ipv4.conf.eth0.shared_media = 1 net.ipv4.conf.eth0.secure_redirects = 1 net.ipv4.conf.eth0.accept_redirects = 1 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.eth0.forwarding = 0 net.ipv4.conf.lo.promote_secondaries = 0 net.ipv4.conf.lo.force_igmp_version = 0 net.ipv4.conf.lo.disable_policy = 1 net.ipv4.conf.lo.disable_xfrm = 1 net.ipv4.conf.lo.arp_accept = 0 net.ipv4.conf.lo.arp_ignore = 0 net.ipv4.conf.lo.arp_announce = 0 net.ipv4.conf.lo.arp_filter = 0 net.ipv4.conf.lo.tag = 0 net.ipv4.conf.lo.log_martians = 0 net.ipv4.conf.lo.bootp_relay = 0 net.ipv4.conf.lo.medium_id = 0 net.ipv4.conf.lo.proxy_arp = 0 net.ipv4.conf.lo.accept_source_route = 1 net.ipv4.conf.lo.send_redirects = 1 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.lo.shared_media = 1 net.ipv4.conf.lo.secure_redirects = 1 net.ipv4.conf.lo.accept_redirects = 1 net.ipv4.conf.lo.mc_forwarding = 0 net.ipv4.conf.lo.forwarding = 0 net.ipv4.conf.default.promote_secondaries = 0 net.ipv4.conf.default.force_igmp_version = 0 net.ipv4.conf.default.disable_policy = 0 net.ipv4.conf.default.disable_xfrm = 0 net.ipv4.conf.default.arp_accept = 0 net.ipv4.conf.default.arp_ignore = 0 net.ipv4.conf.default.arp_announce = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.default.tag = 0 net.ipv4.conf.default.log_martians = 0 net.ipv4.conf.default.bootp_relay = 0 net.ipv4.conf.default.medium_id = 0 net.ipv4.conf.default.proxy_arp = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.shared_media = 1 net.ipv4.conf.default.secure_redirects = 1 net.ipv4.conf.default.accept_redirects = 1 net.ipv4.conf.default.mc_forwarding = 0 net.ipv4.conf.default.forwarding = 0 net.ipv4.conf.all.promote_secondaries = 0 net.ipv4.conf.all.force_igmp_version = 0 net.ipv4.conf.all.disable_policy = 0 net.ipv4.conf.all.disable_xfrm = 0 net.ipv4.conf.all.arp_accept = 0 net.ipv4.conf.all.arp_ignore = 0 net.ipv4.conf.all.arp_announce = 0 net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.tag = 0 net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.all.bootp_relay = 0 net.ipv4.conf.all.medium_id = 0 net.ipv4.conf.all.proxy_arp = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.send_redirects = 1 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.all.shared_media = 1 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.accept_redirects = 1 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.all.forwarding = 0 net.ipv4.neigh.eth0.base_reachable_time_ms = 30000 net.ipv4.neigh.eth0.retrans_time_ms = 1000 net.ipv4.neigh.eth0.locktime = 99 net.ipv4.neigh.eth0.proxy_delay = 79 net.ipv4.neigh.eth0.anycast_delay = 99 net.ipv4.neigh.eth0.proxy_qlen = 64 net.ipv4.neigh.eth0.unres_qlen = 3 net.ipv4.neigh.eth0.gc_stale_time = 60 net.ipv4.neigh.eth0.delay_first_probe_time = 5 net.ipv4.neigh.eth0.base_reachable_time = 30 net.ipv4.neigh.eth0.retrans_time = 99 net.ipv4.neigh.eth0.app_solicit = 0 net.ipv4.neigh.eth0.ucast_solicit = 3 net.ipv4.neigh.eth0.mcast_solicit = 3 net.ipv4.neigh.lo.base_reachable_time_ms = 30000 net.ipv4.neigh.lo.retrans_time_ms = 1000 net.ipv4.neigh.lo.locktime = 99 net.ipv4.neigh.lo.proxy_delay = 79 net.ipv4.neigh.lo.anycast_delay = 99 net.ipv4.neigh.lo.proxy_qlen = 64 net.ipv4.neigh.lo.unres_qlen = 3 net.ipv4.neigh.lo.gc_stale_time = 60 net.ipv4.neigh.lo.delay_first_probe_time = 5 net.ipv4.neigh.lo.base_reachable_time = 30 net.ipv4.neigh.lo.retrans_time = 99 net.ipv4.neigh.lo.app_solicit = 0 net.ipv4.neigh.lo.ucast_solicit = 3 net.ipv4.neigh.lo.mcast_solicit = 3 net.ipv4.neigh.default.base_reachable_time_ms = 30000 net.ipv4.neigh.default.retrans_time_ms = 1000 net.ipv4.neigh.default.gc_thresh3 = 1024 net.ipv4.neigh.default.gc_thresh2 = 512 net.ipv4.neigh.default.gc_thresh1 = 128 net.ipv4.neigh.default.gc_interval = 30 net.ipv4.neigh.default.locktime = 99 net.ipv4.neigh.default.proxy_delay = 79 net.ipv4.neigh.default.anycast_delay = 99 net.ipv4.neigh.default.proxy_qlen = 64 net.ipv4.neigh.default.unres_qlen = 3 net.ipv4.neigh.default.gc_stale_time = 60 net.ipv4.neigh.default.delay_first_probe_time = 5 net.ipv4.neigh.default.base_reachable_time = 30 net.ipv4.neigh.default.retrans_time = 99 net.ipv4.neigh.default.app_solicit = 0 net.ipv4.neigh.default.ucast_solicit = 3 net.ipv4.neigh.default.mcast_solicit = 3 net.ipv4.udp_wmem_min = 4096 net.ipv4.udp_rmem_min = 4096 net.ipv4.udp_mem = 195552 260736 391104 net.ipv4.cipso_rbm_strictvalid = 1 net.ipv4.cipso_rbm_optfmt = 0 net.ipv4.cipso_cache_bucket_size = 10 net.ipv4.cipso_cache_enable = 1 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_dma_copybreak = 4096 net.ipv4.tcp_workaround_signed_windows = 0 net.ipv4.tcp_base_mss = 512 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_abc = 0 net.ipv4.tcp_congestion_control = bic net.ipv4.tcp_tso_win_divisor = 3 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.ipfrag_max_dist = 64 net.ipv4.ipfrag_secret_interval = 600 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_frto = 0 net.ipv4.tcp_tw_reuse = 0 net.ipv4.icmp_ratemask = 6168 net.ipv4.icmp_ratelimit = 1000 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_app_win = 31 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_wmem = 4096 16384 4194304 net.ipv4.tcp_mem = 98304 131072 196608 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_ecn = 0 net.ipv4.tcp_reordering = 3 net.ipv4.tcp_fack = 1 net.ipv4.tcp_orphan_retries = 0 net.ipv4.inet_peer_gc_maxtime = 120 net.ipv4.inet_peer_gc_mintime = 10 net.ipv4.inet_peer_maxttl = 600 net.ipv4.inet_peer_minttl = 120 net.ipv4.inet_peer_threshold = 65664 net.ipv4.igmp_max_msf = 10 net.ipv4.igmp_max_memberships = 20 net.ipv4.route.rt_cache_rebuild_count = 4 net.ipv4.route.secret_interval = 600 net.ipv4.route.min_adv_mss = 256 net.ipv4.route.min_pmtu = 552 net.ipv4.route.mtu_expires = 600 net.ipv4.route.gc_elasticity = 8 net.ipv4.route.error_burst = 5000 net.ipv4.route.error_cost = 1000 net.ipv4.route.redirect_silence = 20480 net.ipv4.route.redirect_number = 9 net.ipv4.route.redirect_load = 20 net.ipv4.route.gc_interval = 60 net.ipv4.route.gc_timeout = 300 net.ipv4.route.gc_min_interval_ms = 500 net.ipv4.route.gc_min_interval = 0 net.ipv4.route.max_size = 524288 net.ipv4.route.gc_thresh = 32768 net.ipv4.route.max_delay = 10 net.ipv4.route.min_delay = 2 net.ipv4.icmp_errors_use_inbound_ifaddr = 0 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_echo_ignore_all = 0 net.ipv4.ip_local_port_range = 32768 61000 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_rfc1337 = 0 net.ipv4.tcp_stdurg = 0 net.ipv4.tcp_abort_on_overflow = 0 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_fin_timeout = 60 net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200 net.ipv4.ipfrag_time = 30 net.ipv4.ip_dynaddr = 0 net.ipv4.ipfrag_low_thresh = 196608 net.ipv4.ipfrag_high_thresh = 262144 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_max_orphans = 32768 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syn_retries = 5 net.ipv4.ip_nonlocal_bind = 0 net.ipv4.ip_no_pmtu_disc = 0 net.ipv4.ip_default_ttl = 64 net.ipv4.ip_forward = 0 net.ipv4.tcp_retrans_collapse = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1
Daniel-Constantin Mierla a écrit :
On 04.11.2009 16:54 Uhr, olivier.taylor@gmail.com wrote:
If you follow the thread, you will see that I was using :
if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { xlog("L_NOTICE", "------------------> LOOSE route"); if (!t_relay()) { sl_reply_error(); } exit; } } }
and not if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
Wich was proposed by another user...
Anyway, using that, I get :
Nov 4 18:48:37 localhost /usr/local/sbin/kamailio[30514]: ------------------> LOOSE route Nov 4 18:48:38 localhost /usr/local/sbin/kamailio[30511]: ------------------> LOOSE route Nov 4 18:48:40 localhost /usr/local/sbin/kamailio[30514]: ------------------> LOOSE route Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
What is the max datagram size in your system? Are you using freebsd? 'sysctl -a' to see all and search for inet or ipv4 and dgram or so ...
Cheers, Daniel
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:tm:msg_send: udp_send failed Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:tm:t_forward_nonack: sending request failed Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30516]: ------------------> LOOSE route Nov 4 18:48:48 localhost /usr/local/sbin/kamailio[30513]: ------------------> LOOSE route Nov 4 18:48:50 localhost /usr/local/sbin/kamailio[30513]: ------------------> LOOSE route Nov 4 18:48:52 localhost /usr/local/sbin/kamailio[30512]: ------------------> LOOSE route
and so on...
Then, using Loose-route doesn't help.
I am sure I made a mistake somewhere, but I don't know where.
In the previous mail you will find my full CFG
kind regards,
Olivier
Iñaki Baz Castillo a écrit :
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
dear Iñaki
I have a server up and running at this time, my only problem is when I use uac_replace_from and receive a Bye from the callee. That's for another server. The default config doesn't help for that, or maybe I am stupid, that's another possibility :)
Your code is not correct:
if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
You must use loose_route() before the t_relay(). If not the Route header are not removed so you get a loop. This is well explained in the default config file.
your message is very helpfull, thanks,
Thanks.
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
maybe this can help?
U xxx.xxx.123.83:5060 -> yyy.yyy.67.183:5060 BYE sip:997321079@yyy.yyy.67.183:5060 SIP/2.0. Record-Route: <sip:xxx.xxx.123.83;ftag=as5f0cc351;lr=on>. Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWh hVSzE4Mw-->. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 16. Content-Length: 0. .
# U yyy.yyy.67.183:5060 -> xxx.xxx.123.83:5060 SIP/2.0 477 Send failed (477/TM). Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0.
As the BYE has a Route header different than the proxy receiving it, it means that it's not removed and the proxy routes the BYE there: Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713...> but obviously something fails when trying to send the request to that IP yyy.yyy.67.183 ¿? -- Iñaki Baz Castillo <ibc@aliax.net>
On 04.11.2009 18:19 Uhr, Iñaki Baz Castillo wrote:
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
maybe this can help?
U xxx.xxx.123.83:5060 -> yyy.yyy.67.183:5060 BYE sip:997321079@yyy.yyy.67.183:5060 SIP/2.0. Record-Route: <sip:xxx.xxx.123.83;ftag=as5f0cc351;lr=on>. Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWh hVSzE4Mw-->. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 16. Content-Length: 0. .
# U yyy.yyy.67.183:5060 -> xxx.xxx.123.83:5060 SIP/2.0 477 Send failed (477/TM). Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0.
As the BYE has a Route header different than the proxy receiving it, it means that it's not removed and the proxy routes the BYE there:
Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713...>
but obviously something fails when trying to send the request to that IP yyy.yyy.67.183 ¿?
the previous log showed that there is an error with sendto() function call, and now looking at the message is something wrong with the length of the buffer:
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
65564 is quite big... Is this happening only for this particular case, right? When you use the uac replace from, right? Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/
In fact, this server have no calls at this time, just the call I make. The cfg is very simple. Get the call, query the db, change the From , forward to the call to another kamailio and respond to auth request. Call is setup with no problem. Problem is only and only when the callee hangup, BYE is never transmitted to the caller even if the BYE is received by Kamailio. my_param in the route header seems to be forgot :( yes it happens with uac replace from and only when the callee hangup the call. Olivier Daniel-Constantin Mierla a écrit :
On 04.11.2009 18:19 Uhr, Iñaki Baz Castillo wrote:
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
maybe this can help?
U xxx.xxx.123.83:5060 -> yyy.yyy.67.183:5060 BYE sip:997321079@yyy.yyy.67.183:5060 SIP/2.0. Record-Route: <sip:xxx.xxx.123.83;ftag=as5f0cc351;lr=on>. Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWh
hVSzE4Mw-->. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 16. Content-Length: 0. .
# U yyy.yyy.67.183:5060 -> xxx.xxx.123.83:5060 SIP/2.0 477 Send failed (477/TM). Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0.
As the BYE has a Route header different than the proxy receiving it, it means that it's not removed and the proxy routes the BYE there:
Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713...>
but obviously something fails when trying to send the request to that IP yyy.yyy.67.183 ¿?
the previous log showed that there is an error with sendto() function call, and now looking at the message is something wrong with the length of the buffer:
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
65564 is quite big...
Is this happening only for this particular case, right? When you use the uac replace from, right?
Cheers, Daniel
Hello, On 04.11.2009 19:15 Uhr, olivier.taylor@gmail.com wrote:
In fact, this server have no calls at this time, just the call I make. The cfg is very simple.
Get the call, query the db, change the From , forward to the call to another kamailio and respond to auth request. Call is setup with no problem.
Problem is only and only when the callee hangup, BYE is never transmitted to the caller even if the BYE is received by Kamailio. my_param in the route header seems to be forgot :( is this param the one used by uac module? Isn't it set in Route header by callee? If yes, then it is a direction to investigate ...
Cheers, Daniel
yes it happens with uac replace from and only when the callee hangup the call.
Olivier
Daniel-Constantin Mierla a écrit :
On 04.11.2009 18:19 Uhr, Iñaki Baz Castillo wrote:
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
maybe this can help?
U xxx.xxx.123.83:5060 -> yyy.yyy.67.183:5060 BYE sip:997321079@yyy.yyy.67.183:5060 SIP/2.0. Record-Route: <sip:xxx.xxx.123.83;ftag=as5f0cc351;lr=on>. Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWh
hVSzE4Mw-->. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 16. Content-Length: 0. .
# U yyy.yyy.67.183:5060 -> xxx.xxx.123.83:5060 SIP/2.0 477 Send failed (477/TM). Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0.
As the BYE has a Route header different than the proxy receiving it, it means that it's not removed and the proxy routes the BYE there:
Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713...>
but obviously something fails when trying to send the request to that IP yyy.yyy.67.183 ¿?
the previous log showed that there is an error with sendto() function call, and now looking at the message is something wrong with the length of the buffer:
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
65564 is quite big...
Is this happening only for this particular case, right? When you use the uac replace from, right?
Cheers, Daniel
-- Daniel-Constantin Mierla * http://www.asipto.com/
hi all, problem solved, next time iI will buy a brain, mine seems to be out of service sometime... In fact this kamailio is installed just to receive calls from some routable IPs, no nat. But, I tried the system with a UA wich was natted... Using the nat_traversal module did solve the problem. uac_replace_from and auth works perfectly for me now. Completely my fault, I apologize :) Thanks to all, Olivier Daniel-Constantin Mierla a écrit :
On 04.11.2009 18:19 Uhr, Iñaki Baz Castillo wrote:
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
maybe this can help?
U xxx.xxx.123.83:5060 -> yyy.yyy.67.183:5060 BYE sip:997321079@yyy.yyy.67.183:5060 SIP/2.0. Record-Route: <sip:xxx.xxx.123.83;ftag=as5f0cc351;lr=on>. Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713;my_param=AAAAAAAAAAAAAAAACgBUWFxPXVpFWh
hVSzE4Mw-->. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Contact: <sip:0485336302@xxx.xxx.123.88>. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. User-Agent: Phonext B2Bua. Max-Forwards: 16. Content-Length: 0. .
# U yyy.yyy.67.183:5060 -> xxx.xxx.123.83:5060 SIP/2.0 477 Send failed (477/TM). Via: SIP/2.0/UDP xxx.xxx.123.83;branch=z9hG4bKa922.9ab28507.0. Via: SIP/2.0/UDP xxx.xxx.123.88:5060;branch=z9hG4bK04f04c65;rport=5060. From: <sip:0485336302@yyy.yyy.67.183>;tag=as5f0cc351. To: "997321079" <sip:997321073@finalcut.be>;tag=5713. Call-ID: 1257324832-1991-MacBook%20de%20Olivier%20Taylor@192.168.2.125. CSeq: 102 BYE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0.
As the BYE has a Route header different than the proxy receiving it, it means that it's not removed and the proxy routes the BYE there:
Route: <sip:yyy.yyy.67.183;lr=on;ftag=5713...>
but obviously something fails when trying to send the request to that IP yyy.yyy.67.183 ¿?
the previous log showed that there is an error with sendto() function call, and now looking at the message is something wrong with the length of the buffer:
Nov 4 18:48:44 localhost /usr/local/sbin/kamailio[30511]: ERROR:core:udp_send: sendto(sock,0xa2b359d0,65564,0,0xa2af4484,16): Message too long(90)
65564 is quite big...
Is this happening only for this particular case, right? When you use the uac replace from, right?
Cheers, Daniel
Iñaki Baz Castillo wrote:
El Miércoles, 4 de Noviembre de 2009, olivier.taylor@gmail.com escribió:
dear Iñaki
I have a server up and running at this time, my only problem is when I use uac_replace_from and receive a Bye from the callee. That's for another server. The default config doesn't help for that, or maybe I am stupid, that's another possibility :)
Your code is not correct:
if(has_totag()){ if(is_method("BYE")){ xlog("L_NOTICE", "------------------> LOOSE route"); } t_relay(); #relay all in-dialog messages (also BYEs) exit; }
You must use loose_route() before the t_relay(). If not the Route header are not removed so you get a loop. This is well explained in the default config file.
Thanks for the clearing, The code I shamelessly copy+pasted(and modified) from the original code was just intended to show the removal of the multiple t_relay(). Of couse the loose_route() should be present there :) That was the whole point of the thread . Sorry again for the time lost. Marius.
your message is very helpfull, thanks,
Thanks.
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
participants (7)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Joao Gomes Pereira -
marius zbihlei -
olivier taylor -
olivier.taylor＠gmail.com