sr-users April 2012

sr-users@lists.kamailio.org

75 participants
132 discussions

Re: [SR-Users] Installing in a non-standard path

by Alex Balashov

The prefix only specifies the destination for the build targets. As far as things like module paths, they are not affected. You will have to change them manually in kamailio.cfg. However, the good news is that there aren't a whole lot of paths to change; you really only need to change it in kamailio,cfg, and in any init scripts. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com Daniel Gonzalez <gonvaled(a)gonvaled.com> wrote: >Hello, > >This is my first message to this list. > >I have installed sip-router as follows (my system is Ubuntu 10.04): > > cd /tmp > git clone --depth 1 git://git.sip-router.org/sip-router sip-router > cd sip-router > git checkout -b 3.1 origin/3.1 > local prefix=/tmp/my/very/strange/path > mkdir -p $prefix > sudo apt-get install -y flex > sudo apt-get install -y docbook2x > make proper > make cfg prefix=$prefix > make all prefix=$prefix > make install prefix=$prefix > >And this has worked as expected. > >Now I try to start the daemon: > > $ /tmp/my/very/strange/path/sbin/ser > loading modules under /usr/lib/ser/modules:/usr/lib/ser/modules_s > >What can I do so that my non-standard path is fully recognized by all >sip router tools? > >Thanks, >Daniel Gonzalez > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users(a)lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

12 years

Kamailio 3.2.2 Error - usrloc

by Gilbert T. Gutierrez, Jr.

12 years

Send() function

by Gustavo Vidovich

Hi everyone, We are using Kamailio as a dispatcher to other two Kamailio servers and want it to stateless forward messages without adding a VIA header. We try to use the send function, but you can not give a pseudo variable as a parameter ($dd in this case as this variable is set by the ds_select_dst() function). We attemp to add a rule for this function to accept pseudo variables as an argument (in cfg.y file, pvar argument) but the problem was that when starting Kami (our friendly name for the Kamailio server), the pseudo variable is empty, then the program attemp to do a dns lookup trying to solve the empty string and obviously fail to start. We partially solve the issue by hard-coding the IP's to dispatch (the only way to make the send() function to work was the sintaxis "send(IP)"). We want a little bit elegancy in configuration file, but can not solve in another way. Any brighter ideas to make it work? Cheers from Uruguay, ODT

12 years

Installing in a non-standard path

by Daniel Gonzalez

Hello, This is my first message to this list. I have installed sip-router as follows (my system is Ubuntu 10.04): cd /tmp git clone --depth 1 git://git.sip-router.org/sip-router sip-router cd sip-router git checkout -b 3.1 origin/3.1 local prefix=/tmp/my/very/strange/path mkdir -p $prefix sudo apt-get install -y flex sudo apt-get install -y docbook2x make proper make cfg prefix=$prefix make all prefix=$prefix make install prefix=$prefix And this has worked as expected. Now I try to start the daemon: $ /tmp/my/very/strange/path/sbin/ser loading modules under /usr/lib/ser/modules:/usr/lib/ser/modules_s What can I do so that my non-standard path is fully recognized by all sip router tools? Thanks, Daniel Gonzalez

12 years

to tag not correctly inserted in rtpproxy command with kamailio 3.2.2

by Laurent Schweizer

Dear all, I see that in some scenario the To Tag is not passed in the command string to configure the rtpproxy. At least I see this scenario: I start a call -> all is ok I do a ReINVITE without any SDP in the INVITE , so I call the rtp_offer() for the 200 OK and the function rtpproxy_answer() for the ACK The problem is with the function rtpproxy_answer() only the from tag is passed so the stream cannot be found (lookup request failed) I do a test with the version 3.2.1 and they was no problem. Bellow rtpproxy log of both version. Regards Laurent With ver: 3.2.2 Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "24732_28 Uc0,8,18,101 ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92 62.12.250.165 62968 pm04tutcvv;1 1332342221131;1" Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 11416/18748, session timer restarted Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: update Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: update from cmd requested Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: new IP : 62.12.250.165's address port 62968 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: old IP: 62.12.250.165 address port 26495 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: RTP IP are the same, we don't update them Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: RTCP IP are the same, we don't update them Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "24732_28 18748 50.10.21.8#012" Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "24679_17 Lc0,101 ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92 50.10.21.92 64078 pm04tutcvv;1" Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: lookup request failed: session ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92, tags pm04tutcvv;1/NONE not found Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "24679_17 0 50.10.21.8#012" With ver: 3.2.1 Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "10958_13 Uc0,8,18,101 4e21d3a85ce70fe0dfa28f517484cba1(a)50.10.21.92 62.12.250.165 56522 jddmr2qwrf;1 1332350278581;1" Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 9974/16864, session timer restarted Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: update Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: update from cmd requested Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: new IP : 62.12.250.165's address port 56522 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: old IP: 62.12.250.165 address port 29436 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: RTP IP are the same, we don't update them Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: RTCP IP are the same, we don't update them Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "10958_13 16864 50.10.21.8#012" Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "10793_9 Lc0,101 4e21d3a85ce70fe0dfa28f517484cba1(a)50.10.21.92 50.10.21.92 63990 jddmr2qwrf;1 1332350278581;1" Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 9974/16864, session timer restarted

12 years

Kamailio server with Two interface

by Marwan Idriss

Greeting, I have a Kamailio server connected to two network, Network one their an Asterisk server, at network two we have the client one a client call , the call will have no audio voice how I can solve this using Kamailio and rtp server ? Thanks for your help Regards

12 years

rtpproxy and CANCEL in serial forked scenarios

by Andreas Granig

Hi, I ran into a scenario with couple of serial forks where kamailio loops to itself and, due to the looping, the INVITE to a new branch happens before the CANCEL to an old branch. What I do at the moment is force rtpproxy in branch route, and stop rtpproxy in the failure route. The problem with this scenario is that in rtpproxy_offer and unforce_rtpproxy, the rtpproxy module only passes the call-id and from-tag to rtpproxy (because there is no to-tag yet), which then in unforce_rtpproxy for a CANCEL deletes all calls related to it (because it can only match on from-tag and call-id, obviously). This means that when I do a subsequent rtpproxy_answer for my new branch, rtpproxy doesn't find the session anymore, since it has been removed with the CANCEL. A fix I can think of is to also pass the branch of the top-most via to rtpproxy in order to perform a more fine-grained matching. Are there solutions to that out there somewhere, or is it something I should just introduce, eg. as a new param to offer/answer/unforce functions? Objections? Other approaches? Andreas

12 years

in doubt about in-dialog INVITE Route params processing

by Andrew Pogrebennyk

I've been pondering an issue with Route header parameters being not mirrored by kamailio proxy into Record-Route field on in-dialog requests over the last few hours so I thought I'd just whether I'm missing something obvious. The call scenario in UA -> lb -> proxy -> sems. Everything is fine with initial INVITE transaction where we add rr param ;rtpprx=yes. (We also use dialog module.) The UA does re-INVITE where it mirrors RR headers to Route set just fine. However, when forwarding re-INVITE kamailio proxy removes own Route header and inserts RR header without rtpproxy, did etc params. The kamailio default config from branch 3.1 routes in-dialog requests in the same fashion and I can't tell really if this is how it is supposed to work? I can workaround this by add_rr_param() but shouldn't missing did param cause a problem with dialog matching? Here is the debug with log level 3: > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:792]: Topmost route URI: 'sip:127.0.0.1:5062;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-' is me > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:257]: No next Route HF found > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:811]: No next URI found > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [rr_cb.c:97]: callback id 1 entered with <lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_handlers.c:910]: route param is '8a3.aab32831' (len=12) > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:442]: ref dlg 0x7f0a0be918b0 with 1 -> 3 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:444]: dialog id=327302058 found on entry 936 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:757]: dialog 0x7f0a0be918b0 changed from state 4 to state 4, due event 8 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_handlers.c:1042]: sequential request successfully processed > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_timer.c:117]: inserting 0x7f0a0be91900 for 127601858 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: dialog [dlg_hash.c:411]: cseq is 10760 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [rr_cb.c:97]: callback id 0 entered with <lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: uac [from.c:421]: getting 'vsf' Route param > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: uac [from.c:429]: route param is 'aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-' (len=44) > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: uac [from.c:479]: decoded uris are: new=[sip:43991001@192.168.51.210] old=[sip:sipwise-user1@192.168.51.210] > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:983]: params are <;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: siputils [checks.c:76]: totag found > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: textops [textops.c:1789]: content type is 196611 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:983]: params are <;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rr [loose.c:983]: params are <;lr;ftag=8pTM6oKWVtC4H03478xjIR34SSsYuTU5;did=8a3.aab32831;mpd=ii;rtpprx=yes;vsf=aDNlNDEjPSkBJB9/YykkNnYYdTZ0KGUsfGZxVndVe1M-> > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: INFO: <script>: Use mediaproxy for forward direction for IPv4/IPv4 - M=INVITE R=sip:127.0.0.1:5080 F=sip:sipwise-user1@192.168.51.210 T=sip:43991002@192.168.51.210 IP=192.168.51.1:35189 (127.0.0.1:5060) ID=M6obxlxpUOPPR3CQYE-d2t9-fgybDo6y > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rtpproxy [rtpproxy_funcs.c:148]: type <application/sdp> found valid > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: DEBUG: rtpproxy [rtpproxy.c:2260]: proxy reply: 30080 192.168.51.210 4#012 > Apr 4 13:23:21 sp1 /usr/sbin/kamailio[7520]: INFO: <script>: Relaying request - M=INVITE R=sip:127.0.0.1:5080 F=sip:sipwise-user1@192.168.51.210 T=sip:43991002@192.168.51.210 IP=192.168.51.1:35189 (127.0.0.1:5060) ID=M6obxlxpUOPPR3CQYE-d2t9-fgybDo6y

12 years

Problem with xpath updates of XCAP documents

by Peter Dunkley

Hi, I have been experimenting with uploading, and modifying existing, XCAP documents. I have been trying out the example from RFC 4827 and I can't get it to work with Kamailio. To upload the document (this works) I use the command: curl --digest -u 111:111 -T pidf.xml -X PUT http://192.168.0.130:5060/xcap-root/pidf-manipulation/users/sip:111@mydomai… To modify the document (this doesn't work) I use the command: curl --digest -u 111:111 -T pidf_modify.xml -H "Content-Type: application/xcap-el+xml" -X PUT http://192.168.0.130:5060/xcap-root/pidf-manipulation/users/sip:111@mydomai…'x8eg92n'%5d/note When I try to modify the document I get the error: "Apr 4 17:12:08 pd-laptop-linux kamailio[16862]: ERROR: xcap_server [xcap_server.c:596]: no new content" I went through the XCAP server code and added some debug and found that the check on xcap_misc.c:491 is succeeding (which means "no selection for xpath parent expression") and the document is not being changed. Also, from my limited understanding of XPath and libxml2, I would have expected the code path which should have been followed to go through the else clause of the conditional on xcap_misc.c:468 - which means I don't think that the xcaps_xpath_set() function is doing the right thing at all. Is there anyone here that is more familiar with libxml2 that can give me any pointers here. As far as I can tell the XCAP server code looks OK to me, and I believe the documents (attached) and my XCAP queries are correct as well. Thanks, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd

12 years

Acc Module - logging forked calls.

by Stephen Dodge (Bistech)

Hello, We currently use the acc module to capture information to generate CDR missed call info. I have now introduced serial forking and I would like to see if I can improve how accounting is working for missed calls. I am using the following configuration. # turn accounting on for all new calls if (is_method("INVITE")){ setflag(1); # do accouting setflag(2); # missed calls record_route(); } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")){ setflag(1); # do accounting setflag(3); # even if the transaction fails xdbg("## BISNET ## - RTPPROXY CHECK \n"); # clear any rtpproxy sessions in progress unforce_rtp_proxy(); } I've noticed that accounting for missed calls is generated for the main branch (1st destination) only, whether this is a 486 response or a 408 on expiry of the 'fr_inv_timer'. After a receiving a failure another destination is created/tried by the script, we are allowing up to 4 serial forks. I do see the 183 message for each fork and if the call is answered then the acc table is updated correctly. How can I log the missed call response for each fork, or only log the final failure message for the call? Logging failed transactions seems to put them into the main acc table and not the missed call table which I would have expected. Thanks, Steve. ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded.

12 years

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

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