sr-users August 2014

sr-users@lists.kamailio.org

73 participants
131 discussions

Understanding hashtable usage
by aft 27 Aug '14

27 Aug '14

Hi, I've got a piece of config code which should solve my problem, but i'm not getting the code. It involves hashtable module. Here it goes : modparam("htable", "htable", "a=>size=8;autoexpire=400") modparam("htable", "htable", "b=>size=8;autoexpire=31") Ok we have two hashtable , a and b, both has a "size" of 8. Then, else if(status == "503") { if($sht(a=>alarm::503) == $null) $sht(a=>alarm::503)=0; $sht(a=>alarm::$si::503) = $sht(a=>alarm::$si::503) + 1; } Here i get lost. what's "a=>alarm::503" and what's "a=>alarm::$si::503"? What's there difference? Next the code goes like :(its supposed be pseduocode) $elem = the size of the sht array. while($i < $elem) { $src_ip = $sht(source_ip_array)[$i]; $i = $i +1; sql_query("cb", "INSERT INTO alarm_data (create_date, type, total, description, source_ip) VALUES(NOW(), 'Too Many 503', $sht(a=>alarm::$src_ip::503), 'service unavailable', '$src_ip')"); } Now i have couple of problems with this code [1] what should be the value of $elem? [2] $sht(source_ip_array)[$i]? what should be the value of source_ip_array? The thing i'm trying to do is, when a 503 (Service unavailable) comes to kamailio, I want to insert it into a database which records this. -- -Cheers -Arif

1 0

match_dialog not handling BYE
by Satish Patel 26 Aug '14

26 Aug '14

I really want to use top hide using dialog module but having very difficult time.. [UA]------[Opensips]-----[Asterisk] I want to hide UA so Asterisk doesn't know its IP. I have following config, Please correct me if anything wrong in my config, Problem is if callee whoever connected to asterisk hangup call it doesn't not know where to send BYE because of top hiding remove all return routes.. i am surprise how it is working with other folks? something must be wrong in my config then.. if (loose_route() || match_dialog()) { if ($DLG_status==NULL) { xlog(" cannot match request to a dialog \n"); # something wrong - might want to drop such requests } if (is_method("BYE") { setflag(ACC_DO); # do accounting ... setflag(ACC_FAILED); # ... even if the transaction fails acc_aaa_request("Internally generated BYE"); end_media_session(); } else if (is_method("INVITE")) { # even if in most of the cases is useless, do RR for # re-INVITEs alos, as some buggy clients do change route set # during the dialog. record_route(); } .... .... if ( uri=~"^sip:[0-9]*@.*") { uac_replace_from("sip:4545@65.xxx.xxx.xxx"); t_on_failure("3"); resetflag(7); topology_hiding(); t_relay( "udp:65.xxx.xxx.xxx" );

1 0

Not able to start tls on port 5061
by Debojit Kakoti 26 Aug '14

26 Aug '14

I am getting error INFO: tls [tls_init.c:385]: init_tls_compression(): tls: init_tls: disabling compression... -- Debojit Kakoti Mobile : +91 9650654870 Email : debojkakoti88(a)gmail.com Skype : deboj1988

2 1

Re: [SR-Users] sr-users Digest, Vol 111, Issue 21
by Rakesh Sharma 23 Aug '14

23 Aug '14

How to configure 3 kamailio on three different node, and they work as a single kamailio proxy. which module or method need to implement. On Fri, Aug 22, 2014 at 3:30 PM, <sr-users-request(a)lists.sip-router.org> wrote: > Send sr-users mailing list submissions to > sr-users(a)lists.sip-router.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > or, via email, send a message with subject or body 'help' to > sr-users-request(a)lists.sip-router.org > > You can reach the person managing the list at > sr-users-owner(a)lists.sip-router.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-users digest..." > > > Today's Topics: > > 1. force_send_socket in event route tm:local-request > (Kristian F. H?gh) > 2. Re: SIP Trunk (Satish Patel) > 3. Re: SIP Trunk (Yuriy Gorlichenko) > 4. Re: CNXCC curious case (Carlos Ruiz D?az) > 5. Kamailio script editor (Grant Bagdasarian) > 6. Re: Kamailio script editor (Narsay, Deep) > 7. Re: Kamailio script editor (Grant Bagdasarian) > 8. Re: Kamailio script editor (Alex Balashov) > 9. Re: force_send_socket in event route tm:local-request > (Daniel-Constantin Mierla) > 10. Re: Kamailio script editor (Daniel-Constantin Mierla) > 11. switch kamailio to domain (Mihai Marin) > 12. Re: SIP Trunk (Satish Patel) > 13. Re: Kamailio script editor (M?ns Nilsson) > 14. Re: force_send_socket in event route tm:local-request > (Kristian Frederik H?gh) > 15. How to uniquely identify SIP WS / WSS endpoint (Muhammad Shahzad) > 16. nat_traversal vs nathelper for mediaproxy (Satish Patel) > 17. Re: switch kamailio to domain (Daniel-Constantin Mierla) > 18. Re: switch kamailio to domain (Mihai Marin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Aug 2014 12:00:49 +0200 > From: Kristian F. H?gh <kfh(a)uni-tel.dk> > To: <sr-users(a)lists.sip-router.org> > Subject: [SR-Users] force_send_socket in event route tm:local-request > Message-ID: <25156162.LDl4apoH3L@kfh-laptop> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > Our kamailio 4.0.6 proxy uses pua/pua_dialoginfo and an external presence > server. > The PUBLISH requests generated by pua* appear in tm:local-request event > route. > > Before sending, we call set_advertised_address and force_send_socket. > Still the requests have the IP address from the first "listen=" as source > and Via address. > The requests are send out using the correct interface and no errors are > logged. > > When forwarding SUBSCRIBE requests received from clients, > force_send_socket before t_relay_to_udp do work as expected. > > mhomed=1 solves the issue, but I prefer force_send_socket. > > Regards, > Kristian H?gh > Uni-tel > > > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Aug 2014 06:43:15 -0400 > From: Satish Patel <satish.txt(a)gmail.com> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.sip-router.org> > Cc: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.sip-router.org> > Subject: Re: [SR-Users] SIP Trunk > Message-ID: <A3BD87DA-AE2A-4E52-B70A-031A875DF111(a)gmail.com> > Content-Type: text/plain; charset=us-ascii > > I will give it a try again today, can you please make sure my t_relay() > syntax is correct? > > So t_relay will rewrite my host past right and send call to trunk. > > While ago I was using rewritehost() function but I think it's not working > with UAC registrant module. > > > Sent from my iPhone > > On Aug 21, 2014, at 3:53 AM, Daniel Tryba <daniel(a)pocos.nl> wrote: > > > On Thursday 21 August 2014 05:56:46 Satish Patel wrote: > >> if ( $rU =~ "sip:1[0-9]@*") { > > > > Try $ru instead, $rU only contains the dialled "number". So > > $ru =~ "sip:1[0-9]@*" > > or > > $rU =~ "1[0-9]" > > > > But note the regexp, that only matches the exact numbers 10 to 19, if > you are > > trying to match prefixes you are doing it wrong (tm). > > > > _______________________________________________ > > 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 > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Aug 2014 15:37:38 +0400 > From: Yuriy Gorlichenko <ovoshlook(a)gmail.com> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.sip-router.org> > Subject: Re: [SR-Users] SIP Trunk > Message-ID: > <CABSP_VczfN-giH5ghuT2A9Gnqyk_+VNa= > XFtX3tAaWDqM4kZTg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > rewritehost() sucessfully work with UAC. But As I know > 1) It statless function > 2) It read only string argumetns, and do not read variables > > > 2014-08-21 14:43 GMT+04:00 Satish Patel <satish.txt(a)gmail.com>: > > > I will give it a try again today, can you please make sure my t_relay() > > syntax is correct? > > > > So t_relay will rewrite my host past right and send call to trunk. > > > > While ago I was using rewritehost() function but I think it's not working > > with UAC registrant module. > > > > > > Sent from my iPhone > > > > On Aug 21, 2014, at 3:53 AM, Daniel Tryba <daniel(a)pocos.nl> wrote: > > > > > On Thursday 21 August 2014 05:56:46 Satish Patel wrote: > > >> if ( $rU =~ "sip:1[0-9]@*") { > > > > > > Try $ru instead, $rU only contains the dialled "number". So > > > $ru =~ "sip:1[0-9]@*" > > > or > > > $rU =~ "1[0-9]" > > > > > > But note the regexp, that only matches the exact numbers 10 to 19, if > > you are > > > trying to match prefixes you are doing it wrong (tm). > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 > > >

1 0

switch kamailio to domain
by Mihai Marin 22 Aug '14

22 Aug '14

Hello Sirs, The RLS module is eating my life. I just managed to make it work 2 months ago and now is not working anymore after I tried to put the kamailio under domain (until now it was simple ip). I don't understand why is not working but I saw a big difference that I don't understand: My environment: - the domain "domain.com" is pointing to the web server - kamailio is hosted under sip.domain.com - DNS has domain.com A record for web server's ip, sip.domain.com A record for kamailio's ip and SRV record for _sip._tcp.domain.com poting to sip.domain.dom Problem: kamailio presence is not working anymore and I think, the error is: grep_sock_info - checking if host==us: 11==14 && [domain.com] == [xx.xx.xx.xx witch is the sip.domain.com IP] If, I change domain.com in DNS to point on the same ip as sip.domain.com RLS is working. This, I can't understand. Can anyone explain me why is not working using this configuration? Also, the RLS is working if i change my domain to be sip.domain.com (ex: sip:user@sip.domain.com). Thank you. Best regards, Mihai M

2 3

force_send_socket in event route tm:local-request
by Kristian F. Høgh 21 Aug '14

21 Aug '14

Hi, Our kamailio 4.0.6 proxy uses pua/pua_dialoginfo and an external presence server. The PUBLISH requests generated by pua* appear in tm:local-request event route. Before sending, we call set_advertised_address and force_send_socket. Still the requests have the IP address from the first "listen=" as source and Via address. The requests are send out using the correct interface and no errors are logged. When forwarding SUBSCRIBE requests received from clients, force_send_socket before t_relay_to_udp do work as expected. mhomed=1 solves the issue, but I prefer force_send_socket. Regards, Kristian Høgh Uni-tel

3 2

Kamailio script editor
by Grant Bagdasarian 21 Aug '14

21 Aug '14

Hello, What editor do most of you use for editing the kamailio config script? I'm using notepad, which works fine, but sometimes I wish I had something like text coloring and other useful stuff found in most scripting editors. Are there perhaps any plans for developing an editor for the kamailio config script? With code completion, etc. Regards, Grant

5 5

SIP Trunk
by Satish Patel 21 Aug '14

21 Aug '14

We have setup Kamailio front and SIP Proxy, Now i want to Trunk it with other SIP provide they gave me IP, Username/Password. How do i configure username/password on Kamailio SIP Proxy?

4 13

CNXCC curious case
by Kelvin Chua 21 Aug '14

21 Aug '14

I am using cnxcc_set_max_channels and set the max channels to 1 after the 1st call goes through and hangs up, the 2nd one would be blocked even if there are no more active dialogs. could it be a dialog state issue? Kelvin Chua

2 3

Re: [SR-Users] automatic string to int conversion for rtpengine flags failed - rtpproxy_offer() does not change sdp when called in branch_route
by Olli Heiskanen 20 Aug '14

20 Aug '14

Hi, The source for this string to int conversion error was found, it was just a minor glitch in an if statement! Man, I feel stupid... Anyways, the problem about calls not going through still persists. This I located to the rtpengine_offer() call in a branch route. The sdp is not changed and this results in Kamailio forking away until it can't. In my test case there is a webrtc client calling another webrtc client. Here I use Kamailio 4.1.5, rtpengine and rtpproxy-ng module. My branch route looks like this: branch_route[MANAGE_RTPENGINE_BRANCH] { xlog("L_INFO", "MANAGE_RTPENGINE_BRANCH: new branch [$T_branch_idx] to $ru\n"); xlog("L_INFO", "MANAGE_RTPENGINE_BRANCH: rtpengine_offer_flags = $avp(rtpengine_offer_flags) and mline = $avp(mline)"); if ($avp(rtpengine_offer_flags) != "") { xlog("L_INFO","MANAGE_RTPENGINE_BRANCH: rtpengine_offer with $avp(rtpengine_offer_flags)"); rtpproxy_offer($avp(rtpengine_offer_flags)); t_on_reply("RTPPROXY_REPLY"); } else { xlog("L_ERR","MANAGE_RTPENGINE_BRANCH but rtp_offer_flags is EMPTY! "); } } And this is what I get in the kamailio log: Aug 20 21:47:58 u363id562 kamailio[28376]: ALERT: <script>: UA_FAILURE: SAVPF found, setting flags using RTP/AVP in offer and RTP/SAVPF in answer Aug 20 21:47:58 u363id562 kamailio[28376]: INFO: <script>: UA_FAILURE: hooked to RTPPROXY_REPLY reply_route and MANAGE_RTPENGINE_BRANCH branch_route, offer flags: froc-sp Aug 20 21:47:58 u363id562 kamailio[28376]: INFO: <script>: RELAY: hooked to manage_failure, now relaying... Aug 20 21:47:58 u363id562 kamailio[28376]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: new branch [1] to sip:661@testers.com Aug 20 21:47:58 u363id562 kamailio[28376]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: rtpengine_offer_flags = froc-sp and mline = m=audio 49466 RTP/SAVPF 111 103 104 0 8 106 105 13 126 Aug 20 21:47:58 u363id562 kamailio[28376]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: rtpengine_offer with froc-sp Aug 20 21:47:58 u363id562 kamailio[28379]: ALERT: <script>: UA_FAILURE: SAVPF found, setting flags using RTP/AVP in offer and RTP/SAVPF in answer Aug 20 21:47:58 u363id562 kamailio[28379]: INFO: <script>: UA_FAILURE: hooked to RTPPROXY_REPLY reply_route and MANAGE_RTPENGINE_BRANCH branch_route, offer flags: froc-sp Aug 20 21:47:58 u363id562 kamailio[28379]: INFO: <script>: RELAY: hooked to manage_failure, now relaying... Aug 20 21:47:58 u363id562 kamailio[28379]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: new branch [2] to sip:661@testers.com Aug 20 21:47:58 u363id562 kamailio[28379]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: rtpengine_offer_flags = froc-sp and mline = m=audio 49466 RTP/SAVPF 111 103 104 0 8 106 105 13 126 Aug 20 21:47:58 u363id562 kamailio[28379]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: rtpengine_offer with froc-sp ... and so on And this is what's happening in syslog between catching a 488, the rtpengine_offer call and the next 488: Here 1.1.1.1 is the public ip of my Kamailio machine and 2.2.2.2 is the ip behind which my clients reside. I haven't been able to spot the problem, maybe You will. Aug 20 22:01:08 u363id562 kamailio[28610]: ALERT: <script>: UA_FAILURE: SAVPF found, setting flags using RTP/AVP in offer and RTP/SAVPF in answer Aug 20 22:01:08 u363id562 kamailio[28610]: INFO: <script>: UA_FAILURE: hooked to RTPPROXY_REPLY reply_route and MANAGE_RTPENGINE_BRANCH branch_route, offer flags: froc-sp Aug 20 22:01:08 u363id562 kamailio[28610]: INFO: <script>: RELAY: hooked to manage_failure, now relaying... Aug 20 22:01:08 u363id562 kamailio[28610]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: new branch [1] to sip:661@testers.com Aug 20 22:01:08 u363id562 kamailio[28610]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: rtpengine_offer_flags = froc-sp and mline = m=audio 55155 RTP/SAVPF 111 103 104 0 8 106 105 13 126 Aug 20 22:01:08 u363id562 kamailio[28610]: INFO: <script>: MANAGE_RTPENGINE_BRANCH: rtpengine_offer with froc-sp Aug 20 22:01:08 u363id562 rtpengine[32233]: Got valid command from 127.0.0.1:57017: offer - { "sdp": "v=0#015#012o=- 3706977575786663946 2 IN IP4 127.0.0.1#015#012s=-#015#012t=0 0#015#012a=group:BUNDLE audio#015#012a=msid-semantic: WMS C4FrYLUUCeWV8DP6OQlzG3XOBCZrnmVlTWuz#015#012m=audio 55155 RTP/SAVPF 111 103 104 0 8 106 105 13 126#015#012c=IN IP4 2.2.2.2#015#012a=rtcp:55155 IN IP4 2.2.2.2#015#012a=candidate:2999745851 1 udp 2122260223 192.168.56.1 55154 typ host generation 0#015#012a=candidate:2999745851 2 udp 2122260223 192.168.56.1 55154 typ host generation 0#015#012a=candidate:3350409123 ... Aug 20 22:01:08 u363id562 rtpengine[32233]: ... 1 udp 2122194687 192.168.0.101 55155 typ host generation 0#015#012a=candidate:3350409123 2 udp 2122194687 192.168.0.101 55155 typ host generation 0#015#012a=candidate:4233069003 1 tcp 1518280447 192.168.56.1 0 typ host generation 0#015#012a=candidate:4233069003 2 tcp 1518280447 192.168.56.1 0 typ host generation 0#015#012a=candidate:2301678419 1 tcp 1518214911 192.168.0.101 0 typ host generation 0#015#012a=candidate:2301678419 2 tcp 1518214911 192.168.0.101 0 typ host generation 0#015#012a=candidate:1190865175 1 udp 1685987071 91. ... Aug 20 22:01:08 u363id562 rtpengine[32233]: ... 145.67.22 55155 typ srflx raddr 192.168.0.101 rport 55155 generation 0#015#012a=candidate:1190865175 2 udp 1685987071 2.2.2.2 55155 typ srflx raddr 192.168.0.101 rport 55155 generation 0#015#012a=ice-ufrag:A/jaPavOgPBuvQLE#015#012a=ice-pwd:cDlvtQt87wG8uuOhrEmhg9dX#015#012a=ice-options:google-ice#015#012a=fingerprint:sha-256 CF:30:A7:7F:71:11:D4:5E:B0:E7:E3:F9:D8:C2:F4:60:2A:D0:76:46:F8:3A:97:01:C9:0C:5A:F7:B8:7D:C1:43#015#012a=setup:actpass#015#012a=mid:audio#015#012a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level#015#012a=extmap:3 http: ... Aug 20 22:01:08 u363id562 rtpengine[32233]: ... // www.webrtc.org/experiments/rtp-hdrext/abs-send-time#015#012a=sendrecv#015#0… opus/48000/2#015#012a=fmtp:111 minptime=10#015#012a=rtpmap:103 ISAC/16000#015#012a=rtpmap:104 ISAC/32000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:106 CN/32000#015#012a=rtpmap:105 CN/16000#015#012a=rtpmap:13 CN/8000#015#012a=rtpmap:126 telephone-event/8000#015#012a=maxptime:60#015#012a=ssrc:772277070 cname:BwsjKefqgs/g3RSF#015#012a=ssrc:772277070 msid:C4FrYLUUCeWV8DP6OQlzG3XOBCZrnmVlTWuz b7ec3c91-c3a2-4ede-adbf-ada31cb9504f#015#012a=ssrc:772277070 msla ... Aug 20 22:01:08 u363id562 rtpengine[32233]: ... bel:C4FrYLUUCeWV8DP6OQlzG3XOBCZrnmVlTWuz#015#012a=ssrc:772277070 label:b7ec3c91-c3a2-4ede-adbf-ada31cb9504f#015#012", "ICE": "remove", "flags": [ "force", "trust-address" ], "replace": [ "origin", "session-connection" ], "transport-protocol": "RTP/AVP", "call-id": "ug2htprt2erjsat1e6rc", "received-from": [ "IP4", "2.2.2.2" ], "from-tag": "vf9jdb7362", "command": "offer" } Aug 20 22:01:08 u363id562 rtpengine[32233]: Unknown flag encountered: 'force' Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] Creating new call Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] Returning to SIP proxy: d3:sdp762:v=0#015#012o=- 3706977575786663946 2 IN IP4 1.1.1.1#015#012s=-#015#012t=0 0#015#012a=msid-semantic: WMS C4FrYLUUCeWV8DP6OQlzG3XOBCZrnmVlTWuz#015#012m=audio 10624 RTP/AVP 111 103 104 0 8 106 105 13 126#015#012c=IN IP4 1.1.1.1#015#012a=rtpmap:111 opus/48000/2#015#012a=fmtp:111 minptime=10#015#012a=rtpmap:103 ISAC/16000#015#012a=rtpmap:104 ISAC/32000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:106 CN/32000#015#012a=rtpmap:105 CN/16000#015#012a=rtpmap:13 CN/8000#015#012a=rtpmap:126 telephone-event/8000#015#012a=maxptime:60#015#012a=ss ... Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] ... rc:772277070 cname:BwsjKefqgs/g3RSF#015#012a=ssrc:772277070 msid:C4FrYLUUCeWV8DP6OQlzG3XOBCZrnmVlTWuz b7ec3c91-c3a2-4ede-adbf-ada31cb9504f#015#012a=ssrc:772277070 mslabel:C4FrYLUUCeWV8DP6OQlzG3XOBCZrnmVlTWuz#015#012a=ssrc:772277070 label:b7ec3c91-c3a2-4ede-adbf-ada31cb9504f#015#012a=sendrecv#015#012a=rtcp:10625#015#012a=rtcp-mux#015#0126:result2:oke Aug 20 22:01:08 u363id562 rtpengine[32233]: Got valid command from 127.0.0.1:49781: delete - { "call-id": "ug2htprt2erjsat1e6rc", "received-from": [ "IP4", "2.2.2.2" ], "from-tag": "vf9jdb7362", "command": "delete" } Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] Deleting full call Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] Final packet stats: Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] --- Tag '', created 0:00 ago, in dialogue with '(none)' Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] ------ Media #1, port 10626 <> 2.2.2.2:55155, 0 p, 0 b, 0 e Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] --- Tag 'vf9jdb7362', created 0:00 ago, in dialogue with '' Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] ------ Media #1, port 10624 <> [::]:0 , 0 p, 0 b, 0 e Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] Returning to SIP proxy: d7:createdi1408557668e11:last signali1408557668e4:tagsd10:vf9jdb7362d3:tag10:vf9jdb73627:createdi1408557668e16:in dialogue with0:6:mediasld5:indexi1e4:type5:audio8:protocol7:RTP/AVP7:streamsld10:local porti10624e8:endpointd6:family4:IPv67:address2:::4:porti0ee19:advertised endpointd6:family4:IPv67:address2:::4:porti0ee11:last packeti1408557668e5:flagsl3:RTP4:RTCPe5:statsd7:packetsi0e5:bytesi0e6:errorsi0eeed10:local porti10625e8:endpointd6:family4:IPv67:address2:::4:porti0 ... Aug 20 22:01:08 u363id562 rtpengine[32233]: [ug2htprt2erjsat1e6rc] ... ee19:advertised endpointd6:family4:IPv67:address2:::4:porti0ee11:last packeti1408557668e5:flagsl4:RTCP13:fallback RTCPe5:statsd7:packetsi0e5:bytesi0e6:errorsi0eeee5:flagsl8:rtcp-muxeeeee6:totalsd3:RTPd7:packetsi0e5:bytesi0e6:errorsi0ee4:RTCPd7:packetsi0e5:bytesi0e6:errorsi0eee6:result2:oke Aug 20 22:01:08 u363id562 kamailio[28613]: ALERT: <script>: UA_FAILURE: SAVPF found, setting flags using RTP/AVP in offer and RTP/SAVPF in answer Can you guys spot the problem from these logs? I've been stuck with this for a while, I must be doing something wrong but don't know what... cheers, Olli 2014-08-19 11:13 GMT+03:00 Olli Heiskanen <ohjelmistoarkkitehti(a)gmail.com>: > Hi, > > A little follow-up on this: > > The problem only happens when I call rtpengine_offer() inside a > branch_route. If I call rtpengine_offer() in the failure_route (after 488) > this conversion error does not happen, but then I get the double sdp issue > indicated here: > http://lists.sip-router.org/pipermail/sr-dev/2014-July/024507.html > > The same problem occurs with Kamailio 4.1.5 and rtpproxy-ng. My current > setup uses Kamailio 4.2 (devel) and rtpengine. > > If anyone has a way around this, I'd appreciate very much to hear it! This > prevents any calls from being setup. > > cheers, > Olli > > > > 2014-08-15 18:40 GMT+03:00 Olli Heiskanen <ohjelmistoarkkitehti(a)gmail.com> > : > > Hello, >> >> As outcome to my earlier sdp/rtp challenges I've upgraded my Asterisk >> version to 11.11.0 and still use a realtime integration with Kamailio. Now >> I face a somewhat different problem. With my setup I also changed from >> jssip client to a sip.js client in my websocket implementation. I cloned >> the latest rtpengine from git today. >> >> I had to revert my Asterisk settings a bit, Asterisk was taking over with >> sdp handling, I don't know if this is relevant but that's why I got calls >> seemingly working before. >> >> When getting the 488 Not Acceptable, I arm a branch route and call >> rtpengine_offer there. When trying to call rtpengine_offer, I get the >> following log: >> (first I print the rtpengine_offer_flags to make sure what is passed to >> the function. >> >> Aug 15 15:04:16 u363id562 kamailio[32178]: INFO: <script>: >> MANAGE_RTPENGINE_BRANCH: rtpengine_offer_flags = rtcp-mux-demux >> trust-address replace-origin replace-session-connection ICE=remove RTP/AVP >> Aug 15 15:04:16 u363id562 kamailio[32178]: WARNING: <core> >> [rvalue.c:1016]: rval_get_int(): automatic string to int conversion for >> "rtcp-mux-demux trust-address replace-origin replace-session-connection >> ICE=remove RTP/AVP" failed >> Aug 15 15:04:16 u363id562 kamailio[32178]: WARNING: <core> >> [rvalue.c:1920]: rval_expr_eval_int(): rval expression conversion to int >> failed (1128,32-1128,32) >> Aug 15 15:04:16 u363id562 rtpengine[32159]: Got valid command from >> 127.0.0.1:44292: delete - { "call-id": "k7bft3u75p5e42ib039r", >> "received-from": [ "IP4", "client_public_address" ], "from-tag": >> "74dovi97bi", "command": "delete" } >> Aug 15 15:04:16 u363id562 rtpengine[32159]: [k7bft3u75p5e42ib039r] >> Call-ID to delete not found >> Aug 15 15:04:16 u363id562 rtpengine[32159]: Returning to SIP proxy: >> d7:warning38:Call-ID not found or tags didn't match6:result2:oke >> >> After this I see another 488 and the loop swirls on until Kamailio runs >> out of forking capacity. Can You guys explain why is this happening? >> >> I set the variable like this: >> $avp(rtpengine_offer_flags) = "rtcp-mux-demux trust-address >> replace-origin replace-session-connection ICE=remove RTP/AVP"; >> >> cheers, >> Olli >> > >

1 0

← 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 August 2014