sr-users September 2012

sr-users@lists.kamailio.org

78 participants
139 discussions

"Command not found" error during "make install"
by Youngjin Park 22 Sep '12

22 Sep '12

Hi, I faced the following error during installing "sip-router" by command "make install" after successful compilation by command "make all". I will appreciate you so much if you can shed light on. My system is 32 bit Fedora. Thanks in advance. Youngjin install -m 644 README /usr/local/share/doc/ser/ docbook2x-man -s ../../doc/stylesheets/serdoc2man.xsl auth.xml make[1]: docbook2x-man: Command not found make[1]: *** [auth.7] Error 127 make: [modules-man] Error 1 (ignored) docbook2x-man -s ../../doc/stylesheets/serdoc2man.xsl auth_db.xml make[1]: docbook2x-man: Command not found make[1]: *** [auth_db.7] Error 127 make: [modules_s-man] Error 1 (ignored) make[1]: `sercmd' is up to date.

3 6

no socket found for match second RR
by Juha Heinanen 21 Sep '12

21 Sep '12

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

4 9

any easy way to access record-route URIs?
by Juha Heinanen 21 Sep '12

21 Sep '12

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

3 5

Re: [SR-Users] [sr-dev] kamailio core at qm_status ( patch required important)
by Jijo 21 Sep '12

21 Sep '12

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 >> >> >

2 1

Kamailio OS Sysctl Tweaks
by Cenk İlker İzanlı 20 Sep '12

20 Sep '12

Hi, Is there any sysctl tweaks for OS to get the most of Kamailio as performance meaning? Thx

2 2

Kamailio Presence module
by Gary Shergill 20 Sep '12

20 Sep '12

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

3 8

authentication for client applications
by David Thomson 20 Sep '12

20 Sep '12

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

3 2

call forking using dbaliases not working for un-NATed clients
by Yufei Tao 19 Sep '12

19 Sep '12

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

2 6

Re: [SR-Users] call forking using dbaliases not working for un-NATed clients
by Yufei Tao 19 Sep '12

19 Sep '12

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

1 0

IM on Kamailio
by Gary Shergill 19 Sep '12

19 Sep '12

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

4 4

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users September 2012