Re: [SR-Users] NAT Traversal
Hello, one option might be a bad ALG implementation in the router. Can you send a full ngrep of such case? You can obfuscate the IP addresses, use different ones for each point in the network and leave the ports. Seeing SIP headers and SDP can indicate the presence of an ALG or something broken in config logic. Also, what is the parameter you give to force_rtp_proxy(...)? Cheers, Daniel On 3/2/11 8:38 AM, Spinov Evgeniy wrote: May be I miss some important details? No suggestions? Thank you. Hello, all. Using nathelper + rtpproxy for subj. Kamailio has public and private network interfaces. Asterisk is only private. RTP Proxy is working in bridge mode and relaying traffic from UAC to Asterisks. Everything is working fine, except one configuration. When the client is behind router ( a specific one, I do not have an access there to check ), and this UAC is making a call to other public extension, which is behind router, then RTP Proxy is relaying traffic to the caller, using another UDP port, then the packets arrive. For instance: UAC 1 - UAC 2 PUBLIC_IP:10 KAMAILIO_IP: KAMAILIO_IP:5678 PUBLIC_IP:12 While for the UAC 2 it looks like: PUBLIC_IP:20 KAMAILIO_IP:6767 KAMAILIO_IP:4564 PUBLIC_IP:20 The source and destination UDP ports are the same. As result, I can hear UAC 1 and he cannot hear me. In case of we have UAC 3, which is behind other router, call is working fine with same configuration. It's routers fault you can say, but in the same configuration ( I mean network, not kamailio ) it worked, but when RTPProxy was not in bridge mode and Kamailio and Asterisks were in public network. Reinvites are not allowed in both cases. The question is, why the source and destination UDP ports are different? Using STUN in first case, cause without it, private IP written in contacts and as result, traffic relayed from Kamailio is incorrect, cause heading to private network which is unreachable. Any ideas where to dig? ___ 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 ___ 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
Re: [SR-Users] Radius authentication
Hello,
On 2/28/11 10:44 AM, Pablo Ros wrote:
I am trying to authenticate through radius (info in LDAP database). I
am using kamailio 3.1
First of all I would like to clear up an issue:
As shown the way to do the authentication is done with:
*Code:*
if (! radius_www_authorize(uu.net http://uu.net)) {
www_challenge(uu.net http://uu.net, 0);
return;
}
first, if you don't have the above block in main request route block,
replace 'return' with 'exit'.
Ok, when I installed openser I did it with kamailio flavour so it
was using the auth_radius module belonging to it.
Does anyone know which would be the correct way to do the challenge to
the user cause is was not working at all. The radius client does not
even send it.
IIRC, even for RADIUS, the challenge is built by Kamailio auth module,
nothing exchanged with the RADIUS server for challenge.
I got stuck some time till I just decided to load the module from ser
modules folder and then freeradius server started to get correctly my
requests. Actually I can even see it authenticates them correctly.
Can you update kamailio default config where you replace auth_db module
with auth_radius (from modules_k), and inside the routing blocks use:
- www_radius_authorize() instead of www_authorize()
- proxy_radius_authorize() instead of proxy_authorize()
Then start it with:
kamailio -E -ddd
and see if you see any hint/error there. Then run a test call and watch
the logs, you should see some errors if communication with radius is not
happening. If you don't understand exactly what happened, send those
messages here.
Cheers,
Daniel
However Openser/Kamailio doesn't seem to see the same and it doesn't
saves location.
*Code:*
route[AUTH] {
#!ifdef WITH_AUTH
# Primeramente comprobamos si pertenece a nuestro dominio; si no ya no
hace falta comprobar credenciales.
if (uri==myself)
{
if (is_method(REGISTER))
{
xlog(L_NOTICE,KAM-INFO: r[AUTH] - REGISTER
- User info: ($fu):($si)\n);
if (!radius_www_authorize(i2cat.net
http://i2cat.net)){
route(RADIUS);
#www_challenge(i2cat.net
http://i2cat.net,0);
exit;
}
}
if ($au!=$tU)
{
sl_send_reply(403,Forbidden auth ID);
exit;
}
} else {
#!ifdef WITH_IPAUTH
if(allow_source_address())
{
# source IP allowed
return;
}
#!endif
# authenticate if from local subscriber
if (from_uri==myself)
{
if (!proxy_authorize($fd, subscriber)) {
proxy_challenge($fd, 0);
exit;
}
if (is_method(PUBLISH))
{
if ($au!=$tU) {
sl_send_reply(403,Forbidden
auth ID);
exit;
}
} else {
if ($au!=$fU) {
sl_send_reply(403,Forbidden
auth ID);
exit;
}
}
consume_credentials();
# caller authenticated
} else {
# caller is not local subscriber, then check
if it calls
# a local destination, otherwise deny, not an
open relay here
if (!uri==myself)
{
sl_send_reply(403,Not relaying);
exit;
}
}
}
#!endif
return;
}
Before doing the challenge then it just goes throught:
*Code:*
route[RADIUS]
{
sl_send_reply(100, Trying);
append_to_reply(Expires: 600\r\n);
append_to_reply(Min-Expires: 240\r\n);
xlog(L_NOTICE,KAM-INFO: RADIUS AUTHENTICATION - AUTHORIZING USER
$fU - $fu:$si\n);
xlog(L_NOTICE,KAM-INFO: CHALLENGING. - RETCODE- $rc \n);
www_challenge(i2cat.net http://i2cat.net, 0);
switch($rc){
case -5:
xlog(L_INFO, - 500: internal server error);
sl_send_reply(500, Internal Server Error);
case -4:
xlog(L_INFO, - 404: credentials not found);
sl_send_reply(404, Credentials Not Found);
case -3:
xlog(L_INFO, - 400: bad request - stale nonce);
sl_send_reply(400, Bad Request);
case -2:
xlog(L_INFO, - 401: invalid password);
Re: [SR-Users] how to combine alias_db_lookup() with lookup()
Hello,
On 2/27/11 3:46 AM, x-kamai...@sidell.org wrote:
I'm trying to use the db_alias module as a way to define generic
addresses that map to a set of actual phones. For example, I'd like
the alias h...@foo.bar to map to kitc...@foo.bar and
off...@foo.bar, so that both phones ring when a call comes in to
home.
I have set the append_branches param to 1:
modparam(alias_db, append_branches, 1)
I also modified the dbaliases database table so that key alias_idx
isn't unique, thereby allow me to add multiple rows for the same
alias.
The relevant script section is taken verbatim from 3.1 kamailio.cfg:
# USER location service
route[LOCATION] {
#!ifdef WITH_ALIASDB
# search in DB-based aliases
alias_db_lookup(dbaliases);
#!endif
if (!lookup(location)) {
switch ($rc) {
case -1:
case -3:
xlog( L_WARN, XXX $ru $fu\n);
t_newtran();
t_reply(404, Not Found);
exit;
case -2:
sl_send_reply(405, Method Not Allowed);
exit;
}
}
# when routing via usrloc, log the missed calls also
if (is_method(INVITE))
{
setflag(FLT_ACCMISSED);
}
}
When I place a call to an alias, the kamailio debug log shows that
alias_db_lookup() is correctly setting the ruri to the first entry
found in the table, and using append_branch() to add the others. But
only the first matching phone gets an INVITE, not the others. I
suspect that the lookup() call is blowing away the branches set up by
alias_db_lookup() and replacing them with the single phone that
matches the ruri for the first alias entry.
Is there a way to get alias_db_lookup() and lookup() to play together,
so that the first function can set up a list of branches, and the
second function can resolve all of the branches to the actual device
locations?
the branches added by alias_db are not lost, but they are sent back to
you over loopback. They get dropped probably because they are authenticated.
Try to watch the traffic on loopback with ngrep just to see if I am right:
ngrep -d any -qt -W byline port 5060
The solution in this case is to have a condition in route[AUTH] for
non-REGISTER requests, something like:
if(src_ip==myself)
return;
before doing proxy_authenticate().
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAT Traversal
Unfortunately ngrep is unavailable right now, cause network was configured to use public IPs. May be I'll can do that on development network later. Right now development network using public`s also. I'll try to sort out ngrep anyway. I was giving FAEI to INVITEs from UAC to Asterisk and FAIE to INVITEs from Asterisks to UAC. Everything was good except destination UDP port to UAC 1. It was different then the source. As result UAC 1 didn't received backflow. Also, may be this will help: Kamailio was unable to identify that faulty UAC 1 is behind the NAT. I've tried nat_uac_test(31), however - nothing, while SIP headers were containing NATed IPs. So during tests I've just forced NAT always. Without that I didn't had audio at all. While with it - one way audio with faulty UAC and normal call for all others. Also, on faulty UAC 1 I had to use STUN server, while all other clients worked without it. After going Asterisks public and changing kamailio configuration for it, STUN no longer needed anywhere. Just assuming fact, that router has bad ALG implementation. Is there any workaround for it, may be forcing destination ports to source ones? On Wed, 2011-03-02 at 09:30 +0100, Daniel-Constantin Mierla wrote: Hello, one option might be a bad ALG implementation in the router. Can you send a full ngrep of such case? You can obfuscate the IP addresses, use different ones for each point in the network and leave the ports. Seeing SIP headers and SDP can indicate the presence of an ALG or something broken in config logic. Also, what is the parameter you give to force_rtp_proxy(...)? Cheers, Daniel On 3/2/11 8:38 AM, Spinov Evgeniy wrote: May be I miss some important details? No suggestions? Thank you. Hello, all. Using nathelper + rtpproxy for subj. Kamailio has public and private network interfaces. Asterisk is only private. RTP Proxy is working in bridge mode and relaying traffic from UAC to Asterisks. Everything is working fine, except one configuration. When the client is behind router ( a specific one, I do not have an access there to check ), and this UAC is making a call to other public extension, which is behind router, then RTP Proxy is relaying traffic to the caller, using another UDP port, then the packets arrive. For instance: UAC 1 - UAC 2 PUBLIC_IP:10 KAMAILIO_IP: KAMAILIO_IP:5678 PUBLIC_IP:12 While for the UAC 2 it looks like: PUBLIC_IP:20 KAMAILIO_IP:6767 KAMAILIO_IP:4564 PUBLIC_IP:20 The source and destination UDP ports are the same. As result, I can hear UAC 1 and he cannot hear me. In case of we have UAC 3, which is behind other router, call is working fine with same configuration. It's routers fault you can say, but in the same configuration ( I mean network, not kamailio ) it worked, but when RTPProxy was not in bridge mode and Kamailio and Asterisks were in public network. Reinvites are not allowed in both cases. The question is, why the source and destination UDP ports are different? Using STUN in first case, cause without it, private IP written in contacts and as result, traffic relayed from Kamailio is incorrect, cause heading to private network which is unreachable. Any ideas where to dig? ___ 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 ___ 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
Re: [SR-Users] NAT Traversal
On 3/2/11 9:32 AM, Spinov Evgeniy wrote: Unfortunately ngrep is unavailable right now, cause network was configured to use public IPs. May be I'll can do that on development network later. Right now development network using public`s also. I'll try to sort out ngrep anyway. I was giving FAEI to INVITEs from UAC to Asterisk and FAIE to INVITEs from Asterisks to UAC. Everything was good except destination UDP port to UAC 1. It was different then the source. As result UAC 1 didn't received backflow. You say about wrong port for RTP or for SIP? For SIP be sure you call force_rport(). For RTP try eventually the flag 'r' in in parameters of force_rtp_proxy(). Also, may be this will help: Kamailio was unable to identify that faulty UAC 1 is behind the NAT. I've tried nat_uac_test(31), however - nothing, while SIP headers were containing NATed IPs. By NATed ip you mean private class, like 10... or 192.168...? If yes, that is strange, can you add debugger module with cfgtrace enabled to see what lines in the config file are executed for that call? (this is assuming you are using v3.1.x, if not add xlog() messages in the config to be sure the nat handling part is executed). Cheers, Daniel So during tests I've just forced NAT always. Without that I didn't had audio at all. While with it - one way audio with faulty UAC and normal call for all others. Also, on faulty UAC 1 I had to use STUN server, while all other clients worked without it. After going Asterisks public and changing kamailio configuration for it, STUN no longer needed anywhere. Just assuming fact, that router has bad ALG implementation. Is there any workaround for it, may be forcing destination ports to source ones? On Wed, 2011-03-02 at 09:30 +0100, Daniel-Constantin Mierla wrote: Hello, one option might be a bad ALG implementation in the router. Can you send a full ngrep of such case? You can obfuscate the IP addresses, use different ones for each point in the network and leave the ports. Seeing SIP headers and SDP can indicate the presence of an ALG or something broken in config logic. Also, what is the parameter you give to force_rtp_proxy(...)? Cheers, Daniel On 3/2/11 8:38 AM, Spinov Evgeniy wrote: May be I miss some important details? No suggestions? Thank you. Hello, all. Using nathelper + rtpproxy for subj. Kamailio has public and private network interfaces. Asterisk is only private. RTP Proxy is working in bridge mode and relaying traffic from UAC to Asterisks. Everything is working fine, except one configuration. When the client is behind router ( a specific one, I do not have an access there to check ), and this UAC is making a call to other public extension, which is behind router, then RTP Proxy is relaying traffic to the caller, using another UDP port, then the packets arrive. For instance: UAC 1 - UAC 2 PUBLIC_IP:10 KAMAILIO_IP: KAMAILIO_IP:5678 PUBLIC_IP:12 While for the UAC 2 it looks like: PUBLIC_IP:20 KAMAILIO_IP:6767 KAMAILIO_IP:4564 PUBLIC_IP:20 The source and destination UDP ports are the same. As result, I can hear UAC 1 and he cannot hear me. In case of we have UAC 3, which is behind other router, call is working fine with same configuration. It's routers fault you can say, but in the same configuration ( I mean network, not kamailio ) it worked, but when RTPProxy was not in bridge mode and Kamailio and Asterisks were in public network. Reinvites are not allowed in both cases. The question is, why the source and destination UDP ports are different? Using STUN in first case, cause without it, private IP written in contacts and as result, traffic relayed from Kamailio is incorrect, cause heading to private network which is unreachable. Any ideas where to dig? ___ 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 ___ 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
Re: [SR-Users] NAT Traversal
On Wed, 2011-03-02 at 09:53 +0100, Daniel-Constantin Mierla wrote: On 3/2/11 9:32 AM, Spinov Evgeniy wrote: Unfortunately ngrep is unavailable right now, cause network was configured to use public IPs. May be I'll can do that on development network later. Right now development network using public`s also. I'll try to sort out ngrep anyway. I was giving FAEI to INVITEs from UAC to Asterisk and FAIE to INVITEs from Asterisks to UAC. Everything was good except destination UDP port to UAC 1. It was different then the source. As result UAC 1 didn't received backflow. You say about wrong port for RTP or for SIP? On RTP only. SIP works fine, except STUN server requirement as I've mentioned below. For SIP be sure you call force_rport(). For RTP try eventually the flag 'r' in in parameters of force_rtp_proxy(). According to README, r flag affects IP addresses, so it will not solve RTP issue, but I'll try it to get rid of STUN server requirement, hope this will help. Also, may be this will help: Kamailio was unable to identify that faulty UAC 1 is behind the NAT. I've tried nat_uac_test(31), however - nothing, while SIP headers were containing NATed IPs. By NATed ip you mean private class, like 10... or 192.168...? Yea, in my case this is 192.168 If yes, that is strange, can you add debugger module with cfgtrace enabled to see what lines in the config file are executed for that call? (this is assuming you are using v3.1.x, if not add xlog() messages in the config to be sure the nat handling part is executed). This is Kamailio 3.0.4. I've added xlogs and seen that messages are proceeded on SIP sessions ( ones for INVITE from UAC1 and once for INVITE from Asterisk to UAC2 ) and for RTP, once for each session. RTP Proxy is proxing all 4 flows ( 2 per each side ). May be I should take a look at something else? Cheers, Daniel So during tests I've just forced NAT always. Without that I didn't had audio at all. While with it - one way audio with faulty UAC and normal call for all others. Also, on faulty UAC 1 I had to use STUN server, while all other clients worked without it. After going Asterisks public and changing kamailio configuration for it, STUN no longer needed anywhere. Just assuming fact, that router has bad ALG implementation. Is there any workaround for it, may be forcing destination ports to source ones? On Wed, 2011-03-02 at 09:30 +0100, Daniel-Constantin Mierla wrote: Hello, one option might be a bad ALG implementation in the router. Can you send a full ngrep of such case? You can obfuscate the IP addresses, use different ones for each point in the network and leave the ports. Seeing SIP headers and SDP can indicate the presence of an ALG or something broken in config logic. Also, what is the parameter you give to force_rtp_proxy(...)? Cheers, Daniel On 3/2/11 8:38 AM, Spinov Evgeniy wrote: May be I miss some important details? No suggestions? Thank you. Hello, all. Using nathelper + rtpproxy for subj. Kamailio has public and private network interfaces. Asterisk is only private. RTP Proxy is working in bridge mode and relaying traffic from UAC to Asterisks. Everything is working fine, except one configuration. When the client is behind router ( a specific one, I do not have an access there to check ), and this UAC is making a call to other public extension, which is behind router, then RTP Proxy is relaying traffic to the caller, using another UDP port, then the packets arrive. For instance: UAC 1 - UAC 2 PUBLIC_IP:10 KAMAILIO_IP: KAMAILIO_IP:5678 PUBLIC_IP:12 While for the UAC 2 it looks like: PUBLIC_IP:20 KAMAILIO_IP:6767 KAMAILIO_IP:4564 PUBLIC_IP:20 The source and destination UDP ports are the same. As result, I can hear UAC 1 and he cannot hear me. In case of we have UAC 3, which is behind other router, call is working fine with same configuration. It's routers fault you can say, but in the same configuration ( I mean network, not kamailio ) it worked, but when RTPProxy was not in bridge mode and Kamailio and Asterisks were in public network. Reinvites are not allowed in both cases. The question is, why the source and destination UDP ports are different? Using STUN in first case, cause without it, private IP written in contacts and as result, traffic relayed from Kamailio is incorrect, cause heading to private network which is unreachable. Any ideas where to dig? ___ 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 ___ 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
Re: [SR-Users] dispatcher confusion
Hi everyone, the idea behind the probing mode was, to have three states for a gateway: - Active - In-Active: Administratively disabled - Probing (Active, but currently not responding) If you disable a gateway when it is in probing mode, it may end up with being enabled again due to some of Kamailio's internals: The OPTIONS-Request being sent out is handled by the TM-Module, which will generate Retransmits for quite a long time (2 minutes?). Upon a successful reply for the OPTIONS-Request, it will set the destination to active again. I will change this behaviour later this week or next week in GIT-Trunk, so an administratively disabled destination stays inactive, even upon a delayed positive reply for an OPTIONS-Request Carsten 2011/2/28 Daniel-Constantin Mierla mico...@gmail.com: Hello, On 2/28/11 5:29 PM, Klaus Darilion wrote: Hi! Every time I use the dispatcher(k) module I am confused again. Sometimes it seems that probing is a dedicated state, sometimes it seems that probing is done also in active state, but never in inactive state. if you set the global parameter for probing, then no matter the state, the pinging is done for all addresses. If the module parameter is not set, only the destinations marked as probing should be pinged. In devel version I tried to sort out a bit these states, so we should make it more sane and clear. IMO probing should only be a flag which indicates if OPTIONS should sent or not. If probing is successful, then the state should be active. If probing is unsuccessful, then the state should be inactive. Current behavior is very strange (ds_probing_mode(0)): -- startup state: A -- no probing kamctl fifo ds_set_state i 1 sip: -- state: I -- no probing kamctl fifo ds_set_state a 1 sip: -- state: A -- no probing When ds_probing_mode==0, only if you set P flag to address will be pinged. calling 3 times ds_mark_dst(p) -- state: P -- probing (and dst is still loaded as last value into the dst_avp, why?) kamctl fifo ds_set_state i 1 sip: -- state: I -- still probing kamctl fifo ds_set_state a 1 sip: -- state: P (???) -- probing Thus, ds_set_state a ... does not set active, but probing if it was probing before. Strange. And as inactive does not stop probing when dst was in probing mode, the destination becomes automatically active if the probing succeeds. inactive and probing are different flags. In devel I introduced new state 'disabled' for cases when you want to remove an address from destination list. And why is a destination in probing mode loaded into the dst_avp? Very weird. If it is just probing and not inactive, then it is loaded as new dst. Is there a reason for this behavior? IIRC, I think Carsten developed most of the probing mode, maybe there was a reason behind current behavior. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany Mobile +49 179 2021244 Home +49 40 34927217 Büro (Verl) +49 5246 801427 Fax +49 40 34927218 mailto:cars...@bock.info ___ 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
Re: [SR-Users] dispatcher confusion
On 02.03.2011 11:52, Carsten Bock wrote: Hi everyone, the idea behind the probing mode was, to have three states for a gateway: - Active - In-Active: Administratively disabled - Probing (Active, but currently not responding) So, inactive should be the same as the newly introduced disabled state? Maybe it would be better to separate the should state from the real state, and probing is just a flag which may happen in all states. Eg: should state: disabled: administratively down (never probing) enabled: administratively up (probing if activated) real sate: disabled: should-state is disabled (destination will NOT be used in dispatching) up: everthing is fine (destination will be used in dispatching) failure: probing failed for threshold times (destination will NOT be used in dispatching) regards Klaus If you disable a gateway when it is in probing mode, it may end up with being enabled again due to some of Kamailio's internals: The OPTIONS-Request being sent out is handled by the TM-Module, which will generate Retransmits for quite a long time (2 minutes?). Upon a successful reply for the OPTIONS-Request, it will set the destination to active again. I will change this behaviour later this week or next week in GIT-Trunk, so an administratively disabled destination stays inactive, even upon a delayed positive reply for an OPTIONS-Request Carsten 2011/2/28 Daniel-Constantin Mierlamico...@gmail.com: Hello, On 2/28/11 5:29 PM, Klaus Darilion wrote: Hi! Every time I use the dispatcher(k) module I am confused again. Sometimes it seems that probing is a dedicated state, sometimes it seems that probing is done also in active state, but never in inactive state. if you set the global parameter for probing, then no matter the state, the pinging is done for all addresses. If the module parameter is not set, only the destinations marked as probing should be pinged. In devel version I tried to sort out a bit these states, so we should make it more sane and clear. IMO probing should only be a flag which indicates if OPTIONS should sent or not. If probing is successful, then the state should be active. If probing is unsuccessful, then the state should be inactive. Current behavior is very strange (ds_probing_mode(0)): --startup state: A --no probing kamctl fifo ds_set_state i 1 sip: --state: I --no probing kamctl fifo ds_set_state a 1 sip: --state: A --no probing When ds_probing_mode==0, only if you set P flag to address will be pinged. calling 3 times ds_mark_dst(p) --state: P --probing (and dst is still loaded as last value into the dst_avp, why?) kamctl fifo ds_set_state i 1 sip: --state: I --still probing kamctl fifo ds_set_state a 1 sip: --state: P (???) --probing Thus, ds_set_state a ... does not set active, but probing if it was probing before. Strange. And as inactive does not stop probing when dst was in probing mode, the destination becomes automatically active if the probing succeeds. inactive and probing are different flags. In devel I introduced new state 'disabled' for cases when you want to remove an address from destination list. And why is a destination in probing mode loaded into the dst_avp? Very weird. If it is just probing and not inactive, then it is loaded as new dst. Is there a reason for this behavior? IIRC, I think Carsten developed most of the probing mode, maybe there was a reason behind current behavior. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ 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
Re: [SR-Users] About RPM of Kamailio
Please post your questions to the mailing list. If you want to build an rpm, the location of the spec file is available in the source tree: ./pkg/kamailio/rpm/kamailio.spec.CenOS If you prefer a link: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=pkg/kamailio/rpm/kamailio.spec.CenOS;h=b2c6d013b2071ac7ec54c15c661b58e7e0d5b005;hb=HEAD Regards, Ovidiu Sas On Wed, Mar 2, 2011 at 5:56 AM, Suresh Bhandari bring...@yahoo.com wrote: Hello Ovidiu, I searched through the kamailio.org/pub but can't find what you said. Can you verify the exact location of package that you've downloaded. Thanks. Suresh ___ 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
[SR-Users] problem unreferencing dialog in dialog module
Hi all,
we are running Kamailio 3.1.2 in a production environment, using the dialog
module, and it crashed two hours ago.
Here you have the logs we got (addtional log fragments with the acc records
involved in this call are appended at the end of the mail):
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: CRITICAL: dialog
[dlg_hash.c:599]: bogus ref -1 with cnt 1 for dlg 0x7f23f472db30
[2490:1070436595] with clid 'e0a20cb844d211e0acd8001422093865@CLIENT IP'
and tags '1577886432-3759264324-335599788-1698171170' ''
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: : core
[mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
free: dialog: dlg_cb.c: destroy_dlg_callbacks_list(80) - aborting
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: core
[main.c:741]: child process 28927 exited by a signal 6
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: core
[main.c:744]: core was not generated
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: INFO: core
[main.c:756]: INFO: terminating due to SIGCHLD
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28948]: INFO: core
[main.c:807]: INFO: signal 15 received
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28942]: INFO: core
[main.c:807]: INFO: signal 15 received
We get the kamailio code from git last week:
sercmd core.info
{
version: kamailio 3.1.2
id: 4ace86
compiler: gcc 4.3.2
compiled: 09:12:36 Feb 23 2011
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
}
The problem looks like this other one already fixed:
http://lists.sip-router.org/pipermail/sr-users/2009-November/027351.html
We set the Kamailio to debug level in case it happens again.
On the other side, I need to know why the core is not been generated. I have
already checked the points mentioned in
http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles
1. disable_core_dump is not set in the config file.
2. From /etc/default/kamailio:
...
DUMP_CORE=yes
...
2. From /etc/init.d/kamailio:
...
if test $DUMP_CORE = yes ; then
# set proper ulimit
ulimit -c unlimited
# directory for the core dump files
COREDIR=/home/corefiles
[ -d $COREDIR ] || mkdir $COREDIR
chmod 777 $COREDIR
echo $COREDIR/core.%e.sig%s.%p /proc/sys/kernel/core_pattern
fi
...
4. Writting permissions of $COREDIR
ls -hall /home
...
drwxrwxrwx 2 root root 4.0K 2010-12-21 09:15 corefiles
...
What else should I check?
Thanks in advance,
regards
Antón
*Acc records related to the dialog whose destruction causes the problem:*
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28902]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073364;method=INVITE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@client
IP;code=200;reason=OK;src_user=caller number;src_domain=client
IP;dst_ouser=called
number;dst_user=called number;dst_domain=10.90.1.251;src_ip=client IP
...
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28920]: NOTICE: acc
[acc.c:275]: ACC: request acknowledged:
timestamp=1299073364;method=ACK;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@client
IP;code=200;reason=OK;src_user=caller number;src_domain=client
IP;dst_ouser=called number;dst_user=called
number;dst_domain=10.90.1.251;src_ip=client IP
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28903]: ERROR: script:
ACK WITHOUT MATCHING TRANSACTION in e0a20cb844d211e0acd8001422093865@client
IP call... ignore and discard.
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28904]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073380;method=BYE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@client
IP;code=200;reason=OK;src_user=caller number;src_domain=client
IP;dst_ouser=called number;dst_user=called
number;dst_domain=10.90.1.251;src_ip=client IP
___
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
Re: [SR-Users] Question about time display in SIREMIS 2.0
Hello Ramona. It is odd. I have created a table in my openser database called “statistics”. The time_stamp column stores the $Ts from Kamailio. These are my last three entries : mysql select id,time_stamp,ul_users,fwd_requests from statistics ORDER by id DESC limit 3; +--++--+--+ | id | time_stamp | ul_users | fwd_requests | +--++--+--+ | 2002 | 1299098096 |1 |0 | | 2001 | 1299097646 |1 | 18 | | 2000 | 1299097346 |1 | 18 | +--++--+--+ 3 rows in set (0.00 sec) If I convert the last three timestamps I get : 1299098096 à Wed, 02 Mar 2011 20:22:26 GMT 1299097646 à Wed, 02 Mar 2011 20:27:26 GMT 1299098096 à Wed, 02 Mar 2011 20:34:56 GMT But in the charts I keeps seeing the last entry as : 12:34:56 PM. My time_stamp column is created as INT(). Could that be the problem? ++-+--+-+-++ | Field | Type| Null | Key | Default | Extra | ++-+--+-+-++ | id | int(11) | NO | PRI | NULL| auto_increment | | time_stamp | int(11) | YES | | NULL|| ++-+--+-+-++ Hope you can help me. Thanks in advance, Regards, Ricardo Martinez.- *De:* Elena-Ramona Modroiu [mailto:ram...@asipto.com] *Enviado el:* miércoles, 02 de marzo de 2011 15:48 *Para:* Ricardo Martinez *CC:* sr-users@lists.sip-router.org *Asunto:* Re: [SR-Users] Question about time display in SIREMIS 2.0 Hi, for charts siremis uses the date() function to convert from unix timestamp that is written by kamailio to the displayed date. It might be possible to adjust the timezone from php.ini. Regards, Ramona On 2/28/11 10:30 PM, Ricardo Martinez wrote: Hello. Is there a way to adjust the timezone to display the charts and the logs in the SIREMIS 2.0? I have my linux machine with my local timezone, but the display in the charts and the logs are not in synch with my local time. Thanks in advance. Regards, Ricardo Martinez.- ___ 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 image001.png___ 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
Re: [SR-Users] Limit call duration
You can use the dialog module to make that happen, Hans. Take a look at http://www.kamailio.org/docs/modules/1.5.x/dialog.html The dialog module is used to track the state of open dialogs in Kamailio and the module includes the option to impose a timeout. You do this by first setting a timeout value in your module parameters section: modparam(dialog, default_timeout, 43200) Now just enable bi-directional BYEs in any routes you want to time out: $dlg_ctx(timeout_bye) = 1; Hope this helps. On 03/02/2011 03:54 PM, Hans Goossens wrote: Hi, I'm wondering if there is a easy way to limit the call duration in Kamailio ? I would like to automaticaly end the call when the max. duration (for example 12 hours) is reached. In the feature overview of Kamailio 1.5 I found: option to send BYE when dialog expires but i'm can't figure out how to get this working (if it's still implemented at all in the current version). Thanks in advance, Kind regards Hans ___ 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 -- Joe Hart Voice Systems Integrator Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web : http://www.evaristesys.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
