when proxy gets ack to invite, it spits out this kind of error message:
Sep 20 22:03:35 wheezy2 /usr/sbin/sip-proxy[4575]: INFO: processing ACK <sip:jh@192.98.103.10:5074>
Sep 20 22:03:35 wheezy2 /usr/sbin/sip-proxy[4575]: WARNING: rr [loose.c:744]: no socket found for match second RR
route headers in the request are:
Route: <sip:192.98.103.10:5060;transport=tcp;r2=on;ftag=43884fd989cff6dc;lr>
Route: <sip:192.98.103.10:5060;r2=on;ftag=43884fd989cff6dc;lr>
and when i start the proxy it tells this:
Listening on
udp: 192.98.103.2 [192.98.103.2]:5070
udp: 127.0.0.1:5072
tcp: 192.98.103.2 [192.98.103.2]:5070
tcp: 127.0.0.1:5072
tcp: 127.0.0.1:6060
Aliases:
*: 192.98.103.10:5060
*: sip.test.fi:5060
why does loose_route() not find the first alias?
-- juha
is there any easy way to access URIs in one or more record-route
headers? there is @via[index], but no corresponding select for record-
route URIs.
-- juha
Hi Daniel,
This patch needs to be applied to avoid core.
Thanks
Jijo
On Wed, Sep 19, 2012 at 10:54 AM, Jijo <realjijo(a)gmail.com> wrote:
>
> 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: <script>:
> CI=1-3292(a)10.233.20.152 -R39 - Entry R-URI=1234 FD=10.233.20.152
> SI=10.233.20.152
>
> 2012-09-19T02:06:17+01:00 [info] sipserver: [27294] INFO: <script>:
> CI=1-3292(a)10.233.20.152 -R1 - Force LAN socket: tcp:10.233.20.151:5060<null>
>
> 2012-09-19T02:06:17+01:00 [info] sipserver: [27303] INFO: <script>:
> CI=1-3292(a)10.233.20.152 -R1 - Force LAN socket: tcp:10.233.20.151:5060<null>
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:2357]: tcp_conn_send_put : calling wbufq_add
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:730]: ERROR: wbufq_add(722 bytes): buf:SUBSCRIBE
> sip:1234@10.233.20.141:5063;transport=tcp SIP/2.0
>
> Record-Route: <sip:10.233.20.151;tran
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:747]: ERROR: wbufq_add(722 bytes): first:b00519f4 last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27303] ERROR: <core>
> [tcp_main.c:774]: ERROR: wbufq_add(2 last free crt_size:722):
> first:b00519f4 last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27294] ERROR: <core>
> [tcp_main.c:796]: ERROR: wbufq_insert(1282 bytes): buf:NOTIFY
> sip:1234@10.233.20.141:5063;transport=tcp SIP/2.0
>
> Record-Route: <sip:10.233.20.151;transpo
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27294] ERROR: <core>
> [tcp_main.c:801]: ERROR: wbufq_insert(2 last free ): first:b00519f4
> last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27294] ERROR: <core>
> [tcp_main.c:820]: ERROR: wbufq_insert(22 last free ): first:b00519f4
> last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [err] sipserver: [27359] ERROR: <core>
> [tcp_main.c:887]: ERROR: wbufq_run(3 last free ): first:b00519f4
> last:b00519f4
>
> 2012-09-19T02:06:17+01:00 [crit] sipserver: [27359] : <core>
> [mem/q_malloc.c:157]: BUG: qm_*: fragm. 0xb00519dc (address 0xb00519f4) end
> overwritten(0, 0)!
>
> 2012-09-19T02:06:18+01:00 [alert] sipserver: [27265] ALERT: <core>
> [main.c:755]: child process 27359 exited by a signal 11
>
> 2012-09-19T02:06:18+01:00 [alert] sipserver: [27265] ALERT: <core>
> [main.c:758]: core was generated
>
> 2012-09-19T02:06:18+01:00 [info] sipserver: [27265] INFO: <core>
> [main.c:770]: INFO: terminating due to SIGCHLD
>
>
>
> Process 27294(NOTIFY) created the TCP connection structure for destination
> IP and just before calling wbufq_insert(), context switch happened and
> process 27303(SUBSCRIBE) got the cpu. Since the connection structure is
> already available process 27303 add the SUBSCRIBE message(722 bytes) to
> wbufq. Afterwards process 27294 got the CPU and invoked wbufq_insert()
> which basically corrupted the memory due to an overflow with the existing
> implementation.
>
>
>
>
>
> inline static int _wbufq_insert(struct tcp_connection* c, const char*
> data,
>
>
> unsigned int size)
>
> {
>
> struct tcp_wbuffer_queue* q;
>
> struct tcp_wbuffer* wb;
>
>
>
> q=&c->wbuf_q;
>
> if (likely(q->first==0)) /* if empty, use wbufq_add */
>
> return _wbufq_add(c, data, size);
>
> :
>
> :
>
> :
>
> :
>
> if ((q->first==q->last) &&
> ((q->last->b_size-q->last_used)>=size)){
>
> /* one block with enough space in it for
> size bytes */
>
>
>
> memmove(q->first->buf+size,
> q->first->buf, size);
>
> memcpy(q->first->buf, data, size);
>
> q->last_used+=size;
>
> }
>
>
>
> The above condition shall be true in this case and memmove was moving the
> pointer which was causing the overflow.
>
> memmove(void *dest, const void *src, size_t n);
>
>
>
> As per the memmove man page, the src shall be copied with size ‘n’ to a
> temporary buffer and then temporary buffer to dest.
>
>
>
> dest is q->first->buf+size: which is basically (q->first->buf + NOTIFY
> MSG SIZE). so the dst will move my 1282 bytes, so we have remaining space
> of only 818 bytes.
>
>
>
> src is q->first->buf: which is basically copied to temp buffer with NOTIFY
> SIZE(1282bytes).
>
>
>
> Finally we are moving the buffer from temporary buffer of size 1282 bytes
> to buffer which we left with 818 bytes, This basically corrupt the memory
> and on wbufq_run we see the memory corruption
>
>
>
> 2012-09-19T02:06:17+01:00 [crit] sipserver: [27359] : <core>
> [mem/q_malloc.c:157]: BUG: qm_*: fragm. 0xb00519dc (address 0xb00519f4) end
> overwritten(0, 0)!
>
>
>
> I think we don’t need memove, so we can change the code as below
>
>
>
> if ((q->first==q->last) && ((q->last->b_size-q->last_used)>=size)){
>
> /* one block with enough space in it for size bytes */
>
> //memmove(q->first->buf+size, q->first->buf, size);
>
> memcpy(q->first->buf+q->last_used, data, size);
>
> q->last_used+=size;
>
> }
>
> OR
> we need only the else part as it always add the block to the first.
>
> Thanks
> Jijo
>
> On Wed, Jul 18, 2012 at 12:42 PM, Daniel-Constantin Mierla <
> miconda(a)gmail.com> wrote:
>
>> Hello,
>>
>> sorry, I just read the last messages in the thread and I didn't noticed
>> it is about a crash, but thought it is about an annoying log message.
>>
>> The backtrace is no longer matching the latest sources of the 3.1 branch,
>> but I expect it is due to a double free issue, so you have to update to
>> latest 3.1.6, as suggested by other users here. There were many fixes from
>> 3.1.0 to 3.1.6.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 7/17/12 6:03 PM, Jijo wrote:
>>
>> Hi,
>>
>> This is not happening at shutdown or status check. Its aborting when
>> the system is active.
>>
>> Thanks
>> Jijo
>> On Tue, Jul 17, 2012 at 3:06 AM, Daniel-Constantin Mierla <
>> miconda(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>> does it keep being or it is one time and that's it?
>>>
>>> That is printed at shut down or if pkg_status() or shm_status() is
>>> executed from some part of code or in config via cfgutils module functions.
>>>
>>> You can get rid of them by setting memdbg and memlog to a value higher
>>> than debug global parameter.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 7/16/12 5:28 PM, Jijo wrote:
>>>
>>> Thanks.. It is not easy to upgrade as it is happening at customer
>>> system.
>>> Is there any change occurred for this issue.I looked at it, but didn't
>>> see anything in q_malloc.c/qm_status()
>>>
>>>
>>> On Mon, Jul 16, 2012 at 11:12 AM, Jon Bonilla <manwe(a)aholab.ehu.es>wrote:
>>>
>>>> El Mon, 16 Jul 2012 10:27:42 -0400
>>>> Jijo <realjijo(a)gmail.com> escribió:
>>>>
>>>> > Hi All,
>>>> >
>>>> > I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
>>>> > mem/q_malloc.c:763" for kamailio version 3.1.0
>>>> >
>>>>
>>>> I'd say that you're using a very old version. You should update your
>>>> branch to
>>>> 3.1.6 or upgrade to a newer branch.
>>>>
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> sr-dev(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>
Hi Kamailio Community,
Recently installed Kamailio, plan to integrate with SylkServer.
Tried the SIP IM feature, but can't seem to get it working.
Logged on to Bria and Blink, two seperate accounts.
They can call each other, but can't add each other for presence.
So I installed the presence module with apt-get and edited the
kamailio.cfg file to add the line;
#!define WITH_PRESENCE
Restarting the server comes up with the following error;
----------------------
root@opensep:~# vi /etc/kamailio/kamailio.cfg
root@opensep:~# service kamailio restart
Not starting Kamailio: invalid configuration file!
-e
0(5114) : <core> [cfg.y:3591]: parse error in config file
/etc/kamailio/kamailio.cfg, line 392, column 32-36: syntax error
0(5114) : <core> [cfg.y:3591]: parse error in config file
/etc/kamailio/kamailio.cfg, line 392, column 32-36: Invalid arguments
0(5114) : <core> [cfg.y:3594]: parse error in config file
/etc/kamailio/kamailio.cfg, line 392, column 37:
ERROR: bad config file (3 errors)
----------------------
Those lines are as follows;
----------------------
#!ifdef WITH_PRESENCE
# ----- presence params -----
modparam("presence", "db_url", DBURL)
# ----- presence_xml params -----
modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)
#!endif
----------------------
The exact place is where it says DBURL on both params.
I am using Ubuntu 12.04 and Kamailio 3.3.x.
Thank you for your time.
Kind Regards,
Gary Shergill
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
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
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 <yufei.tao(a)redembedded.com> Subject: Re: [SR-Users] call
forking using dbaliases not working for un-NATed clients To: Klaus
Darilion <klaus.mailinglists(a)pernau.at> Cc: "SIP Router - Kamailio
\(OpenSER\) and SIP Express Router \(SER\) - Users Mailing List"
<sr-users(a)lists.sip-router.org> Message-ID:
<5059D309.6030500(a)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
>>>> 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
--
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
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-ka…
>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
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
