sr-users December 2009

sr-users@lists.kamailio.org

67 participants
96 discussions

[Kamailio-Users] Problem with ACK
by Ricardo Martinez 07 Dec '09

07 Dec '09

Hello List. I'm testing the last kamailio versión 1.5.3. I'm using the default configuration file and a gateway sending calls to a registered device. Gw : 10.0.0.7 Proxy : 10.0.0.11 Registered device : 10.0.0.20 This is what I see : U 10.0.0.7:5060 -> 10.0.0.11:5060 INVITE sip:5501234567@10.0.0.11 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Supported: timer, replaces, early-session. Min-SE: 1800. Date: Mon, 07 Dec 2009 16:17:13 GMT. User-Agent: AddPac SIP Gateway. Contact: <sip:3341876@10.0.0.7>. Accept: application/sdp. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REFER, NOTIFY, INFO. Content-Type: application/sdp. Content-Length: 238. Max-Forwards: 70. . v=0. o=3341876 1260202633 1260202633 IN IP4 10.0.0.7. s=AddPac Gateway SDP. c=IN IP4 10.0.0.7. t=1260202633 0. m=audio 23068 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. U 10.0.0.11:5060 -> 10.0.0.7:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0. . U 10.0.0.11:5060 -> 10.0.0.20:5060 INVITE sip:5501234567@10.0.0.20:5060;transport=udp SIP/2.0. Record-Route: <sip:10.0.0.11;lr=on>. Via: SIP/2.0/UDP 10.0.0.11;branch=z9hG4bKd506.b3a3dd83.0. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Supported: timer, replaces, early-session. Min-SE: 1800. Date: Mon, 07 Dec 2009 16:17:13 GMT. User-Agent: AddPac SIP Gateway. Contact: <sip:3341876@10.0.0.7>. Accept: application/sdp. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REFER, NOTIFY, INFO. Content-Type: application/sdp. Content-Length: 238. Max-Forwards: 69. . v=0. o=3341876 1260202633 1260202633 IN IP4 10.0.0.7. s=AddPac Gateway SDP. c=IN IP4 10.0.0.7. t=1260202633 0. m=audio 23068 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. U 10.0.0.20:5060 -> 10.0.0.11:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.0.0.11;branch=z9hG4bKd506.b3a3dd83.0. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. Record-Route: <sip:10.0.0.11;lr=on>. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>;tag=3079903260. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO. Allow-Events: talk, hold, conference, LocalModeStatus. Contact: "5501234567" <sip:5501234567@10.0.0.20:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1B6C7A>". Server: Aastra 57i/2.5.0.82. Supported: gruu, path. Content-Length: 0. . U 10.0.0.11:5060 -> 10.0.0.7:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. Record-Route: <sip:10.0.0.11;lr=on>. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>;tag=3079903260. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO. Allow-Events: talk, hold, conference, LocalModeStatus. Contact: "5501234567" <sip:5501234567@10.0.0.20:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1B6C7A>". Server: Aastra 57i/2.5.0.82. Supported: gruu, path. Content-Length: 0. . U 10.0.0.20:5060 -> 10.0.0.11:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.0.0.11;branch=z9hG4bKd506.b3a3dd83.0. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. Record-Route: <sip:10.0.0.11;lr=on>. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>;tag=3079903260. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO. Allow-Events: talk, hold, conference, LocalModeStatus. Contact: "5501234567" <sip:5501234567@10.0.0.20:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1B6C7A>". Server: Aastra 57i/2.5.0.82. Supported: gruu, path, timer, replaces. Content-Type: application/sdp. Content-Length: 210. . v=0. o=MxSIP 0 0 IN IP4 10.0.0.20. s=SIP Call. c=IN IP4 10.0.0.20. t=0 0. m=audio 3000 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. U 10.0.0.11:5060 -> 10.0.0.7:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. Record-Route: <sip:10.0.0.11;lr=on>. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>;tag=3079903260. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 INVITE. Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO. Allow-Events: talk, hold, conference, LocalModeStatus. Contact: "5501234567" <sip:5501234567@10.0.0.20:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1B6C7A>". Server: Aastra 57i/2.5.0.82. Supported: gruu, path, timer, replaces. Content-Type: application/sdp. Content-Length: 210. . v=0. o=MxSIP 0 0 IN IP4 10.0.0.20. s=SIP Call. c=IN IP4 10.0.0.20. t=0 0. m=audio 3000 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. U 10.0.0.7:5060 -> 10.0.0.11:5060 ACK SIP/2.0. Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK894be985a441. From: <sip:3341876@10.0.0.7>;tag=894be985a4. To: <sip:5501234567@10.0.0.11>;tag=3079903260. Call-ID: 892a1d4b-35e7-e926-8085-0002a401f510(a)10.0.0.7. CSeq: 41 ACK. Route: <sip:10.0.0.11;lr=on>. Content-Length: 0. Max-Forwards: 70. . The call is answered and then the ACK is sent without R-URI.. making the Proxy fails with : Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:core:parse_uri: uri too short: <> (0) Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:core:parse_sip_msg_uri: bad uri <> Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:rr:loose_route: failed to parse Request URI Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:core:parse_uri: uri too short: <> (0) Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:core:parse_sip_msg_uri: bad uri <> Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:pv:pv_get_ruri_attr: failed to parse the R-URI Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:core:parse_uri: uri too short: <> (0) Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:core:parse_sip_msg_uri: bad uri <> Dec 7 17:22:17 proxy /usr/local/sbin/kamailio[14219]: ERROR:pv:pv_get_ruri_attr: failed to parse the R-URI What could be the problem? I'm using the default configuration file, and this start happening to me since the upgrade from 1.5.2 to 1.5.3.. Hope that someone could help me. Ricardo Martinez.

2 1

[Serusers] Via: branch tags from SER for CANCELs/BYEs frequently don't match value in the INVITE
by Frank Durda IV 07 Dec '09

07 Dec '09

As you may recall, this is a problem where frequently (well, virtually all of the time) when SER passed a BYE or CANCEL message through, the device receiving such messages from SER would reject them, because the Via: header line that SER added to the BYE or CANCEL message didn't match the one that SER added to the INVITE message sent earlier. I brought this up a couple of times in the list previously. As there was not any response on this point at all, I have done some digging and have a simplified example and analysis of what SER appears to be doing wrong. First, here is an example of the problem occurring. Here are key header lines from the INVITE and a BYE message of a sample call: INVITE INPUT TO SER From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone> Call-ID: 16305237000a0285 CSeq: 252558264 INVITE SER EMITTED THIS INVITE (to called party) Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKe47c.7be033a8ca37f0e8a1c6bfe63b043efe.0 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone> Call-ID: 16305237000a0285 CSeq: 252558264 INVITE BYE INPUT TO SER (from calling party) Call-ID: 16305237000a0285 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone>;tag=15358744 CSeq: 252558265 BYE SER EMITTED THIS BYE (to called party) Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKf47c.c79c6922afd022e9b4cdf00110f17fd5.0 Call-ID: 16305237000a0285 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone>;tag=15358744 CSeq: 252558265 BYE The called switch rejects the BYE with a 481 because top-most Via: in the BYE does not match the one from the INVITE. Here are the two VIAs added by SER that do not match: INVITE Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKe47c.7be033a8ca37f0e8a1c6bfe63b043efe.0 BYE Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKf47c.c79c6922afd022e9b4cdf00110f17fd5.0 A review of how SER constructs the branch=nnnn value reveals where the differences are coming from: #1. e47c vs f47c difference caused by the Cseq: number changing between INVITE and BYE messages. The Cseq: value is supposed to be different in the INVITE and BYE per RFC 3261. The Cseq: should not be used in generating the branch=nnnn value. In this example, the BYE just happened to get the very next sequence number, but it will always be a value other than the sequence number seen in the INVITE. #2. 7be033a8ca37f0e8a1c6bfe63b043efe vs c79c6922afd022e9b4cdf00110f17fd5 is caused by ;tag=15358744 added to BYE To: header line. At minimum, any tags present on the To: and From: header should not be used in generating the branch=nnnn value because of the handling of tags in called-party-BYE situations. Also, there is no requirement in RFC 3261 that the To: nor From: header lines be used in generating the branch=nnnn value at all. Based on what I am seeing, it appears that neither the Cseq: nor the complete To: or From: header lines should have ever been used in constructing a branch=nnnn value, because of the adverse affects on CANCEL and BYE messages. Four things appear to be key to causing the branch=nnnn computation to generate non-compliant results in this example, as well as the case of a CANCEL message sent prior to the completion of the INVITE. (There could be other scenarios.) #1. The Cseq: value of the BYE will be different than the INVITE (per RFC 3261). The Cseq: header line should not ever be used in generation the hash for a branch=nnnn value as it will prevent the branch in BYE from matching the one in the INVITE. #2. If the called party generated the BYE message, the tags on the To: and From: header lines will be exchanged (also per RFC 3261), so the entire To: and From: header line's content cannot be used for generating a hash for a branch=nnnn value that is expected to match earlier messages that had a branch=nnnn value computed prior to the tag swap. #3. If a tag was previously absent on the To:/From:, a BYE from either party will add one. Again, the entire To: and From: header lines cannot be used for generating a hash for a branch=nnnn value that matches earlier messages prior to the addition of any tag. #4. Any deviation in the From: and To: header lines between INVITE and BYE/CANCEL will yield a different branch=nnnn value, even though the parameters of the From: and To: header lines may still be perfectly legal and technically identical. Any deviation may be the result of a sloppy SIP implementation in the calling equipment, but isn't valid grounds for not handling the message correctly. Examples include things like alternate number formats (as in To: sip:8885551212@66.77.88.99:5060 (seen in INVITE) versus To: <sip:8885551212@66.77.88.99:5060> (seen in CANCEL from same calling device), or differences in the amount of whitespace (including trailing whitespace), which is supposed to be ignored in SIP messages but the MD5 generator doesn't appear to know that it should ignore whitespace. Any one or a combination of these items (and possibly others) will cause the current branch=nnnn generation code in SER to generate a different branch=nnnn value and a receiving system who is following RFC 3261 will reject the BYE or CANCEL message that has passed through SER. This is non-compliant behavior. For BYE, you only get into this situation if you are using Record-Route to force the BYE message to pass through SER so that it can tear down the call (unforce_rtp_proxy() and similar actions), but for a CANCEL message, anybody can run into this problem, if syn_branch=0. So, while this defect in the branch=nnnn generation doesn't affect everybody, it still appears to be wrong. Is there by chance a compliant version of char_msg_val() exists that doesn't have these issues? That is, it doesn't use the Cseq: header line, and if it uses the From: or To: header line at all, it computes using only the called/calling digits, and not anything else that may appear on those header lines. I also don't understand why this is being MD5'ed. The RFC only says that the branch must be unique, and there are lots of cheaper has algorithms out there. Thanks for reading this far and thanks in advance for anyone who has fixed this or can come up with a fix.

4 7

[Kamailio-Users] Add Reason Header in CANCEL request (forked call)
by heinz huber 07 Dec '09

07 Dec '09

Hi everyone, I've the following question: Is it possible to add a reason header in a CANCEL request? This is helpful in the following scenario: A call gets forked by the proxy (since there are more contacts for one AOR). On the of the SIP-destination-UAs accepts the call and sends a 200 OK to the proxy. The proxy afterwards generates the CANCEL request for all open UAC transactions. In this case it would be helpful to add additional infos, like "Call completed" elsewhere, so that the call is not listed in the "missing calls" list in the destinations UAs. I've found a linke in the tracker on http://sourceforge.net/tracker/?func=detail&aid=2581449&group_id=139143&ati… Has this feature been included in the last official kamailio version, or is it still open. thx && br Andy -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

2 1

[Kamailio-Users] log not showing when using uac_replace_from( ) function
by Robert R 07 Dec '09

07 Dec '09

Hi, I simply trying to modify URI and FROM headers as follow. tcpdump packet capture shows the values are changed for both URI and FROM headers. However, the syslog only shows the new value for URI and not for FROM header. How can I verify new value in FROM header in the log file? # main request routing logic route { $rU = avp(i:1); $rd = avp(i:2); .... uac_replace_from("$avp(i:3)"); xlog ("fu after perl: $fu"); xlog ("ru after perl: $ru"); ... } Thanks, Rob

3 2

[Kamailio-Users] finding out which gw id was used
by Anders 07 Dec '09

07 Dec '09

Hi, I would like to know which gw was used for a call. Right now, it is doing this: sql_query("cb", "select id from gw where ip_addr='$rd'", "rb"); ...in route[1], but that's not good enough, because I have more than one gw with the same IP, so it just takes the first one available. If I could do something like "select id from gw where grp_id='grp_id_from_lcr'" , where grp_id_from_lcr is the the grp_id in the lcr table, which lead to the gw used... then I'd have the right id of the gw, since I use unique numbers for the grp_id in the gw table. How do I do this? Thanks!!

2 1

[Kamailio-Users] Can't connect with rtpproxy-0.2_2007-07-28
by RAJNIKANT VANZA 07 Dec '09

07 Dec '09

Hi Friends, i have problem about rtpproxy connection. /var/log/messages/ --------------------------- ERROR:nathelper:send_rtpp_command: can't connect to RTP proxy ERROR:nathelper:send_rtpp_command: proxy <unix:/var/run/rtpproxy.sock> does not respond, disable it WARNING:nathelper:rtpp_test: can't get version of the RTP proxy WARNING:nathelper:rtpp_test: support for RTP proxy <unix:/var/run/rtpproxy.sock> has been disabled temporarily i have installed successful rtpproxy-0.2_2007-07-28. run from /usr/local/sbin/rtpproxy in /var/run/ to files exists as -rw-r--r-- 1 root root 6 Dec 4 19:48 rtpproxy.pid srwxr-xr-x 1 root root 0 Dec 4 19:48 rtpproxy.sock kamailio.cfg ------------------ loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 60) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)") -- Thanks and Regards Rajnikant Vanza Call : +91-97374 56583

2 1

Symbol referencing errors (building ser-2.99.99-pre3_src_2009-12-03_ca351a on Solaris)
by Bruce McAlister 07 Dec '09

07 Dec '09

Hi All, When attempting to build SIPRouter version ser-2.99.99-pre3_src_2009-12-03_ca351a on Solaris 10 I am presented with the following error: ---- config.mak included make[1]: Entering directory `/export/home/user/packages/BUILD/ser-2.99.99-pre3/modules/ctl' Makefile.defs defs skipped make[2]: Entering directory `/export/home/user/packages/BUILD/ser-2.99.99-pre3/utils/sercmd' make[2]: Leaving directory `/export/home/user/packages/BUILD/ser-2.99.99-pre3/utils/sercmd' Makefile.defs defs skipped make[2]: Entering directory `/export/home/user/packages/BUILD/ser-2.99.99-pre3/utils/sercmd' /usr/sfw/bin/gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -m32 -minline-all-stringops -falign-loops -mtune=athlon -Wall -DNAME='"sercmd"' -DVERSION='"0.2"' -DMOD_NAME="utils/sercmd" -c parse_listen_id.c -o parse_listen_id.o /usr/sfw/bin/gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -m32 -minline-all-stringops -falign-loops -mtune=athlon -Wall -DNAME='"sercmd"' -DVERSION='"0.2"' -DMOD_NAME="utils/sercmd" -c sercmd.c -o sercmd.o /usr/sfw/bin/gcc -m32 -O2 parse_listen_id.o sercmd.o -o sercmd Undefined first referenced symbol in file bind sercmd.o getservbyname parse_listen_id.o gethostbyname sercmd.o socket sercmd.o connect sercmd.o ld: fatal: Symbol referencing errors. No output written to sercmd collect2: ld returned 1 exit status make[2]: *** [sercmd] Error 1 make[2]: Leaving directory `/export/home/user/packages/BUILD/ser-2.99.99-pre3/utils/sercmd' ERROR: make -C ../../utils/sercmd install-if-newer failed make[1]: *** [install-utils] Error 1 make[1]: Leaving directory `/export/home/user/packages/BUILD/ser-2.99.99-pre3/modules/ctl' make: *** [install-modules] Error 1 ---- Here are the steps that I have followed to get to this point: [1] make prefix=/opt/kamailio [2] make prefix=/opt/kamailio 'include_modules=db_unixodbc db_postgres cpl-c snmpstats' modules [3] make basedir=/var/tmp/pkgbuild-user/SIPRouter-2.99.99-pre3-build prefix=/opt/kamailio 'include_modules=db_unixodbc db_postgres cpl-c snmpstats' install The above error I receive is during the last step ([3]), the installation phase of SIPRouter. I'm not sure where to go from here, although it looks like it may be a resolver library that is not included along the line. Any help would be appreciated. If you need any further information, please dont hesitate to ask. Thanks Bruce

2 4

[Kamailio-Users] [kamailio-users] Error : SIP/2.0 401 Unauthorized
by RAJNIKANT VANZA 05 Dec '09

05 Dec '09

Hi Friends, need to help. *I have problem about sip : SIP/2.0 401 Unauthorized* Is it require to nathelper module in kamailio ? *what can i write kamailio.cfg file when kamailio and Asterisk on same network?* Scenario is like as : ----------------------------- 1) kamailio server on 172.18.100.74 kamailio.cfg ( nathelpler module ) ----------------- loadmodule "nathelper.so" modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "natping_interval", 60) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)") 2) Asterisk server on 172.18.100.65 sip.conf ----------- [rajnikant] nat=yes disallow=all allow=alaw allow=ulaw allow=gsm type=peer context=default host=172.18.100.74 fromdomain=rajnikant.net mailbox=user@context -- Thanks and Regards Rajnikant Vanza

2 1

[Kamailio-Users] Kamailio RTP Proxy issues
by General Lee 04 Dec '09

04 Dec '09

Hi, I am currently integrating an H323 to SIP gateway with Kamailio and trying to route all calls through RTP Proxy. I have a problem where RTP Proxy treats both the incoming H323 gateway call (Caller) and outgoing SIP call (Callee) as the 'caller' in the RTP Proxy syslog. RTP Proxy doesn't assign a 'callee' therefore not able to setup a call (See syslog below). I have configured Kamailio to accept the 'ACK' with SDP and this is working correctly. When I enable H323 Fast connect and the SDP is included in the INVITE, the call connects correctly and is routed through RTP Proxy. I feel the problem is related to RTP Proxy receiving an INVITE from the H323-SIP gateway without SDP. Can anyone explain why RTP Proxy treats both the incoming H323 Gateway call and outgoing SIP call as the 'caller' in the RTP Proxy syslog. How can I make RTP Proxy treat the incoming H323 call as the 'callee'? Thanks, More information below ******************************************************************************* My H323 endpoints use H323 Slow Connect, so when the H323-SIP Gateway delivers the 'INVITE' to Kamailio there is no SDP included in the INVITE. I added a 'onreply_route' to the Kamailio configuration file which handles the 'ACK' with SDP which is working correctly. All of my SIP calls (Signalling + Media) are forced though RTP Proxy and I would like to force all H323-SIP Gateway calls through RTP Proxy. When placing a call from my H323 endpoint to my SIP UA, the RTP Proxy syslog records the incoming and outgoing call, however RTP Proxy states that the ‘callee’ is actually the 'caller'. The RTP Proxy syslog also states that the caller is the caller so there is no 'callee' (see below). In the syslogs both the ‘callee’ and ‘caller’ are recognised as the ‘caller’ so RTP Proxy has no callee to send the traffic back to. When the INVITE is received the ‘callee’ is populated in the syslogs as the ‘caller’. The H323 Gateway call is not recorded until after the ‘ACK’ with SDP is received from the gateway. Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49620 (Should be callee) Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49622 (Should be callee) Then after the ‘ACK’ is received from the Gateway, the H323 call is mentioned in the syslog as well as the other caller who is supposed to be the callee. Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 69.72.11.51:10204 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 69.72.11.51:10214 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49620 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49622 -- View this message in context: http://www.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26112049.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

3 12

Build Error for v3.0.0-rc2 (2009-12-03_3ed668) on Solaris
by Bruce McAlister 03 Dec '09

03 Dec '09

Hi All, I am trying to build Kamailio v3.0.0 RC2 on Solaris 10 (note: *not* OpenSolaris), but I have been faced with a couple issues I hope you can help me with. The first issue has to do with GNU as (/usr/sfw/bin/gas), there appears to be a check somewhere for what I assume to be the version number of the GNU assembler. When the make is running "/usr/sfw/bin/gas -V" it just hangs at this point with the following output from make: ---- make prefix=/opt/kamailio Makefile:248: config.mak: No such file or directory normal Makefile.defs exec target architecture <i386>, host architecture <x86_64> ---- I did a process listing and noticed the following process waiting: 1719 make prefix=/opt/kamailio 1763 /bin/sh -c if [ -z "/usr/sfw/bin/gas" ] ; then echo "as" ; else if /usr/sfw/bin 1764 /usr/sfw/bin/gas -V I ended up making a wrapper script that just output the version information for "/usr/sfw/bin/gas -V" which let me get a little further. The wrapper script looks as follows: ---- #/bin/ksh if [ "$1" = "-V" ]; then echo "GNU assembler version 2.15 (i386-pc-solaris2.10) using BFD version 2.15" exit else /usr/sfw/bin/gas.bin $@ fi ---- However, when I now try a "make prefix=/opt/kamailio" I am faced with the following error: ---- gcc: installation problem, cannot exec `/usr/sfw/bin/gas': Exec format error ---- The complete output of the make is as follows: ---- make prefix=/opt/kamailio Makefile:248: config.mak: No such file or directory normal Makefile.defs exec target architecture <i386>, host architecture <x86_64> making config... yacc -d -b cfg cfg.y conflicts: 5 shift/reduce flex cfg.lex Makefile.defs defs skipped /usr/sfw/bin/gcc -g -O9 -funroll-loops -Wcast-align -m32 -minline-all-stringops -falign-loops -mtune=athlon -Wall -DNAME='"kamailio"' -DVERSION='"3.0.0-rc2"' -DARCH='"i386"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"/usr/sfw/bin/gcc 3.4.3"' -D__CPU_i386 -D__OS_solaris -DSER_VER=3000000 -DCFG_DIR='"/opt/kamailio/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DSTATISTICS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c action.c -o action.o gcc: installation problem, cannot exec `/usr/sfw/bin/gas': Exec format error make: *** [action.o] Error 1 ---- If I remove the wrapper script then the make just hangs on the command "/usr/sfw/bin/gas -V". Would anyone know how I could work around the issue? Just an FYI, I am able to build Kamailio 1.5.2-notls on the same machine without any errors/hangs, although we are considering moving to Kamailio 3/Sip-Router when it is officially released, this is why I am trying to build v3.0.0 RC2 at the moment. If you need any further information please dont hesitate to ask, any help in resolving the issue would be greatly appreciated. Thanks Bruce

3 4

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

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