Re: [OpenSIPS-Users] Preparing new major release 1.7.0 - UPDATE
Hi, coming back with the timing for the new 1.7 major release: *30th of June *- SVN freeze - at the time, all new things and known bugs are to be committed into SVN and tested ; at this point the testing phase will start. *12th of July* - release date - the 1.7 beta will be officially release. The list of changes for 1.7 will be fully available starting with 30th of June, when SVN will be freeze. Best regards, Bogdan On 06/08/2011 08:05 PM, Bogdan-Andrei Iancu wrote: Hi all, The plan is to put on the roll the preparing of a new major release for opensips, to incorporate all the new things that were added : - RTP timeout notification in nathlper (via rtpproxy) with dialog termination - better error handling for RTPproxy failover - dialog enhancement (dialog fixing, in-dialog pinging) - Event interface (datagram support) - registrant module - B2B module - internal API and DB persistence for restarts. - presence enhancement We still have on the roll some work (to be finished in the next week) like: - avp auto aliasing (drop the i: and s: naming) - multi-insert in DB ops (for acc, siptrace, location). The new release will be generated from trunk and a new branch will be created for it. In the next days we will compile a detailed and complete list of new things in opensips 1.7. We also want to change a bit the release policy: after first level of testing, a beta release (release candidate) will be made public ; this code is intended to be used and tested "as final version" - eventual bugs will be fixed, opening the way for the final stable release. This is to improve the quality and stability of the stable release. I will be glad to get feedback on : - what code/functionality is missing and should be in 1.7 - the new release policy. Best regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and "know-how" ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] 30x redirect for register
Hi Dani, Theoretically yes - I mean according to RFC 3261 is perfectly make sense. On the other hand, some SIP UA implementations do not properly handle a redirect for REGISTER.Probably you need to explicitly test with the UACs you want use. Regards, Bogdan On 06/20/2011 07:08 PM, Dani Popa wrote: Hi all, It is viable solution to use 30(1|2|5) redirect for REGISTER sip messages ? Thanks, Dani ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS solutions and "know-how" ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 404 Contact not found
Dear All! opensips: opensips_trunk rev 7915 I have strange problem. When I try to delete contact fifo command ul_show_contact can't find AOR but fifo comman ul_show contact show it. # opensipsctl fifo ul_show_contact location u...@domain.com Contact:: ;q=0;expires=109;flags=0x0;cflags=0x0;socket=;methods=0x143F;user_agent= # opensipsctl fifo ul_rm_contact location u...@domain.com sip:user@UAC:5060 404 Contact not found Thanks in advance! ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] 30x redirect for register
Hi, Thanks Bogdan for confirmation, for list acknowledge, till now, Linksys support 30x redirect for register(an also for invite) and grandstream not for REGISTER(but support for INVITE) . Also x-lite,bria,eyebeam and jitsi don't support 30x for REGISTER(i didn't test for INVITE and other sip methods). If someone have other results, please let me know. Dani On 06/21/11 12:26, Bogdan-Andrei Iancu wrote: Hi Dani, Theoretically yes - I mean according to RFC 3261 is perfectly make sense. On the other hand, some SIP UA implementations do not properly handle a redirect for REGISTER.Probably you need to explicitly test with the UACs you want use. Regards, Bogdan On 06/20/2011 07:08 PM, Dani Popa wrote: Hi all, It is viable solution to use 30(1|2|5) redirect for REGISTER sip messages ? Thanks, Dani ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool billing of internal calls
Anyone? >From FreeRadius log: *Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 408 Sip-Method = Invite Event-Timestamp = "Jun 14 2011 16:02:47 CEST" Sip-From-Tag = "as16538a8e" Acct-Session-Id = "**18375a0e058480f5626c94293975f7cf@x*<18375a0e058480f5626c94293975f7cf@x> *" User-Name = "**a@x* *" Calling-Station-Id = "sip:a@x" Called-Station-Id = "sip:b@y" Sip-Translated-Request-URI = "sip:b@ip" Source-IP = "ip" Source-Port = "5060" Billing-Party = "sip:a@x" Canonical-URI = "sip:b@y" User-Agent = "Asterisk PBX" Contact = "" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "89f0c9014ba0a2f9" Timestamp = 1308060167 Request-Authenticator = Verified* Best regards, Tony Tyler 2011/6/14 Tony Tyler > Hi, > > We have setup CDRTool version 8.0.15 with an Asterisk multitenant PBX. > > We want to be able to log and bill the internal calls in CDRTool. > All the calls are sent from Asterisk to OpenSIPS and the call is sent back > to the same Asterisk on the same IP-address. > > If it´s a external call, there is no problem. The problem occurs when the > called number is a local customer, then it can´t log or bill the call in > CDRTool. > > From FreeRadius log: > > Acct-Status-Type = Failed > Service-Type = Sip-Session > Sip-Response-Code = 408 > Sip-Method = Invite > Event-Timestamp = "Jun 14 2011 16:02:47 CEST" > Sip-From-Tag = "as16538a8e" > Acct-Session-Id = "18375a0e058480f5626c94293975f7cf@x" > User-Name = "a@x" > Calling-Station-Id = "sip:a@x" > Called-Station-Id = "sip:b@y" > Sip-Translated-Request-URI = "sip:b@ip" > Source-IP = "ip" > Source-Port = "5060" > Billing-Party = "sip:a@x" > Canonical-URI = "sip:b@y" > User-Agent = "Asterisk PBX" > Contact = "" > NAS-Port = 5060 > Acct-Delay-Time = 0 > NAS-IP-Address = 127.0.0.1 > Acct-Unique-Session-Id = "89f0c9014ba0a2f9" > Timestamp = 1308060167 > Request-Authenticator = Verified > > > Best regards, > Tony Tyler > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool billing of internal calls
Look at my last post here http://opensips-open-sip-server.1449251.n2.nabble.com/CDRTool-CDR-Flow-record-td6432731.html#a6449882 I think it's just a matter of what you have configured for "E164_class" => "intAccessCode" => "natAccessCode" => And also edit the can_uri. So if your can_uri for your internal calls is set up the same as outbound calls it should calculate the calls. Hope that answers the issue you are having. On Jun 21, 2011 7:29am, Tony Tyler wrote: Anyone? From FreeRadius log: Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 408 Sip-Method = Invite Event-Timestamp = "Jun 14 2011 16:02:47 CEST" Sip-From-Tag = "as16538a8e" Acct-Session-Id = "18375a0e058480f5626c94293975f7cf@x" User-Name = "a@x" Calling-Station-Id = "sip:a@x" Called-Station-Id = "sip:b@y" Sip-Translated-Request-URI = "sip:b@ip" Source-IP = "ip" Source-Port = "5060" Billing-Party = "sip:a@x" Canonical-URI = "sip:b@y" User-Agent = "Asterisk PBX" Contact = "" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "89f0c9014ba0a2f9" Timestamp = 1308060167 Request-Authenticator = Verified Best regards, Tony Tyler 2011/6/14 Tony Tyler tonytyler2...@gmail.com> Hi, We have setup CDRTool version 8.0.15 with an Asterisk multitenant PBX. We want to be able to log and bill the internal calls in CDRTool. All the calls are sent from Asterisk to OpenSIPS and the call is sent back to the same Asterisk on the same IP-address. If it´sa external call, there is no problem. The problem occurs when the called number is a local customer, then it can´t log or bill the call in CDRTool. From FreeRadius log: Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 408 Sip-Method = Invite Event-Timestamp = "Jun 14 2011 16:02:47 CEST" Sip-From-Tag = "as16538a8e" Acct-Session-Id = "18375a0e058480f5626c94293975f7cf@x" User-Name = "a@x" Calling-Station-Id = "sip:a@x" Called-Station-Id = "sip:b@y" Sip-Translated-Request-URI = "sip:b@ip" Source-IP = "ip" Source-Port = "5060" Billing-Party = "sip:a@x" Canonical-URI = "sip:b@y" User-Agent = "Asterisk PBX" Contact = "" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "89f0c9014ba0a2f9" Timestamp = 1308060167 Request-Authenticator = Verified Best regards, Tony Tyler ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] rtpproxy stream2uac using incorrect codec
Hi, I am triggering rtpproxy_answer and stream2uac on a 183 early media message which has codec 0 pcmu as the returned codec. However it seems to be only playing codec 8 pcma which is the first on the list in the initial invite. Should the answer method update the codec ready for the stream? Many thanks Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] rtpproxy stream2uac using incorrect codec
Hi, Doing some further testing looking at debug on rtpproxy I see the initial offer giving Uc8,0,101 as the codec list, I then see the answer giving Lc0,101 as the codec list but when I see the P stream message it says it is playing the relevant prompt but using codec 8 surely it should be using the negotiated codec in the answer message? Any help would be appreciated. Regards Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Single call generates many Invites to callee
I noticed an issue on my OpenSIPS B2BUA server where Heartbeat gave me the following errors Jun 21 11:50:46 proxy01 logd: [1086]: WARN: G_CH_check_int: working on IPC channel took 160 ms (> 100 ms) Jun 21 11:50:48 proxy01 logd: [1084]: WARN: G_CH_check_int: working on IPC channel took 770 ms (> 100 ms) Jun 21 11:50:48 proxy01 logd: [1084]: WARN: G_CH_check_int: working on IPC channel took 370 ms (> 100 ms) Jun 21 11:50:48 proxy01 logd: [1086]: WARN: G_CH_prepare_int: working on IPC channel took 390 ms (> 100 ms) Jun 21 11:50:48 proxy01 logd: [1084]: WARN: G_CH_check_int: working on IPC channel took 140 ms (> 100 ms) Jun 21 11:50:48 proxy01 logd: [1084]: WARN: G_CH_prepare_int: working on IPC channel took 130 ms (> 100 ms) Jun 21 11:50:48 proxy01 crmd: [21371]: WARN: G_CH_check_int: working on IPC channel took 290 ms (> 100 ms) Jun 21 11:50:48 proxy01 ccm: [21366]: WARN: G_CH_check_int: working on IPC channel took 540 ms (> 100 ms) Jun 21 11:50:48 proxy01 lrmd: [21368]: WARN: G_CH_check_int: working on IPC channel took 650 ms (> 100 ms) Jun 21 11:50:48 proxy01 cib: [21367]: WARN: G_CH_check_int: working on Heartbeat API channel took 1630 ms (> 100 ms) Jun 21 11:50:48 proxy01 crmd: [21371]: WARN: G_CH_check_int: working on IPC channel took 350 ms (> 100 ms) Jun 21 11:50:48 proxy01 crmd: [21371]: WARN: G_CH_check_int: working on IPC channel took 220 ms (> 100 ms) Jun 21 11:50:49 proxy01 cib: [21367]: WARN: G_CH_check_int: working on IPC channel took 220 ms (> 100 ms) Jun 21 11:50:50 proxy01 cib: [21367]: WARN: G_CH_check_int: working on IPC channel took 170 ms (> 100 ms) the errors eventually went away without me having to restart anything but because of Heartbeat it was causing my SIP Trunk provider to send multiple INVITES when a ITSP Caller was calling one of my users because the OpenSIPS B2BUA server took so long to reply to the INVITEs. Because a ton of INVITES were sent the OpenSIPS B2BUA sends a ton of INVITES to the OpenSIPS Proxy and then the proxy sends a ton of calls to the UA client. So the client gets bombed with a ton of calls. Is there any way from an OpenSIPS perspective to protect myself from from this? I currently can set each user to only have a certain amount of call channels, but this would just cause the extra channels to get loaded up. I was hoping there was a way to notice multiple INVITES with the same CALL-ID coming in and only relay the single INVITE on to the Proxy. Anyone else run into this? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
