[SR-Users] authentication for client applications
David Thomson writes: > Is it possible to include a public key and digital signature in the > register events and have kamailio perform the transformation to > validate the client's identity? If so which module provides such > functionality? Has something like this been implemented in the past? if you put signature info in some custom header of sip request, kamailio has many ways to pass that info to external server that performs validation unless a straight db query directly from kamailio is not enough. -- juha ___ 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] authentication for client applications
Hi, I am working on a project where a custom sip client will be integrated into a suite of applications to provide voip. The sip client will be working with Kamailio. The goal is to ensure that the client is authorized for communication with kamailio before allowing any calls to be made. Conventional username/password authentication for individual users will also be used once the client has been authenticated. Currently other applications in the suite use a digital signature in the http headers when communicating with server processes. If the signature is validated by the server process then the applications identity is validated and communication with the server process is allowed. Is it possible to include a public key and digital signature in the register events and have kamailio perform the transformation to validate the client's identity? If so which module provides such functionality? Has something like this been implemented in the past? Thanks for any input. ttyl,Dave ___ 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] IM on Kamailio
Hi Everyone, > You don't need to do anything to support MESSAGE requests on Kamailio. >> Following the guide from the web site, you will enable Presence. >> However, your problem seems to be with the client software. >> If I am correct, Blink uses Session mode (MSRP) for IM service. >> Bria uses Page mode (sip MESSAGE requests) for that. >> Try to use other clients, for example Jitsi. >> Presence and IM should be working there. Thank you Martian! Using Jitsi it works perfectly, IM and presence and audio too on calls. Even works when I turn on SylkServer and log on to an account from there; (@.) Thanks again, great help here =) Kind Regards, Gary Shergill ___ 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] Kamailio Presence module
Hi Andreas, === >Check what's in line 392, it should give you a hint what's wrong. === That's where it mentions the DBURL. I think I fixed this issue by, instead of using DBURL, I just use the location (mysql://...). That allows Kamailio to restart with no issues (so I assume it means presence is working as well, just need to get two clients that are free and compatible). === >There are two ways doing IM in >SIP: one is page-mode using MESSAGE requests, which should take pretty >much the same route as INVITE (that is: authorization of caller, >normalization of callee, lookup in location table, then t_relay to >callee); === To be honest I'm really not sure what that means, I'm quite new to SIP, having previously only used Asterisk. === >the other one is MSRP, which is actually an INVITE with a >special payload. If you use sylkserver, then you can just forward the >INVITE to sylkserver, which has an MSRP relay integrated, === This is perfect, I'm actually using SylkServer (is the reason I am trying to get this configured). This may not seem like the best of questions, but how exactly would I go about forwarding an INVITE to sylkserver? At the moment I am able to log on to a SIP Client using the details; @. Where the SylkServer user is created on SylkServer's Openfire install. I believe this means that SylkServer recognises my Kamailio server already. Thank you. Kind Regards, Gary Shergill ___ 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] call forking using dbaliases not working for un-NATed clients
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 clien
Re: [SR-Users] call forking using dbaliases not working for un-NATed clients
In LOCATION_BRANCH, after lookup location, I've added: if ($du==$null)
$du=$ru; And now everything works! In summary, either of the following
would fix the problem: 1. call fix_nated_contact for all clients, so
that 'received' column in location table is populated (so that $du will
be set), or 2. set $du after lookup if it is empty Wonder if it is worth
adding fixes in the source code. Thanks very much Klaus for pointing me
to the right direction! Yufei Date: Wed, 19 Sep 2012 15:13:29 +0100
From: Yufei Tao Subject: Re: [SR-Users] call
forking using dbaliases not working for un-NATed clients To: Klaus
Darilion Cc: "SIP Router - Kamailio
\(OpenSER\) and SIP Express Router \(SER\) - Users Mailing List"
Message-ID:
<5059d309.6030...@redembedded.com> Content-Type: text/plain;
charset="ISO-8859-1" 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
>>
Re: [SR-Users] [sr-dev] kamailio core at qm_status
Hi All, Finally i found the issue, Here is one of the bad trace for SUBSCRIBE(722bytes) and NOTIFY(1282bytes) which corrupted the memory. The messages came in the order NOTIFY and SUBSCRIBE. The core is generated in a different place but I believe this could be the reason for memory corruption. Here is the trace UDP Process 27294 processing NOTIFY and Process 27303 processing SUBSCRIBE . The explanation and implementation is below 2012-09-19T02:06:17+01:00 [info] sipserver: [27303] INFO:
Re: [SR-Users] call forking using dbaliases not working for un-NATed clients
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 p
Re: [SR-Users] Kamailio-Redirect based LCR routing
Hi Daniel,
Thank you very much..
The below script works fine.
I've been a long time struggling with script while the problem was in the
x-lite. After using another phone things went smooth.
Thanks a lot.
Cheers,
F Chahrour
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: Wednesday, September 12, 2012 5:15 PM
To: Fatima Chahrour~Vanrise Support
Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List'
Subject: Re: [SR-Users] Kamailio-Redirect based LCR routing
Hello,
I am not very familiar with the code of the lcr module to see if you get
access to the destination addresses via some variables, but probably you can
try to do a loop on next_gw():
while(next_gw()) {
km_append_branch();
}
sl_send_reply("302","Moved Temporary");
exit;
Cheers,
Daniel
On 9/12/12 2:57 PM, Fatima Chahrour~Vanrise Support wrote:
Hello,
Any help?
Cheers,
F Chahrour
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Fatima
Chahrour~Vanrise Support
Sent: Tuesday, September 11, 2012 11:37 AM
To: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List'; mico...@gmail.com
Subject: Re: [SR-Users] Kamailio-Redirect based LCR routing
Hi,
Sorry!!! You already mentioned to me that I should use
km_append_branch("uri") in order to send multiple contacts.
I tried it now as follow:
Km_append_branch($ru) or Km_append_branch()
sl_send_reply("302","Moved Temporary")
Am getting in the contacts the first lcr_gw twice;
Contact: sip:961377888@192.168.111.195, sip:961377888@192.168.111.195.
What variable should I use to list all contacts of lcr_gw?
Kind regards,
F Chahrour
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Fatima
Chahrour~Vanrise Support
Sent: Monday, September 10, 2012 11:50 PM
To: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List'; mico...@gmail.com
Subject: [SR-Users] Kamailio-Redirect based LCR routing
Dear Daniel\List,
Following up to a previous post where I was able in my testing lab to
redirect call with 1st destination of lcr_gw table to another
Kamailio(acting as any SBC) with Daniels assist, I need a hand in
redirecting the call with multiple contacts , basically based on the lcr
routing rule configured in kamailio LCR module for the rerouted call.
Is this possible using code 300 with multiple choices message? Or you advise
me with another method?
If 300 redirect message works, what should be the variable set as $ru to get
all lcr_gw destinations?
Example for clarification:
My current redirect script used after lcr functions is :
..
$ru= $ru;
sl_send_reply("302","Moved Temporary");
..
This script is successfully sending the 302 message with Contact:
sip:1119613454646@192.168.111.195. (1119613454646 is the dialed number with
prefix, 192.168.111.195 is first lcr_gw ip). Now if the call to
192.168.111.195 is failed and I need to redirect the second destination,
second lcr_gw ip, how can I achieve this?
Thank you for your usual response.
Kind Regards,
F Chahrour
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -
http://asipto.com/u/katu
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IM on Kamailio
Hi Gary! You don't need to do anything to support MESSAGE requests on Kamailio. Following the guide from the web site, you will enable Presence. However, your problem seems to be with the client software. If I am correct, Blink uses Session mode (MSRP) for IM service. Bria uses Page mode (sip MESSAGE requests) for that. Try to use other clients, for example Jitsi. Presence and IM should be working there. Martin __ Od: "Gary Shergill" Komu: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List" Dátum: 19.09.2012 08:31 Predmet: [SR-Users] IM on Kamailio Hi Kamailio Community, I've been configuring the presence module on Kamailio and trying to get it working, using the following as a guideline; http://nil.uniza.sk/instant-messaging/simple/configuring-im-and-presence-kamailio-31-howto From that I assumed that enabling Presence would mean that IM would be enabled too. However, that doesn't seem to be the case. May I ask please how to configure IM on Kamailio? Note that I am testing this with one computer connected by Bria and another computer connected via Blink. I am able to log on to a user on each (test1 and test2) and they are able to call each other. The issue is, with presence enabled, they are unable to IM each other (or add each other as contacts and see online status). Thank you. Kind Regards, Gary Shergill ___ 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] call forking using dbaliases not working for un-NATed clients
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[
Re: [SR-Users] Registration Authentication Error
On 09/18/2012 04:58 PM, Nathaniel L Keeling III wrote: > 11(28548) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b8560) result > set > 11(28548) DEBUG: auth_db [authorize.c:124]: HA1 string calculated: > e13d569284e76a33ca63e4d6203f844a > 11(28548) DEBUG: auth [api.c:211]: check_response: Our result = > '18210b5da2b3d27e6ba50977072599ea' > 11(28548) DEBUG: auth [api.c:221]: check_response: Authorization failed What realm do you use for proxy_challenge? Does it match the realm configured in the client? You can calculate and check the digest response yourself by using a simple script like http://code.google.com/p/variman/source/browse/website/trunk/docroot/support/digest.php ___ 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] call forking using dbaliases not working for un-NATed clients
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=
Re: [SR-Users] IM on Kamailio
You can configure msilo module parameters as here (for offline user's
message storing)
http://telephonynetworks.blogspot.com/2012/08/configuracion-de-kamailio-33-con-nat.html
*/*Este modulo es opcional, se utiliza para guardar mensajes en la
base de datos si el usuario esta offline, y se lo envia cuando vuelva
a estar en linea, para activarlo debes escribir al principio #!define
WITH_MSILO y cambiar las siguientes lineas*/*
#!ifdef WITH_MSILO
# -- msilo params --
modparam("msilo","db_url",DBURL)*modparam("msilo","from_address","sip:registrar@your_public_ip")*
#modparam("msilo","contact_hdr","Contact: \r\n")
modparam("msilo","content_type_hdr","Content-Type: text/plain\r\n")
modparam("msilo","offline_message","*** User $rU is offline!")
#modparam("msilo", "check_time", 10)
#!endif
2012/9/19 Andrew Pogrebennyk
> On 09/18/2012 12:15 PM, Gary Shergill wrote:
> > Note that I am testing this with one computer connected by Bria and
> > another computer connected via Blink. I am able to log on to a user on
> > each (test1 and test2) and they are able to call each other. The issue
> > is, with presence enabled, they are unable to IM each other (or add
> > each other as contacts and see online status).
>
> Gary,
> I thought Bria uses RPID data format for presence (RFC 4480) while Blink
> uses PIDF so they won't be able to see presence status of each other. I
> see though that blink website mentions RPID as well, maybe somebody more
> knowledgeable about blink can correct me.
>
> For IM, add MESSAGE method to supported methods and send it after lookup
> like INVITE. For offline message delivery, checkout the msilo module
> readme.
>
> HTH,
> Andrew
>
> ___
> 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] IM on Kamailio
On 09/18/2012 12:15 PM, Gary Shergill wrote: > Note that I am testing this with one computer connected by Bria and > another computer connected via Blink. I am able to log on to a user on > each (test1 and test2) and they are able to call each other. The issue > is, with presence enabled, they are unable to IM each other (or add > each other as contacts and see online status). Gary, I thought Bria uses RPID data format for presence (RFC 4480) while Blink uses PIDF so they won't be able to see presence status of each other. I see though that blink website mentions RPID as well, maybe somebody more knowledgeable about blink can correct me. For IM, add MESSAGE method to supported methods and send it after lookup like INVITE. For offline message delivery, checkout the msilo module readme. HTH, Andrew ___ 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
