[OpenSIPS-Devel] New MediaProxy release 2.5.0
Hello, There is a new release of MediaProxy available with compatibility for newer iptables versions, latest Python dependencies and newer kernels. MediaProxy is a media relay for RTP/RTCP and UDP streams that works in tandem with OpenSIPS to provide NAT traversal capability for media streams from SIP user agents located behind NAT. MediaProxy supports ICE negotiation by behaving like a TURN relay candidate and the policy can be controlled from OpenSIPS configuration. The software is now ready packaged for the latest Debian and Ubuntu Linux distributions. mediaproxy (2.5.0) unstable; urgency=low * Adapted to changes in python-application * Fixed several pyflakes warnings * Fixed encoding media information * Adapted to changes in libipt and netfilter APIs * Bumped Debian standards version to 3.9.2 * Reworked Debian packaging * Added more user agent images taken from CDRTool * Added specific iptables version dependency Installation and upgrade instructions area available here: http://mediaproxy-ng.org/wiki/InstallationGuide Kind regards, Adrian Georgescu ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8015] trunk/modules/b2b_entities
Revision: 8015 http://opensips.svn.sourceforge.net/opensips/?rev=8015view=rev Author: anca_vamanu Date: 2011-06-17 09:41:27 + (Fri, 17 Jun 2011) Log Message: --- - fix: made WRITE_THROUGH db mode more accurate - update also when sending requests/replies out (reported by Ovidiu Sas in bug #3317402) Modified Paths: -- trunk/modules/b2b_entities/b2b_entities.c trunk/modules/b2b_entities/b2be_db.c trunk/modules/b2b_entities/dlg.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3317402 ] b2b calls out of sync after server restart
Bugs item #3317402, was opened at 2011-06-16 19:53 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3317402group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Nobody/Anonymous (nobody) Summary: b2b calls out of sync after server restart Initial Comment: If a server is restarted while a b2b call is active, the b2b call is restored from the db. The issue is that subsequent in-dialog requests are having the Cseq reseted and this is causing rejections from the far end. How to reproduce: - initiate a b2b call, - answer the b2b call, - send a reINVITE, - restart opensips, - send a reINVITE from one of the participants and check the CSeq number It seems that the CSeq fields are not updated into the db. Regards, Ovidiu Sas -- Comment By: Anca Vamanu (anca_vamanu) Date: 2011-06-17 13:42 Message: Hello Ovidiu, The first thing that I noticed in your sql traces is that only one dialog is updated. The thing is that in the way the WRITE_THROUGH mode was working until today, the updates in db for a dialog were done only when a request or reply was received. It was assumed that replies sent out don't change state and that requests sent out will eventually receive a reply and the state will be save then. However this is indeed not that accurate. This is the reason why today I committed a modification. I have also called the update function where requests or replies are sent out, with an efficiency check to make sure that you don't update in the same processing sequence the same dialog twice. If you can please take the new code and test. However, apart from this observation the traces don't really show what you suspected. First, to make it clear - the reInvite is received in this dialog: callid:: c3e141c7-a61270ac@192.168.2.93 ? For this dialog the cseq doesn't changes neither in memory. And I have now checked, the b2b doesn't update the caller cseq never. Because it doesn't actually need that cseq as no cseq validation is preformed. I wrote a few lines to make a cseq check and to update the cseq in prescript_f function, but then realized that the cseq must be updated also when PRACK is received ( and now for PRACK the dialog is not even searched - 200OK is sent directly). And since I don't have the time and means to test now, I have not completed the patch. If you are willing to work on the PRACK part I can give you the partial patch that I have now. Apart from this, you said in the initial comment that the in-dialog requests after restart are rejected by far end - so it actually seems there is a problem with updating the local_cseq. Please try the patch that I committed today that updates the dialog more often and say if this problem appears still. Regards, Anca -- Comment By: Ovidiu Sas (osas) Date: 2011-06-17 00:59 Message: Here's what we have in memory compared with what is saved on db. call answered (in conversation $ opensipsctl fifo b2be_list dlg:: 426 param=561.0 state=5 last_invite_cseq=101 last_method=0 last_reply_code=200 db_flag=2 ruri:: sip:248@192.168.2.2:5080 callid:: c3e141c7-a61270ac@192.168.2.93 from:: uri=sip:0026998D2646-1@192.168.2.2 tag=df62070b4614cc38o0 to:: Ovidiu Sas uri=sip:248@192.168.2.2 tag=bk2bk.82.426 cseq:: caller=101 callee=1 contact:: caller=sip:0026998D2646-1@192.168.2.93:5060 callee=sip:192.168.2.2:5080 send_sock:: 192.168.2.2 dlg:: 5416268 param=561.0 state=5 last_invite_cseq=104 last_method=4 db_flag=2 callid:: bk2bk.49.5416268 from:: Ovidiu Sas PBX uri=sip:osas@192.168.2.20 tag=85264a8f8cfcee6787f3406feb27d2b7 to:: uri=sip:248@192.168.2.20 tag=as07119f07 cseq:: caller=104 callee=1 contact:: caller=sip:192.168.2.2:5080 callee=sip:248@192.168.2.20:5060 send_sock:: 192.168.2.2 leg:: 0 tag=as07119f07 cseq=103 contact=sip:248@192.168.2.20:5060 reINVITE (hold) received 110616 18:21:24 64478 Query update b2b_logic set sstate=-3,next_sstate=0,lifetime=1308298856,e1_type=0,e1_sid='',e1_to='sip:248@192.168.2.20',e1_from='sip:osas@192.168.2.20',e1_key='bk2bk.82.426',e2_type=1,e2_sid='',e2_to='sip:248@192.168.2.20',e2_from='sip:osas@192.168.2.20',e2_key='bk2bk.49.5416268' where si_key='561.0' 64478 Query update b2b_entities set state=6,cseq0=101,cseq1=1,lm=0,lrc=200,lic=101,contact0='sip:0026998D2646-1@192.168.2.93:5060',contact1='sip:192.168.2.2:5080' where type=0 AND tag0='df62070b4614cc38o0' AND tag1='bk2bk.82.426' AND
[OpenSIPS-Devel] [ opensips-Bugs-3317402 ] b2b calls out of sync after server restart
Bugs item #3317402, was opened at 2011-06-16 12:53 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3317402group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Nobody/Anonymous (nobody) Summary: b2b calls out of sync after server restart Initial Comment: If a server is restarted while a b2b call is active, the b2b call is restored from the db. The issue is that subsequent in-dialog requests are having the Cseq reseted and this is causing rejections from the far end. How to reproduce: - initiate a b2b call, - answer the b2b call, - send a reINVITE, - restart opensips, - send a reINVITE from one of the participants and check the CSeq number It seems that the CSeq fields are not updated into the db. Regards, Ovidiu Sas -- Comment By: Ovidiu Sas (osas) Date: 2011-06-17 09:13 Message: Hello Anca, I noticed that only one dialog was updated in the trace (it is true that I did not mentioned this in the latest post) and you confirmed that. The fix is working ok. I don't know if we really need to do something about PRACK, because the PRACK makes sense only during alerting, and in alerting state, calls don't survive a restart (the transaction is lost). If you think that is worth doing something for PRACK, I can try to validate your patch. Please send me the patch privately and I will try to test it for you and we will continue the PRACK discussion on the mailing list. Thanks, Ovidiu -- Comment By: Anca Vamanu (anca_vamanu) Date: 2011-06-17 06:42 Message: Hello Ovidiu, The first thing that I noticed in your sql traces is that only one dialog is updated. The thing is that in the way the WRITE_THROUGH mode was working until today, the updates in db for a dialog were done only when a request or reply was received. It was assumed that replies sent out don't change state and that requests sent out will eventually receive a reply and the state will be save then. However this is indeed not that accurate. This is the reason why today I committed a modification. I have also called the update function where requests or replies are sent out, with an efficiency check to make sure that you don't update in the same processing sequence the same dialog twice. If you can please take the new code and test. However, apart from this observation the traces don't really show what you suspected. First, to make it clear - the reInvite is received in this dialog: callid:: c3e141c7-a61270ac@192.168.2.93 ? For this dialog the cseq doesn't changes neither in memory. And I have now checked, the b2b doesn't update the caller cseq never. Because it doesn't actually need that cseq as no cseq validation is preformed. I wrote a few lines to make a cseq check and to update the cseq in prescript_f function, but then realized that the cseq must be updated also when PRACK is received ( and now for PRACK the dialog is not even searched - 200OK is sent directly). And since I don't have the time and means to test now, I have not completed the patch. If you are willing to work on the PRACK part I can give you the partial patch that I have now. Apart from this, you said in the initial comment that the in-dialog requests after restart are rejected by far end - so it actually seems there is a problem with updating the local_cseq. Please try the patch that I committed today that updates the dialog more often and say if this problem appears still. Regards, Anca -- Comment By: Ovidiu Sas (osas) Date: 2011-06-16 17:59 Message: Here's what we have in memory compared with what is saved on db. call answered (in conversation $ opensipsctl fifo b2be_list dlg:: 426 param=561.0 state=5 last_invite_cseq=101 last_method=0 last_reply_code=200 db_flag=2 ruri:: sip:248@192.168.2.2:5080 callid:: c3e141c7-a61270ac@192.168.2.93 from:: uri=sip:0026998D2646-1@192.168.2.2 tag=df62070b4614cc38o0 to:: Ovidiu Sas uri=sip:248@192.168.2.2 tag=bk2bk.82.426 cseq:: caller=101 callee=1 contact:: caller=sip:0026998D2646-1@192.168.2.93:5060 callee=sip:192.168.2.2:5080 send_sock:: 192.168.2.2 dlg:: 5416268 param=561.0 state=5 last_invite_cseq=104 last_method=4 db_flag=2 callid:: bk2bk.49.5416268 from:: Ovidiu Sas PBX uri=sip:osas@192.168.2.20 tag=85264a8f8cfcee6787f3406feb27d2b7 to:: uri=sip:248@192.168.2.20 tag=as07119f07 cseq:: caller=104 callee=1 contact:: caller=sip:192.168.2.2:5080
Re: [OpenSIPS-Devel] [OpenSIPS-Users] New MediaProxy release 2.5.0
On Jun 17, 2011, at 11:21 AM, Adrian Georgescu wrote: Hello, There is a new release of MediaProxy available with compatibility for newer iptables versions, latest Python dependencies and newer kernels. MediaProxy is a media relay for RTP/RTCP and UDP streams that works in tandem with OpenSIPS to provide NAT traversal capability for media streams from SIP user agents located behind NAT. MediaProxy supports ICE negotiation by behaving like a TURN relay candidate and the policy can be controlled from OpenSIPS configuration. The software is now ready packaged for the latest Debian and Ubuntu Linux distributions. mediaproxy (2.5.0) unstable; urgency=low * Adapted to changes in python-application * Fixed several pyflakes warnings * Fixed encoding media information * Adapted to changes in libipt and netfilter APIs * Bumped Debian standards version to 3.9.2 * Reworked Debian packaging * Added more user agent images taken from CDRTool * Added specific iptables version dependency Installation and upgrade instructions area available here: http://mediaproxy-ng.org/wiki/InstallationGuide A note for CentOS users: As the installation guide now mentions, iptables = 1.4.3 is required now. CentOS 5.6 has iptables version 1.3.5 and we could not maintain backwards compatibility any longer. Thus, CentOS 5.x users should stay on MediaProxy 2.4.4. I hope CentOS 6 provides up-to-date enough versions for Python and iptables so that its easy to build MediaProxy there. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
