i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
I tried for multiple hours to operate the debugger, also looking at -ddd output at stdout for many days. But I'm none the wiser. voicemail works from route[location] (e.g. if extension is not registered), but not after late errors like busy while ringing.
On 5/23/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
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
I'm still thinking about this issue and wondering: is it even compliant to the RFC to go directly from ringing to session progress and then OK? Because that's what freeswitch is answering with when I try to relay the call to it's voicemail when user is busy in kamailio.
On 6/1/13, hiro 23hiro@gmail.com wrote:
I tried for multiple hours to operate the debugger, also looking at -ddd output at stdout for many days. But I'm none the wiser. voicemail works from route[location] (e.g. if extension is not registered), but not after late errors like busy while ringing.
On 5/23/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
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
to clarify, it doesn't normally happen, just in some rare non-reproducable cases after i played with the config in some very random ways. have been playing to corner that case for many hours, but going to sleep now.
On 6/2/13, hiro 23hiro@gmail.com wrote:
I'm still thinking about this issue and wondering: is it even compliant to the RFC to go directly from ringing to session progress and then OK? Because that's what freeswitch is answering with when I try to relay the call to it's voicemail when user is busy in kamailio.
On 6/1/13, hiro 23hiro@gmail.com wrote:
I tried for multiple hours to operate the debugger, also looking at -ddd output at stdout for many days. But I'm none the wiser. voicemail works from route[location] (e.g. if extension is not registered), but not after late errors like busy while ringing.
On 5/23/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
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,
On 6/2/13 10:57 PM, hiro wrote:
I'm still thinking about this issue and wondering: is it even compliant to the RFC to go directly from ringing to session progress and then OK?
if I understand correctly what you mean, then it is ok from RFC point of view. Why you think would be a problem?
Cheers, Daniel
Because that's what freeswitch is answering with when I try to relay the call to it's voicemail when user is busy in kamailio.
On 6/1/13, hiro 23hiro@gmail.com wrote:
I tried for multiple hours to operate the debugger, also looking at -ddd output at stdout for many days. But I'm none the wiser. voicemail works from route[location] (e.g. if extension is not registered), but not after late errors like busy while ringing.
On 5/23/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
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
At some point i got session progress and then loads of OKs back from freeswitch, but either the phone didn't receive or didn't accept it. the ringing tone would keep on playing in the phone instead. Randomly the session progress seems to still get processed by the phone, i would hear freeswitch rtp, but again the phone would often ignore all the OKs afterwards... Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
On 6/4/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 6/2/13 10:57 PM, hiro wrote:
I'm still thinking about this issue and wondering: is it even compliant to the RFC to go directly from ringing to session progress and then OK?
if I understand correctly what you mean, then it is ok from RFC point of view. Why you think would be a problem?
Cheers, Daniel
Because that's what freeswitch is answering with when I try to relay the call to it's voicemail when user is busy in kamailio.
On 6/1/13, hiro 23hiro@gmail.com wrote:
I tried for multiple hours to operate the debugger, also looking at -ddd output at stdout for many days. But I'm none the wiser. voicemail works from route[location] (e.g. if extension is not registered), but not after late errors like busy while ringing.
On 5/23/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
On Tuesday 04 June 2013 12:07:35 hiro wrote:
Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP not defined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" + $sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY);
exit; }
return; }
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote:
On Tuesday 04 June 2013 12:07:35 hiro wrote:
Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP notdefined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +$sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY); exit; } return;}
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024
actually, I now see my last message is wrong. I've compared the 200 OKs that gets sent from freeswitch to my phone after the busy error and after direct voicemail routing from LOCATION when user is offline. Both 200 OKs look the same with one exception: The one that doesn't work had nat=yes two times here:
Record-Route: sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes Record-Route: sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes
On 6/4/13, hiro 23hiro@gmail.com wrote:
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote:
On Tuesday 04 June 2013 12:07:35 hiro wrote:
Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP notdefined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +$sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY); exit; } return;}
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024
Are you executing the route block for NAT handling in request_route and failure_route blocks? It should be done in branch route or only once in request_route. Look for add_rr_param() and see how many times it is executed for a branch (if executed in request_route, then it is for all branches at least one time).
Cheers, Daniel
On 6/4/13 10:57 PM, hiro wrote:
actually, I now see my last message is wrong. I've compared the 200 OKs that gets sent from freeswitch to my phone after the busy error and after direct voicemail routing from LOCATION when user is offline. Both 200 OKs look the same with one exception: The one that doesn't work had nat=yes two times here:
Record-Route: sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes Record-Route: sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes
On 6/4/13, hiro 23hiro@gmail.com wrote:
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote:
On Tuesday 04 June 2013 12:07:35 hiro wrote:
Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP notdefined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +$sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY); exit; } return;}
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024
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
I'm just using the default kamailio.cfg for kamailio 4.0.
add_rr_param() gets called in branch_route[MANAGE_BRANCH] and failure_route[MANAGE_FAILURE]
i commented out the latter and the phone gets the replies just fine now! But the rtp gets sent to the originally called phone from the port that got originally got presented to that phone in the first INVITE.
On 6/5/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
Are you executing the route block for NAT handling in request_route and failure_route blocks? It should be done in branch route or only once in request_route. Look for add_rr_param() and see how many times it is executed for a branch (if executed in request_route, then it is for all branches at least one time).
Cheers, Daniel
On 6/4/13 10:57 PM, hiro wrote:
actually, I now see my last message is wrong. I've compared the 200 OKs that gets sent from freeswitch to my phone after the busy error and after direct voicemail routing from LOCATION when user is offline. Both 200 OKs look the same with one exception: The one that doesn't work had nat=yes two times here:
Record-Route: sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes Record-Route: sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes
On 6/4/13, hiro 23hiro@gmail.com wrote:
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote:
On Tuesday 04 June 2013 12:07:35 hiro wrote:
Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP notdefined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +$sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY); exit; } return;}
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
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
I couldn't find if many parameters with same name are allowed in SIP URI, in headers they are not.
Try to put:
if(t_is_branch_route())
as condition for add_rr_param(...)
Cheers, Daniel
On 6/5/13 7:18 PM, hiro wrote:
I'm just using the default kamailio.cfg for kamailio 4.0.
add_rr_param() gets called in branch_route[MANAGE_BRANCH] and failure_route[MANAGE_FAILURE]
i commented out the latter and the phone gets the replies just fine now! But the rtp gets sent to the originally called phone from the port that got originally got presented to that phone in the first INVITE.
On 6/5/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
Are you executing the route block for NAT handling in request_route and failure_route blocks? It should be done in branch route or only once in request_route. Look for add_rr_param() and see how many times it is executed for a branch (if executed in request_route, then it is for all branches at least one time).
Cheers, Daniel
On 6/4/13 10:57 PM, hiro wrote:
actually, I now see my last message is wrong. I've compared the 200 OKs that gets sent from freeswitch to my phone after the busy error and after direct voicemail routing from LOCATION when user is offline. Both 200 OKs look the same with one exception: The one that doesn't work had nat=yes two times here:
Record-Route: sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes Record-Route: sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes
On 6/4/13, hiro 23hiro@gmail.com wrote:
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote:
On Tuesday 04 June 2013 12:07:35 hiro wrote:
Sometimes it also seemed that kamailio was sending the INVITE to the phone instead of to freeswitch, or when i played around between changing $du or $ru the INVITE gets sends to freeswitch but with the wrong URI pointing to the phone instead of 127.0.0.1:5070 which is where freeswitch is listening. I guess it would be easier to reproduce if that random factor wasn't there, but at least it's failing most of the time, only in different ways. I had hoped I could get at least confirmation that it "works here" to keep me going :P I will test with xlog when I can test at home again which would at least exclude NAT issues.
It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP notdefined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +$sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY); exit; } return;}
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
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
earlier today I commented out the whole route(NATMANAGE) from MANAGE_FAILURE route, that broke the NAT. But with your condition it works fine. thanks! Only I don't understand the $du/$ru thing yet.
On 6/5/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
I couldn't find if many parameters with same name are allowed in SIP URI, in headers they are not.
Try to put:
if(t_is_branch_route())
as condition for add_rr_param(...)
Cheers, Daniel
On 6/5/13 7:18 PM, hiro wrote:
I'm just using the default kamailio.cfg for kamailio 4.0.
add_rr_param() gets called in branch_route[MANAGE_BRANCH] and failure_route[MANAGE_FAILURE]
i commented out the latter and the phone gets the replies just fine now! But the rtp gets sent to the originally called phone from the port that got originally got presented to that phone in the first INVITE.
On 6/5/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
Are you executing the route block for NAT handling in request_route and failure_route blocks? It should be done in branch route or only once in request_route. Look for add_rr_param() and see how many times it is executed for a branch (if executed in request_route, then it is for all branches at least one time).
Cheers, Daniel
On 6/4/13 10:57 PM, hiro wrote:
actually, I now see my last message is wrong. I've compared the 200 OKs that gets sent from freeswitch to my phone after the busy error and after direct voicemail routing from LOCATION when user is offline. Both 200 OKs look the same with one exception: The one that doesn't work had nat=yes two times here:
Record-Route: sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes Record-Route: sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes
On 6/4/13, hiro 23hiro@gmail.com wrote:
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote:
On Tuesday 04 June 2013 12:07:35 hiro wrote: > Sometimes it also seemed that kamailio was sending the INVITE to the > phone instead of to freeswitch, or when i played around between > changing $du or $ru the INVITE gets sends to freeswitch but with the > wrong URI pointing to the phone instead of 127.0.0.1:5070 which is > where freeswitch is listening. > I guess it would be easier to reproduce if that random factor wasn't > there, but at least it's failing most of the time, only in different > ways. > I had hoped I could get at least confirmation that it "works here" > to > keep me going :P > I will test with xlog when I can test at home again which would at > least exclude NAT issues. It works here :)
I know your pain. I spend days figuring out the magic trick was to set $du to null (which I stumbled upon by accident). Without $du=$null traffic was being routed (seemingly random) to either the registered phone or the actual voicemail server.
# route to voicemail server route[TOVOICEMAIL] { if(!is_method("INVITE")) return;
# check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP notdefined\n"); return; }
if($avp(dst_voicemail)) { $du=$null; $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +$sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
route(RELAY); exit; } return;}
failure_route[MANAGE_FAILURE] { .... # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(CALLREDIRECT); route(TOVOICEMAIL); exit; } .... }
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
On 6/6/13 12:01 AM, hiro wrote:
earlier today I commented out the whole route(NATMANAGE) from MANAGE_FAILURE route, that broke the NAT. But with your condition it works fine. thanks!
Welcome.
Only I don't understand the $du/$ru thing yet.
$ru is R-URI, the address in the first line of a SIP request.
$du - is outbound address, an internal field that is used as target destination if it is set. If not set, then the request is sent to the address in $ru.
If $du was set previously, it is set also in failure_route, if you don't want to resend it to same address, set it to $null and then just change the R-URI and relay again.
Cheers, Daniel
On 6/5/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
I couldn't find if many parameters with same name are allowed in SIP URI, in headers they are not.
Try to put:
if(t_is_branch_route())
as condition for add_rr_param(...)
Cheers, Daniel
On 6/5/13 7:18 PM, hiro wrote:
I'm just using the default kamailio.cfg for kamailio 4.0.
add_rr_param() gets called in branch_route[MANAGE_BRANCH] and failure_route[MANAGE_FAILURE]
i commented out the latter and the phone gets the replies just fine now! But the rtp gets sent to the originally called phone from the port that got originally got presented to that phone in the first INVITE.
On 6/5/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
Are you executing the route block for NAT handling in request_route and failure_route blocks? It should be done in branch route or only once in request_route. Look for add_rr_param() and see how many times it is executed for a branch (if executed in request_route, then it is for all branches at least one time).
Cheers, Daniel
On 6/4/13 10:57 PM, hiro wrote:
actually, I now see my last message is wrong. I've compared the 200 OKs that gets sent from freeswitch to my phone after the busy error and after direct voicemail routing from LOCATION when user is offline. Both 200 OKs look the same with one exception: The one that doesn't work had nat=yes two times here:
Record-Route: sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes Record-Route: sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes
On 6/4/13, hiro 23hiro@gmail.com wrote:
ok. right now from tcpdump I can see the session progress and OK messages are sent to the correct ip:port of my phone, but either the phone doesn't receive it or it doesn't process it.
I assume the problem to be the headers sent by freeswitch, and perhaps not changed appropriately by kamailio, but I'm not sure: Call id and Cseq are the same as in RINGING, but contact header has freeswitch's IP (on the same server as kamailio) Contact: sip:3@127.0.0.1:5070;transport=udp
Could that ever work this way?
On 6/4/13, Daniel Tryba daniel@pocos.nl wrote: > On Tuesday 04 June 2013 12:07:35 hiro wrote: >> Sometimes it also seemed that kamailio was sending the INVITE to the >> phone instead of to freeswitch, or when i played around between >> changing $du or $ru the INVITE gets sends to freeswitch but with the >> wrong URI pointing to the phone instead of 127.0.0.1:5070 which is >> where freeswitch is listening. >> I guess it would be easier to reproduce if that random factor wasn't >> there, but at least it's failing most of the time, only in different >> ways. >> I had hoped I could get at least confirmation that it "works here" >> to >> keep me going :P >> I will test with xlog when I can test at home again which would at >> least exclude NAT issues. > It works here :) > > I know your pain. I spend days figuring out the magic trick was to > set > $du > to > null (which I stumbled upon by accident). Without $du=$null traffic > was > being > routed (seemingly random) to either the registered phone or the > actual > voicemail server. > > # route to voicemail server > route[TOVOICEMAIL] { > if(!is_method("INVITE")) > return; > > # check if VoiceMail server IP is defined > if (strempty($sel(cfg_get.voicemail.srv_ip))) { > xlog("SCRIPT: VoiceMail routing enabled but IP not > defined\n"); > return; > } > > if($avp(dst_voicemail)) > { > $du=$null; > $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" + > $sel(cfg_get.voicemail.srv_ip) + ":" + > $sel(cfg_get.voicemail.srv_port); > > route(RELAY); > > exit; > } > > return; > } > > failure_route[MANAGE_FAILURE] { > .... > # serial forking > # - route to voicemail on busy or no answer (timeout) > if (t_check_status("486|408")) { > route(CALLREDIRECT); > route(TOVOICEMAIL); > exit; > } > .... > } > > -- > > POCOS B.V. - Croy 9c - 5653 LC Eindhoven > Telefoon: 040 293 8661 - Fax: 040 293 8658 > http://www.pocos.nl/ - http://www.sipo.nl/ > K.v.K. Eindhoven 17097024 >
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
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://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
Hello,
On 6/1/13 10:30 PM, hiro wrote:
I tried for multiple hours to operate the debugger, also looking at -ddd output at stdout for many days. But I'm none the wiser. voicemail works from route[location] (e.g. if extension is not registered), but not after late errors like busy while ringing.
if debugger does not work for you being too verbose, add xlog() messages in your failure route and see if they are printed in syslog without increasing debug level.
Cheers, Daniel
On 5/23/13, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 5/19/13 2:05 PM, hiro wrote:
i'm trying to use the example kamailio.cfg to route to voicemail server on busy or decline. Only thing I did was adding decline code to t_check_status("486|408"), enabling the preprocessor variable for voicemail and changing the voicemail host and port to my voicemail server. No requests arrive on my voicemail server and the dial tone keeps ringing even if phone is busy and when I decline on the receiving phone there's a new INVITE sent to the phone directly afterwards. Am I doing something wrong here?
enable debugger module with cfgtrace option and see if the right actions are executed in the configuration file. Maybe there is a misconfiguration or wrong condition somewhere.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu *
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 Tryba -
Daniel-Constantin Mierla -
hiro