19 May
2013
19 May
'13
3:05 p.m.
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?
23 May
23 May
11:22 a.m.
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 *
1 Jun
1 Jun
11:30 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2 Jun
2 Jun
11:57 p.m.
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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:59 p.m.
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(a)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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4 Jun
4 Jun
12:18 p.m.
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(a)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(a)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(a)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 *
1:07 p.m.
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(a)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(a)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(a)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(a)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 *
7:33 p.m.
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
10:50 p.m.
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(a)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
11:57 p.m.
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(a)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(a)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
5 Jun
5 Jun
10:41 a.m.
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(a)gmail.com> wrote:
--
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 *
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:18 p.m.
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(a)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(a)gmail.com> wrote:
--
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:18 p.m.
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(a)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(a)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(a)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(a)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(a)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 *
6 Jun
6 Jun
1:01 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)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 *
11:30 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)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 *
>
>
--
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 *
4 Jun
4 Jun
12:12 p.m.
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(a)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(a)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 *
4187
days inactive
4205
days old
15 comments
3 participants
participants (3)
-
Daniel Tryba -
Daniel-Constantin Mierla -
hiro