Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay ---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things: - why does a lookup of dbaliases before lookup of location make such difference? - does lookup location work differently depending on whether it is called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); }
if (!t_relay()) { sl_reply_error(); }
exit; }
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in REGISTER message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ...
# user location service route(LOCATION);
route(RELAY); }
Hope I have made it clear. Thanks very much!
Yufei -- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
I suspect that the branch route is first executed for the NATed client. Then the 'received' column is used as destination URI. When executing the branch route again, the destination URI is still the value from the previous branch, and lookup() will not overwrite is as 'received' is not available. Then Kamailio sends the INVITE again to the first client.
You can try to set $du to Null before lookup(). ($du=null or $du=$null, not sure what the correct syntax is).
Another workaround is to use fix_nated_register() for every client (the pragmatic and more secure approach).
regards Klaus
On 18.09.2012 15:16, Yufei Tao wrote:
Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay ---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things:
- why does a lookup of dbaliases before lookup of location make such
difference?
- does lookup location work differently depending on whether it is
called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit;
}
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in REGISTER
message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ... # user location service route(LOCATION); route(RELAY);
}
Hope I have made it clear. Thanks very much!
Yufei
Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
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
Hi Klaus
Thanks for the reply!
I check the $du, it is always null before and after the lookup. Is it only set when relaying to a proxy (from record-route), and not to a client?
When no fix_nated_register is called, the lookup location for both clients y2 and y3 is successful from the log, when printing out $ru after lookup. But seems Kamailio only relays to one client's IP while not others. I think there must be some differences when branch route is executed first time and second time as you said. As it feels like for the first branch (trunk?) it used the 'contact' column from the location table, and for the other branches, it tries to use 'received'?
Yufei
On 18/09/12 18:49, Klaus Darilion wrote:
I suspect that the branch route is first executed for the NATed client. Then the 'received' column is used as destination URI. When executing the branch route again, the destination URI is still the value from the previous branch, and lookup() will not overwrite is as 'received' is not available. Then Kamailio sends the INVITE again to the first client.
You can try to set $du to Null before lookup(). ($du=null or $du=$null, not sure what the correct syntax is).
Another workaround is to use fix_nated_register() for every client (the pragmatic and more secure approach).
regards Klaus
On 18.09.2012 15:16, Yufei Tao wrote:
Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay
---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things:
- why does a lookup of dbaliases before lookup of location make such
difference?
- does lookup location work differently depending on whether it is
called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location
trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit;
}
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in REGISTER
message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ... # user location service route(LOCATION); route(RELAY);
}
Hope I have made it clear. Thanks very much!
Yufei
Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
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
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
On 19.09.2012 12:24, Yufei Tao wrote:
Hi Klaus
Thanks for the reply!
I check the $du, it is always null before and after the lookup. Is it only set when relaying to a proxy (from record-route), and not to a client?
That's strange. For NATed clients, $du must contain the 'received' URI. Otherwise they can not be contacted as $ru contains the private IP address.
When no fix_nated_register is called, the lookup location for both clients y2 and y3 is successful from the log, when printing out $ru after lookup. But seems Kamailio only relays to one client's IP while not others. I think there must be some differences when branch route is executed first time and second time as you said. As it feels like for the first branch (trunk?) it used the 'contact' column from the location table, and for the other branches, it tries to use 'received'?
It seems db_lookup() creates multiple branches. Is lookup() only finding 1 contact in table or multiple contacts?
regards Klaus
Yufei
On 18/09/12 18:49, Klaus Darilion wrote:
I suspect that the branch route is first executed for the NATed client. Then the 'received' column is used as destination URI. When executing the branch route again, the destination URI is still the value from the previous branch, and lookup() will not overwrite is as 'received' is not available. Then Kamailio sends the INVITE again to the first client.
You can try to set $du to Null before lookup(). ($du=null or $du=$null, not sure what the correct syntax is).
Another workaround is to use fix_nated_register() for every client (the pragmatic and more secure approach).
regards Klaus
On 18.09.2012 15:16, Yufei Tao wrote:
Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay
---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things:
- why does a lookup of dbaliases before lookup of location make such
difference?
- does lookup location work differently depending on whether it is
called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location
trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit;
}
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in REGISTER
message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ... # user location service route(LOCATION); route(RELAY);
}
Hope I have made it clear. Thanks very much!
Yufei
Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
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
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
I should have made it clearer: $du is null both before and after lookup location in LOCATION_BRANCH when no fix_nated_register was done (thus 'received' column in location table was null). When fix_nated_register was done, $du for each branch was null before lookup location, but set to 'received' after lookup location as you said. But in this case (fix_nated_register done), everything works fine.
So seems now the problem happens when: 'received' in location table is null, causing $du not to be set. I used to think $du is only set by record-route and thanks for clarifying this :)
Even when without fix_nated_register (thus no 'received'), the lookup location for each branch, i.e. y2 and y3, set $ru to the 'contact' field successfully, but $du isn't set. But Kamailio did relay to the first branch (trunk?) and not the others. So the first branch is handled differently? So maybe when $du is null, should set it to $ru on the branches?
Yufei
On 19/09/12 11:53, Klaus Darilion wrote:
On 19.09.2012 12:24, Yufei Tao wrote:
Hi Klaus
Thanks for the reply!
I check the $du, it is always null before and after the lookup. Is it only set when relaying to a proxy (from record-route), and not to a client?
That's strange. For NATed clients, $du must contain the 'received' URI. Otherwise they can not be contacted as $ru contains the private IP address.
When no fix_nated_register is called, the lookup location for both clients y2 and y3 is successful from the log, when printing out $ru after lookup. But seems Kamailio only relays to one client's IP while not others. I think there must be some differences when branch route is executed first time and second time as you said. As it feels like for the first branch (trunk?) it used the 'contact' column from the location table, and for the other branches, it tries to use 'received'?
It seems db_lookup() creates multiple branches. Is lookup() only finding 1 contact in table or multiple contacts?
regards Klaus
Yufei
On 18/09/12 18:49, Klaus Darilion wrote:
I suspect that the branch route is first executed for the NATed client. Then the 'received' column is used as destination URI. When executing the branch route again, the destination URI is still the value from the previous branch, and lookup() will not overwrite is as 'received' is not available. Then Kamailio sends the INVITE again to the first client.
You can try to set $du to Null before lookup(). ($du=null or $du=$null, not sure what the correct syntax is).
Another workaround is to use fix_nated_register() for every client (the pragmatic and more secure approach).
regards Klaus
On 18.09.2012 15:16, Yufei Tao wrote:
Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay
---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things:
- why does a lookup of dbaliases before lookup of location make such
difference?
- does lookup location work differently depending on whether it is
called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location
trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit;
}
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in
REGISTER message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ... # user location service route(LOCATION); route(RELAY);
}
Hope I have made it clear. Thanks very much!
Yufei
Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
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
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
On 19.09.2012 16:13, Yufei Tao wrote:
I should have made it clearer: $du is null both before and after lookup location in LOCATION_BRANCH when no fix_nated_register was done (thus 'received' column in location table was null). When fix_nated_register was done, $du for each branch was null before lookup location, but set to 'received' after lookup location as you said. But in this case (fix_nated_register done), everything works fine.
So seems now the problem happens when: 'received' in location table is null, causing $du not to be set. I used to think $du is only set by record-route and thanks for clarifying this :)
Even when without fix_nated_register (thus no 'received'), the lookup location for each branch, i.e. y2 and y3, set $ru to the 'contact' field successfully, but $du isn't set. But Kamailio did relay to the first branch (trunk?) and not the others. So the first branch is handled differently? So maybe when $du is null, should set it to $ru on the branches?
There is no need to set $du. If $du is null, $ru is used for routing.
Can you verify with ngrep/tcpdump (capture on 'any' interface) if there is no SIP message sent to y2/y3 or the message is sent, but to wrong destination (e.g. same target as first branch).
regards Klaus
Yufei
On 19/09/12 11:53, Klaus Darilion wrote:
On 19.09.2012 12:24, Yufei Tao wrote:
Hi Klaus
Thanks for the reply!
I check the $du, it is always null before and after the lookup. Is it only set when relaying to a proxy (from record-route), and not to a client?
That's strange. For NATed clients, $du must contain the 'received' URI. Otherwise they can not be contacted as $ru contains the private IP address.
When no fix_nated_register is called, the lookup location for both clients y2 and y3 is successful from the log, when printing out $ru after lookup. But seems Kamailio only relays to one client's IP while not others. I think there must be some differences when branch route is executed first time and second time as you said. As it feels like for the first branch (trunk?) it used the 'contact' column from the location table, and for the other branches, it tries to use 'received'?
It seems db_lookup() creates multiple branches. Is lookup() only finding 1 contact in table or multiple contacts?
regards Klaus
Yufei
On 18/09/12 18:49, Klaus Darilion wrote:
I suspect that the branch route is first executed for the NATed client. Then the 'received' column is used as destination URI. When executing the branch route again, the destination URI is still the value from the previous branch, and lookup() will not overwrite is as 'received' is not available. Then Kamailio sends the INVITE again to the first client.
You can try to set $du to Null before lookup(). ($du=null or $du=$null, not sure what the correct syntax is).
Another workaround is to use fix_nated_register() for every client (the pragmatic and more secure approach).
regards Klaus
On 18.09.2012 15:16, Yufei Tao wrote:
Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay
---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things:
- why does a lookup of dbaliases before lookup of location make such
difference?
- does lookup location work differently depending on whether it is
called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location
trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit;
}
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in
REGISTER message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ... # user location service route(LOCATION); route(RELAY);
}
Hope I have made it clear. Thanks very much!
Yufei
Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
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
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
In the problem situation, when $du is null after the lookup, and only y2 rings, I've seen 2 different things:
1. the INVITE to y3 is actually sent to Kamailio itself sometimes: when Kamailio receives this, $ru of the INVITE is correctly set to the contact of y3. Why is it sent to Kamailio itself and not y3's $ru? -- I've seen this many times during my tests but don't know why I can't reproduce this now. The syslog for this is in attached failed_group_call.txt. You can search for "route: INVITE" to see the INVITEs received by Kamailio. This is printed out at the start of my main route.
The set up for failed_group_call.txt: - Kamailio@10.82.130.244 - y1@10.82.130.135:5060 calls global.group, which has members: - y2@10.82.130.140:19322 - y3@10.82.130.140:53444
2. the INVITE to y3 is not sent at all sometimes The syslog for this call is in failed_group_call_notToSelf.txt
From this file when you search for "route: INVITE" you don't see that
for y3@10... as you would from the other log in 1. Also I've done tcpdump on all interfaces for this and can confirm there isn't INVITE sent to anywhere else either, apart from to y2.
The set up for failed_group_call_notToSelf.txt: - Kamailio@10.82.130.244 - y1@10.82.130.135 calls global.group, which has members: - y2@10.82.130.140:39598 - y3@10.82.130.140:50104
Both log files are produced with debug set to 4.
Yufei
On 19/09/12 16:23, Klaus Darilion wrote:
On 19.09.2012 16:13, Yufei Tao wrote:
I should have made it clearer: $du is null both before and after lookup location in LOCATION_BRANCH when no fix_nated_register was done (thus 'received' column in location table was null). When fix_nated_register was done, $du for each branch was null before lookup location, but set to 'received' after lookup location as you said. But in this case (fix_nated_register done), everything works fine.
So seems now the problem happens when: 'received' in location table is null, causing $du not to be set. I used to think $du is only set by record-route and thanks for clarifying this :)
Even when without fix_nated_register (thus no 'received'), the lookup location for each branch, i.e. y2 and y3, set $ru to the 'contact' field successfully, but $du isn't set. But Kamailio did relay to the first branch (trunk?) and not the others. So the first branch is handled differently? So maybe when $du is null, should set it to $ru on the branches?
There is no need to set $du. If $du is null, $ru is used for routing.
Can you verify with ngrep/tcpdump (capture on 'any' interface) if there is no SIP message sent to y2/y3 or the message is sent, but to wrong destination (e.g. same target as first branch).
regards Klaus
Yufei
On 19/09/12 11:53, Klaus Darilion wrote:
On 19.09.2012 12:24, Yufei Tao wrote:
Hi Klaus
Thanks for the reply!
I check the $du, it is always null before and after the lookup. Is it only set when relaying to a proxy (from record-route), and not to a client?
That's strange. For NATed clients, $du must contain the 'received' URI. Otherwise they can not be contacted as $ru contains the private IP address.
When no fix_nated_register is called, the lookup location for both clients y2 and y3 is successful from the log, when printing out $ru after lookup. But seems Kamailio only relays to one client's IP while not others. I think there must be some differences when branch route is executed first time and second time as you said. As it feels like for the first branch (trunk?) it used the 'contact' column from the location table, and for the other branches, it tries to use 'received'?
It seems db_lookup() creates multiple branches. Is lookup() only finding 1 contact in table or multiple contacts?
regards Klaus
Yufei
On 18/09/12 18:49, Klaus Darilion wrote:
I suspect that the branch route is first executed for the NATed client. Then the 'received' column is used as destination URI. When executing the branch route again, the destination URI is still the value from the previous branch, and lookup() will not overwrite is as 'received' is not available. Then Kamailio sends the INVITE again to the first client.
You can try to set $du to Null before lookup(). ($du=null or $du=$null, not sure what the correct syntax is).
Another workaround is to use fix_nated_register() for every client (the pragmatic and more secure approach).
regards Klaus
On 18.09.2012 15:16, Yufei Tao wrote:
Hi
I have a strange problem on forking calls to a group of users. For example I have two users y2 and y3 in dbaliases, both with alias_username 'group'. And y2 and y3 both registers with Kamailio fine. When I make a call to 'group' from a third client y1, what my kamailio.cfg does is: do an alias_db_lookup("dbaliases"), and goes to BRANCH_ALIASDB, where a lookup location will be done for each of the username resulting from lookup of dbaliases, something like this:
y1--INVITE 'group'-->lookup dbaliase-->[BRANCH_ALIASDB]--->'y2'-->lookup location---¬
| |-->relay
---->[BRANCH_ALIASDB]--->'y3'-->lookup location----
The all works well as long as all clients are NAT'ed. However when they are not NAT'ed, e.g. all on the same LAN with Kamailio, the call only goes to one of the group members, e.g. y2 only. When checking the log, it seemed to have done the dbaliases lookup fine, and each location lookup successfully. But Kamailio only relayed y2's IP, e.g. to the client, while y3's to itself.
When comparing the location table when clients are NAT'ed or not, I find that the 'received' column is only populated when I do fix_nated_register. And group calls only works when 'received' column is populated. That explains why when clients are NAT'ed group calls work, as I only do fix_nated_register if nat_uac_test returns true.
But if this is the only reason, if two clients register using the same username, e.g. both as y3, and when 'received' column of location table is empty (no fix_nated_register done), I would expect a call to y3 should also only make 1 client ring. But in fact both of them rang! The flow is like:
y1--INVITE 'y3'-->lookup location for 'y3'----> IP of 1st client registered as 'y3' | ---> IP of 2nd client registered as 'y3'
While a call to 'group' (thus dbaliases lookup took place) under such un-NAT'ed set up made only 1 client ring.
So I can make it work by always doing fix_nated_register. But I'm not clear about these things:
- why does a lookup of dbaliases before lookup of location make such
difference?
- does lookup location work differently depending on whether it is
called from trunk or from a route called from a branch route?
Following is relevant parts from my config file:
############################################################# route[LOCATION] { if ( alias_db_lookup("dbaliases") ) { t_on_branch("BRANCH_ALIASDB"); # in branch_route[BRANCH_ALIASDB], # call another route that looks up location, # if not existent, call drop()
} else { xlog("L_DBG","LOCATION: not alias - go to lookup location
trunk\n"); route(LOCATION_TRUNK); # normal look up location and sending of 404 etc }
... ... } ############################################################# branch_route[BRANCH_ALIASDB] { xlog("L_DBG", "BRANCH_ALIASDB: $fU@$fd -> $rU@$rd; Method:$rm\n"); route(LOCATION_BRANCH); }
route[LOCATION_BRANCH] { if (!lookup("location")) { # Drop this branch - it's going nowhere drop(); } } ############################################################# route[RELAY] { xlog("L_DBG","RELAY: method=$rm, callid=$ci, cseq=$cs\n");
#!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_DBG", "RELAY: about to call RTPPROXY\n"); route(RTPPROXY); } #!endif
/* example how to enable some additional event routes */ if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit;
}
############################################################ route[NAT] { #!ifdef WITH_NAT xlog("L_DBG","NAT: method=$rm, callid=$ci, cseq=$cs\n");
force_rport(); if (nat_uac_test("2")) { if (method=="REGISTER") { fix_nated_register(); xlog("L_DBG","NAT: Just done fix_nated_register in
REGISTER message in NAT route\n"); } else { xlog("L_DBG","NAT: fix_nated_contact\n"); fix_nated_contact(); } setflag(FLT_NATS); }
# setflag(FLT_NATS); ## -- YT: set NAT flag for all, so will force media relay #!endif return; }
############################################################# And in the main route, route LOCATION and RELAY are the last two routes: route { ... route(NAT);
... ... # user location service route(LOCATION); route(RELAY);
}
Hope I have made it clear. Thanks very much!
Yufei
Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
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
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
-- Yufei Tao Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ