[OpenSIPS-Devel] SF.net SVN: opensips:[6624] branches/1.6/modules/dispatcher/dispatch.c
Revision: 6624 http://opensips.svn.sourceforge.net/opensips/?rev=6624&view=rev Author: bogdan_iancu Date: 2010-02-25 07:38:41 + (Thu, 25 Feb 2010) Log Message: --- backport from trunk (rev #6623): - removed bogus message -> module allow starting with no destinations, so why reporting as error on timer :P Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6623&view=rev Modified Paths: -- branches/1.6/modules/dispatcher/dispatch.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] SF.net SVN: opensips:[6623] trunk/modules/dispatcher/dispatch.c
Revision: 6623 http://opensips.svn.sourceforge.net/opensips/?rev=6623&view=rev Author: bogdan_iancu Date: 2010-02-25 07:37:28 + (Thu, 25 Feb 2010) Log Message: --- - removed bogus message -> module allow starting with no destinations, so why reporting as error on timer :P Modified Paths: -- trunk/modules/dispatcher/dispatch.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
Re: [OpenSIPS-Devel] [ opensips-Bugs-2958254 ] Comma separated headers are not parsed by $hdr
I'm kind of under the impression that $(hdr(name)[N]) will return the body of
the Nth instance of the header. At least that's what the documentation states.
3.82 SIP Headers
$(hdr(name)[N]) - represents the body of the N-th header identified by 'name'.
If [N] is omitted then the body of the first header is printed. The first
header is got when N=0, for the second N=1, a.s.o. To print the last header of
that type, use -1, no other negative values are supported now. No white spaces
are allowed inside the specifier (before }, before or after {, [, ] symbols).
When N='*', all headers of that type are printed.
On Feb 24, 2010, at 5:42 PM, SourceForge.net wrote:
> Bugs item #2958254, was opened at 2010-02-24 17:42
> Message generated for change (Tracker Item Submitted) made by rshpount
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2958254&group_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: core
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Roman Shpount (rshpount)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Comma separated headers are not parsed by $hdr
>
> Initial Comment:
> When comma separated headers, such as "Allow: INVITE, ACK, CANCEL, BYE" are
> accessed using $hdr script variable, they are presented as a single header.
> In other words, $hdr(Allow) returns "INVITE, ACK, CANCEL, BYE" and
> $(hdr(Allow)[1]) returns . Expected behavior is to return "INVITE" and
> "ACK" respectively.
>
> To reproduce, see the output of
>
> xlog("L_INFO", "TRACE:TEST: $hdr(Allow)\n");
> xlog("L_INFO", "TRACE:TEST: $(hdr(Allow)[1])\n");
>
> while processing almost any Register message.
>
>
> --
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2958254&group_id=232389
>
> ___
> Devel mailing list
> Devel@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2958257 ] hdr script var does not support [0] index
Bugs item #2958257, was opened at 2010-02-24 17:47
Message generated for change (Tracker Item Submitted) made by rshpount
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2958257&group_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: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Shpount (rshpount)
Assigned to: Nobody/Anonymous (nobody)
Summary: hdr script var does not support [0] index
Initial Comment:
When trying to access first element of hdr collection using [0] index is
returned. Furthermore, "DBG:core:pv_get_hdr: index out of range" message is
generated in the log.
To reproduce see output of
xlog("L_INFO", "TRACE:TEST: $hdr(Allow)\n");
xlog("L_INFO", "TRACE:TEST: $(hdr(Allow)[0])\n");
while processing any Register message with Allow header. Both log messages are
expected to produce the same result. In reality, first log message returns
complete Allow header and the second message returns .
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2958257&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2958254 ] Comma separated headers are not parsed by $hdr
Bugs item #2958254, was opened at 2010-02-24 17:42
Message generated for change (Tracker Item Submitted) made by rshpount
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2958254&group_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: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Shpount (rshpount)
Assigned to: Nobody/Anonymous (nobody)
Summary: Comma separated headers are not parsed by $hdr
Initial Comment:
When comma separated headers, such as "Allow: INVITE, ACK, CANCEL, BYE" are
accessed using $hdr script variable, they are presented as a single header. In
other words, $hdr(Allow) returns "INVITE, ACK, CANCEL, BYE" and
$(hdr(Allow)[1]) returns . Expected behavior is to return "INVITE" and
"ACK" respectively.
To reproduce, see the output of
xlog("L_INFO", "TRACE:TEST: $hdr(Allow)\n");
xlog("L_INFO", "TRACE:TEST: $(hdr(Allow)[1])\n");
while processing almost any Register message.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2958254&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] New MediaProxy release 2.4.0 with support for ICE negotiation
We are aware of this and will address the OpenXCAP packaging issue in the next release. Adrian On Feb 24, 2010, at 5:01 AM, Juha Heinanen wrote: > Juha Heinanen writes: > >> adrian, >> >> the list does not include anything about python-application >> 1.2.2 compatibility. does it work with that version or still require >> old version? >> >> -- juha > > sorry about the mixup. the problem was with openxcap, not mediaproxy. > > -- juha > > ___ > Devel mailing list > Devel@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2957313 ] [MediaProxy] Add support for ICE
Patches item #2957313, was opened at 2010-02-23 18:12 Message generated for change (Comment added) made by saghul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2957313&group_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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: saghul (saghul) Assigned to: Dan (dan_pascu) Summary: [MediaProxy] Add support for ICE Initial Comment: Hi, The attached patch adds support for using ICE (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19) in scenarios involving OpenSIPS and MediaProxy. Currently NAT is usually fixed by mangling the SDP in OpenSIPS and directing RTP to a media relay server. This SDP mangling makes ICE not to work, because ICE needs to have a candidate for the IP present in the c line of the SDP, and as the proxy changed it, ICE negotiation breaks. With the attached patch, OpenSIPS will add the necessary candidates to the SDP so that the ICE negotiation doesn't break and we can have p2p audio on LAN environments for example. :) Please consder it for inclusion in some later relase, Kind regards, PS: The design on how the issue has been solved can be seen here: http://mediaproxy.ag-projects.com/wiki/ICE PS2: This patch needs this other patch to be applied previously: https://sourceforge.net/tracker/?func=detail&aid=2949743&group_id=232389&atid=1086412 -- Saúl Ibarra Corretgé AG Projects -- >Comment By: saghul (saghul) Date: 2010-02-24 18:47 Message: Just uploaded a patch for adding the documentation (README and XML) for the new parameters. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2957313&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] new CDRTool release 7.1.0
Changelog: cdrtool (7.1.0) unstable; urgency=low * Added support for ICE negotiation (requires MediaProxy >=2.4.0) You must update Freeradius configuration with sql.conf and reload the stored procedures file radius_accounting.proc in the radius database * Insert/update sql queries in Freeradius sql.conf have been deprecated in favour of the stored procedure * Added EPC2203 user agent The software can be downloaded as a tar archive from: http://download.ag-projects.com/CDRTool/ For those running Debian unstable there is an official public repository. To use it, add these lines in /etc/apt/sources.list # AG Projects software deb http://ag-projects.com/debian unstable main deb-src http://ag-projects.com/debian unstable main Install the AG Projects debian software signing key: wget http://download.ag-projects.com/agp-debian-gpg.key apt-key add agp-debian-gpg.key After that, run: sudo apt-get update sudo apt-get install cdrtool Regards, Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2956739 ] SRV lookup not correct
Bugs item #2956739, was opened at 2010-02-22 13:38 Message generated for change (Comment added) made by byron_clark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2956739&group_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: core Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Clark (byron_clark) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: SRV lookup not correct Initial Comment: When using an SRV record to relay to a destination, OpenSIPS will repeatedly attempt to send the message to the second result in the lookup reply. Here's an example (assume no response is received to the message): - call t_relay() to relay to sip.example.com - OpenSIPS performs SRV lookup for _sip._udp.sip.example.com - DNS responds with sip1.example.com, sip2.example.com, sip3.example.com, sip4.example.com (equal priority) - OpenSIPS performs A lookup for sip1.example.com - OpenSIPS relays the message to sip1.example.com (including retransmits) - OpenSIPS performs A lookulp for sip2.example.com - OpenSIPS relays the message to sip2.example.com (including retransmits) At this point, OpenSIPS should attempt to use sip3.example.com, but instead continues to lookup and then send the message to sip2.example.com until these errors show up in the log: Feb 18 16:36:08 bgw1 opensips[1745]: ERROR:tm:add_uac: maximum number of branches exceeded Feb 18 16:36:08 bgw1 opensips[1745]: ERROR:tm:t_forward_nonack: failure to add branches -- >Comment By: Byron Clark (byron_clark) Date: 2010-02-24 08:33 Message: Log attached. DNS record is SRV _sip._udp.wholesaleorigination.acc.globalipcom.com. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-02-24 02:40 Message: Hi, Could you post the logs (debug=4) for such a scenarios ? it will be easier for me to understand what is going on. Also, if the DNS record is public, maybe we could let me know its name, so that I can try for myself. Regards, Bogdan -- Comment By: Byron Clark (byron_clark) Date: 2010-02-22 13:40 Message: The attached patch (against the 1.6 branch) causes OpenSIPS to correctly walk through all of the SRV responses instead of continuing to use the same entry. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2956739&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] disabling outbound TCP connection for nated UA
Ok, so let say we see (after usrloc lookup) that we have to use tcp (looking at RURI param) and also we can inspect the bflag for nat indication. From this point I see two options: - expose a TCP related function to be called from script to check if there is an opened connection to a certain destination (like RURI) -> if false, drop the call - invent a new flag to instruct the TCP layer not to open a new connection - probably a script flag, as the sip_msg struct is not passed to the transport layer. In this case, the error will be reported by t_relay()...a bit ambiguous .. Regards, Bogdan Emmanuel BUU wrote: > Bogdan-Andrei Iancu a écrit : > >> Hi Emmanuel, >> >> In theory this will be nice and correct, but practically speaking it is >> too difficult to do , as the SIP part needs to be aware of the transport >> layer and vice versa . >> >> > This already the case as the contact that is stored in the USRLOC module > contains a transport indication (that is if the UA is using TCP) > >> Like you need to "know" that a SIP URI points behind a NAT, store the >> info with the RURI and pass it to the transport level when it tries to >> send the message out. >> >> > This can be done by scripting when the REGISTER message is processed and > one could use a registry flag to tag the contact as nated". > >> The 2.0 design will solve this problem as the async model will not be >> affected by the blocking to a natted destination. >> >> > Yes but it will issue TCP connection nevetheless, connections that are > bound to fail. Maybe we should see if there is a way to tell the TM module: > > "try to reuse a TCP connection to this UA and if no such connection is > available, report an error". > >> Regards, >> Bogdan >> >> Emmanuel BUU wrote: >> >> >>> Hello, >>> >>> Is there a way in the TM module to prevent opensips to open an outbound >>> TCP connection in case the destination is nated? >>> >>> Emmanuel >>> >>> ___ >>> Devel mailing list >>> Devel@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel >>> >>> >>> >>> >> >> > > > ___ > Devel mailing list > Devel@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] New contribution, uac_auth() in request route
Hi Michael,
Michael Schloh von Bennewitz wrote:
> Hello Bogdan,
>
> On Tues., Feb. 16, 2010, Bogdan-Andrei Iancu wrote:
>
>> 1) what if the client is really dummy or does not have support for
>> auth at all, so you cannot rely on the UAC to send a second INVITE
>> with credentials.
>>
>>
> But this question is equally valid for regular usage of the auth
> module. If an administrator assumes that only UACs which will
> regiser are able to answer 401 or 407 replies correctly then
> he will have problems when a special case scenario appears (like
> the one you mention.) If I understand your question correctly,
> then the administrator knows to use uac_auth or proxy_challenge
> only when the client is not so dumb.
>
Not really - is the regular usage of uac_auth(), the UAC sends an INVITE
and opensips is doing the rest of the job (intercepting the 401 and
generating a new INVITE), totally transparent for UAC - here the UAC
does not have to do anything extra.
>
>> 2) what if the client - server relation is not passwd based, so again
>> the UAC cannot generate the INVITE with credentials
>>
>>
> Yes, the unmodified (in 1.6.X) uac_auth function only provides password
> based authentication. My changes simply extend the possible range of
> the unmodified uac_auth function to be usable from the request route
> as well. If the client must authenticate using a nonpassword based
> algorithm, then it's up to the admin to find a way to provide that.
> He won't be using uac_auth at all, so my changes are not relevant.
>
That is correct, but my question was actually overlapping with the first
one - about the capability of a client to send a second INVITE, in
response to a 401/407. Only the scenario was different than in the first
question:
scenario 1) - there is no auth relation between UAC and opensips, so
UAC cannot handle any auth challenge at all
scenario 2) - there is a non-passwd auth relation between UAC and
opensips, so UAC cannot handle any auth passwd-based challenge at all
>
>> 3) what if the the UAC is also authenticating to the server :
>> UAC -> INVITE -> proxy
>> UAC <- 407 proxy <- proxy
>> UAC -> INVITE+res_proxy-> proxy
>>proxy -> INVITE -> GW
>>proxy <- 407 gw <- GW
>> UAC <- 407 gw <- proxy
>>
> UAC -> INVITE+res_proxy+res_gw -> proxy -> INVITE -> GW
> proxy <- 200 OK <- GW
> UAC <- 200 OK <- proxy
>
>
>>at this moment the uac may stop responding (as it cannot answer
>>to the new request - unknown realm, or because it things the
>>first auth failed)
>>
>>
> I've tested this with only one softphone and one hardphone. Both
> Twinkle and Snom do indeed stop responding, but only if both proxy
> and gateway specify the same authentication realm. Probably this
> confuses the phone's software which thinks the authentication
> requests originated from the same server (not true.) This can be
> solved by the admin who has control over the auth module's realm
> logic.
>
> If there is no realm conflict then after the UAC tries once to
> authenticate to the SIP proxy it will accept 407 again and try
> to authenticate a second time, appending both Proxy-Authorization
> strings (one for each realm) to the new (third INVITE) request.
>
> Unfortunately, to solve the problem of a challenge loop the admin
> probably must use:
>
> modparam("auth", "disable_nonce_check", 1)
>
> ...to allow OpenSIPS to pass the third INVITE without challenging.
>
Right.
> I doubt that the SIP RFCs specify such multiple challenge results,
> so if that's true then the choice is up to us. The question is:
>
> Do we want to distribute and support a hacky way
> to provide multiple authentication stages?
>
Normally, this is a job for a b2bua and not for a proxy. I agree that
what we have so far is also a hack, so I do not expect the miracle-
solution here :). I'm not against hacking the hack, but I'm just trying
to see the design of the new hack and how it should work in some cases.
> Or would we rather restrict the admin to a single
> authentication stage?
>
That's impossible in same cases.
Regarding your solution, I see it as a clean idea -forcing the cseq
change from the UAC side- , but I'm so positive about who you try to
force the UAC the re-send the request (via a challenge) - what about
trying it via a 300 redirect (to the same destination) ?
> There's a chance to do this better using new B2B logic, but I
> kind of doubt that it would be much less hacky than this. Don't
> forget, the unmodified uac_auth function is hacky itself. It
> doesn't conform to RFC 2543 recommending sequential CSEQ numbers.
>
Again, right, but also making auth with b2bua requires some more work -
it will
Re: [OpenSIPS-Devel] ERROR:core:udp_send: sendto(): Operation not permitted(1)
well, the man page is not always complete. For sure I can say that EPERM is returned by sendto() when you block the traffic with some iptables rules on outbound chain. Regards, Bogdan adi wrote: > On Tue, Feb 16, 2010 at 12:22:50PM +0200, Bogdan-Andrei Iancu wrote: > >> The blocking is generated from kernel level it is typically related to >> the send socket (the IP used to send the message from). maybe you have >> some iptables on the OUTPUT chain. >> > > Thanks for responding. For sure there is no firewall rule on my > system. 'Unfortunately', the problem goes away (I do change opensips.cfg > several times). I'm a bit confuse with return code from sendto(), which > should not EPERM according to linux manpage. > > Regards, > > P.Y. Adi Prasaja > > ___ > Devel mailing list > Devel@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2955731 ] nat traversal and b2bua
Bugs item #2955731, was opened at 2010-02-21 00:19 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2955731&group_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: 1.6.x >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Richard Revels (rrevels) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: nat traversal and b2bua Initial Comment: The changes put in nat_traversal.c did not quite stop opensips from crashing when the module is loaded and the b2bua is used. I think a return statement is probably also needed. This incompatibility should probably be mentioned in the b2bua and nat_traversal docs. I don't think it's unreasonable for a person to believe that top hiding would be a good fit with natted clients. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-02-24 12:25 Message: Hi Richard, Indeed, a "return" was missing -I took care of it. Actually the incompatibility is not between b2bua and NAT, but between b2bua and nat_traversal, as nat_traversal is using dialog support in order to do nat traversal. If you use other nat modules (like nathelper), you should not have this issue. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2955731&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6622] branches/1.6/modules/nat_traversal/ nat_traversal.c
Revision: 6622 http://opensips.svn.sourceforge.net/opensips/?rev=6622&view=rev Author: bogdan_iancu Date: 2010-02-24 10:22:39 + (Wed, 24 Feb 2010) Log Message: --- backport from trunk (rev #6621): -fixed missing "return" - related to fix 6603. Reported by Richard Revels Closes bug 2955731.. Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6621&view=rev Modified Paths: -- branches/1.6/modules/nat_traversal/nat_traversal.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] SF.net SVN: opensips:[6621] trunk/modules/nat_traversal/nat_traversal.c
Revision: 6621 http://opensips.svn.sourceforge.net/opensips/?rev=6621&view=rev Author: bogdan_iancu Date: 2010-02-24 09:56:44 + (Wed, 24 Feb 2010) Log Message: --- -fixed missing "return" - related to fix 6603. Reported by Richard Revels Closes bug 2955731.. Modified Paths: -- trunk/modules/nat_traversal/nat_traversal.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] SF.net SVN: opensips:[6620] branches/1.5/modules/load_balancer/lb_db.c
Revision: 6620 http://opensips.svn.sourceforge.net/opensips/?rev=6620&view=rev Author: bogdan_iancu Date: 2010-02-24 09:49:17 + (Wed, 24 Feb 2010) Log Message: --- backport from trunk (rev #6618): - fixed imporper table init - must be before checkig table version Credits go to Walter Doekes ( SF id wdoekes). Closes bug report #2956632 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6618&view=rev Modified Paths: -- branches/1.5/modules/load_balancer/lb_db.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-2956632 ] database version check inconsistency in load_balancer
Bugs item #2956632, was opened at 2010-02-22 17:40 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2956632&group_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: 1.6.x >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Walter Doekes (wdoekes) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: database version check inconsistency in load_balancer Initial Comment: Hi, the other modules I've tried, check the table name defined in the modparam against the `version` table. The load_balancer.so module checks the default table name. I believe this to be wrong. The attached patch reorders the setting so the modparam-name is checked. Regards, Walter Doekes OSSO B.V. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-02-24 11:47 Message: Hi Walter, Thanks a lot for the fix - you are totally right. I just uploaded it on SVN (head and stable branches). Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2956632&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6619] branches/1.6/modules/load_balancer/lb_db.c
Revision: 6619 http://opensips.svn.sourceforge.net/opensips/?rev=6619&view=rev Author: bogdan_iancu Date: 2010-02-24 09:47:28 + (Wed, 24 Feb 2010) Log Message: --- backport from trunk (rev #6618): - fixed imporper table init - must be before checkig table version Credits go to Walter Doekes ( SF id wdoekes). Closes bug report #2956632 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6618&view=rev Modified Paths: -- branches/1.6/modules/load_balancer/lb_db.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] SF.net SVN: opensips:[6618] trunk/modules/load_balancer/lb_db.c
Revision: 6618 http://opensips.svn.sourceforge.net/opensips/?rev=6618&view=rev Author: bogdan_iancu Date: 2010-02-24 09:45:36 + (Wed, 24 Feb 2010) Log Message: --- - fixed imporper table init - must be before checkig table version Credits go to Walter Doekes ( SF id wdoekes). Closes bug report #2956632 Modified Paths: -- trunk/modules/load_balancer/lb_db.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-2956739 ] SRV lookup not correct
Bugs item #2956739, was opened at 2010-02-22 22:38 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2956739&group_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: core Group: 1.6.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Clark (byron_clark) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: SRV lookup not correct Initial Comment: When using an SRV record to relay to a destination, OpenSIPS will repeatedly attempt to send the message to the second result in the lookup reply. Here's an example (assume no response is received to the message): - call t_relay() to relay to sip.example.com - OpenSIPS performs SRV lookup for _sip._udp.sip.example.com - DNS responds with sip1.example.com, sip2.example.com, sip3.example.com, sip4.example.com (equal priority) - OpenSIPS performs A lookup for sip1.example.com - OpenSIPS relays the message to sip1.example.com (including retransmits) - OpenSIPS performs A lookulp for sip2.example.com - OpenSIPS relays the message to sip2.example.com (including retransmits) At this point, OpenSIPS should attempt to use sip3.example.com, but instead continues to lookup and then send the message to sip2.example.com until these errors show up in the log: Feb 18 16:36:08 bgw1 opensips[1745]: ERROR:tm:add_uac: maximum number of branches exceeded Feb 18 16:36:08 bgw1 opensips[1745]: ERROR:tm:t_forward_nonack: failure to add branches -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2010-02-24 11:40 Message: Hi, Could you post the logs (debug=4) for such a scenarios ? it will be easier for me to understand what is going on. Also, if the DNS record is public, maybe we could let me know its name, so that I can try for myself. Regards, Bogdan -- Comment By: Byron Clark (byron_clark) Date: 2010-02-22 22:40 Message: The attached patch (against the 1.6 branch) causes OpenSIPS to correctly walk through all of the SRV responses instead of continuing to use the same entry. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2956739&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2957313 ] [MediaProxy] Add support for ICE
Patches item #2957313, was opened at 2010-02-23 19:12 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2957313&group_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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: saghul (saghul) >Assigned to: Dan (dan_pascu) Summary: [MediaProxy] Add support for ICE Initial Comment: Hi, The attached patch adds support for using ICE (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19) in scenarios involving OpenSIPS and MediaProxy. Currently NAT is usually fixed by mangling the SDP in OpenSIPS and directing RTP to a media relay server. This SDP mangling makes ICE not to work, because ICE needs to have a candidate for the IP present in the c line of the SDP, and as the proxy changed it, ICE negotiation breaks. With the attached patch, OpenSIPS will add the necessary candidates to the SDP so that the ICE negotiation doesn't break and we can have p2p audio on LAN environments for example. :) Please consder it for inclusion in some later relase, Kind regards, PS: The design on how the issue has been solved can be seen here: http://mediaproxy.ag-projects.com/wiki/ICE PS2: This patch needs this other patch to be applied previously: https://sourceforge.net/tracker/?func=detail&aid=2949743&group_id=232389&atid=1086412 -- Saúl Ibarra Corretgé AG Projects -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2957313&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2949743 ] [MediaProxy] Fix the IP in the RTCP line
Patches item #2949743, was opened at 2010-02-11 17:00 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2949743&group_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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: saghul (saghul) >Assigned to: Dan (dan_pascu) Summary: [MediaProxy] Fix the IP in the RTCP line Initial Comment: Hi, The attached patch makes the MediaProxy module properly fix the IP in the RTCP line (if present in the SDP), as it currently doesn't. MediaProxy module hasn't changed (just 1 or 2 lines) since version 1.4, so the patch can be cleanly applied from version 1.4 up to trunk. -- Saúl Ibarra Corretgé AG Projects -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2949743&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [Memcached module] Adding cache_increment/cache_decrement methods
Sure, I'll attach the patches to this thread shortly. ( after verifying that
they work )
Thanks,
Abhinav
On Wed, Feb 24, 2010 at 2:31 PM, Alex Massover wrote:
> I’m also interested in this functionality, would you like to share it? J
>
> Maybe Andrei will like to apply your patches to the trunk J
>
>
>
> *From:* devel-boun...@lists.opensips.org [mailto:
> devel-boun...@lists.opensips.org] *On Behalf Of *Abhinav Jha
> *Subject:* Re: [OpenSIPS-Devel] [Memcached module] Adding
> cache_increment/cache_decrement methods
>
>
>
> Thanks Andrei,
>
>
>
> This helped a lot. I chose the first method (modified the parser to
> recognize cache_increment and cache_decrement methods) and now I have
> working atomic cached_increment and cached_decrement methods in memcached
> module as well :)
>
>
>
> Abhinav
>
> On Mon, Feb 22, 2010 at 4:01 PM, Andrei Dragus
> wrote:
>
> Hi there,
>
>
> > 1. cache_fetch, cache_store and cache_remove are not exported by the
> > memcached module anywhere. How then are we able to use them from
> > opensips.cfg ?
>
> There is a layer of abstractization called memcache(in the core)
> which can be implemented in two ways "memcached" or "localcache" (both
> are modules). The parser recognizes constructs such as "cache_store.."
> in the .cfg file and calls the appropriate methods of the
> abstractization layer (core), which in turn calls the method of the
> registered cache system(module).
>
>In other words you need to modify the parser to recognize
> "cache_increment" and "cache_decrement". If you choose this way you must
> also create appropriate methods in the localcache module or at least
> place warnings that they are not implemented.
>
>There is however a different approach. You can export the 2
> functions as you did, but you need to manually search for the server and
> call the library increment function. Of course the functions will look a
> little different. They will look like this:
>
> int cache_increment (struct sip_msg* msg, char* str1,char * str2 )
> {
>//...some code to find the appropriate handle in "servers" list
>// you should use fix-up functions if you know how
>
>//call the increment method.
>
>return 1; // or -1 on error
> }
>
> Hope it helps.
>
> --
> Andrei Dragus
>
> www.voice-system.ro
>
>
>
> ___
> Devel mailing list
> Devel@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
>
>
> This mail was received via Mail-SeCure System.
>
>
> This mail was sent via Mail-SeCure System.
>
> ___
> Devel mailing list
> Devel@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [Memcached module] Adding cache_increment/cache_decrement methods
I'm also interested in this functionality, would you like to share it? :)
Maybe Andrei will like to apply your patches to the trunk :)
From: devel-boun...@lists.opensips.org
[mailto:devel-boun...@lists.opensips.org] On Behalf Of Abhinav Jha
Subject: Re: [OpenSIPS-Devel] [Memcached module] Adding
cache_increment/cache_decrement methods
Thanks Andrei,
This helped a lot. I chose the first method (modified the parser to recognize
cache_increment and cache_decrement methods) and now I have working atomic
cached_increment and cached_decrement methods in memcached module as well :)
Abhinav
On Mon, Feb 22, 2010 at 4:01 PM, Andrei Dragus
mailto:adra...@opensips.org>> wrote:
Hi there,
> 1. cache_fetch, cache_store and cache_remove are not exported by the
> memcached module anywhere. How then are we able to use them from
> opensips.cfg ?
There is a layer of abstractization called memcache(in the core)
which can be implemented in two ways "memcached" or "localcache" (both
are modules). The parser recognizes constructs such as "cache_store.."
in the .cfg file and calls the appropriate methods of the
abstractization layer (core), which in turn calls the method of the
registered cache system(module).
In other words you need to modify the parser to recognize
"cache_increment" and "cache_decrement". If you choose this way you must
also create appropriate methods in the localcache module or at least
place warnings that they are not implemented.
There is however a different approach. You can export the 2
functions as you did, but you need to manually search for the server and
call the library increment function. Of course the functions will look a
little different. They will look like this:
int cache_increment (struct sip_msg* msg, char* str1,char * str2 )
{
//...some code to find the appropriate handle in "servers" list
// you should use fix-up functions if you know how
//call the increment method.
return 1; // or -1 on error
}
Hope it helps.
--
Andrei Dragus
www.voice-system.ro
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
This mail was received via Mail-SeCure System.
This mail was sent via Mail-SeCure System.
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2948561 ] deadlock on pua presentity lock
Bugs item #2948561, was opened at 2010-02-09 17:38
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2948561&group_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: 1.6.x
>Status: Closed
>Resolution: Invalid
Priority: 1
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: deadlock on pua presentity lock
Initial Comment:
Hi,
when sending the PUBLISH messages to self, using:
modparam("pua_dialoginfo", "presence_server", "sip:a.b.c.d:5060") # send
PUBLISH messages to self
I get a deadlock of the entire opensips daemon.
If I send the messages to somewhere else, the deadlock does not occur.
If I release the locks as per the attached patch, the deadlock doesn't occur
either.
But according to the comments in the code, the lock is not meant to be freed
just yet. So I'm not sure what my patch breaks instead. (I'm not even sure I'm
supposed to publish to self, but it seems like it, as I want to generate
notifies based on the state changes found in the publish.)
I'm running 1.6-svn (r6568)
Regards,
Walter Doekes
OSSO B.V.
--
>Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-02-24 10:15
Message:
Hi Walter,
The reason you get a deadlock is exactly that you use only one child. The
process might get blocked while trying to send a new Publish request and
there is no one to handle the reply for the previous one and release the
lock. So, it is compulsory to have more children when using pua module.
Regards,
Anca
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-02-24 08:59
Message:
Furthermore, I can add that I used children=1.
(Having children as 1 also led me to believe that setting $var()s in
startup_route could be used as process-wide constants, which they cannot.
This should clear up some more of the odd issues I was having. How would
you feel about a process_startup_route? I cannot believe I'm the only one
who likes constants at the top of the file.)
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-02-12 10:11
Message:
Hi Anca,
Thanks for your quick reply.
I've tried to reduce/declutter my config file to make it easily
reproducable, but during this reduction the problem goes away. I can hardly
give you the full config file as it's a bit of a complex hack, and
incomplete at that ;)
Yes, what I want to do is implement BLF on OpenSIPS. To do this, I do
basically this:
route {
if (uri == myself) {
if ($si == "e.f.g.h") { # my IP
if (method == "PUBLISH") {
handle_publish("sip:mys...@myself.myself");
exit;
}
}
if (method == "SUBSCRIBE") {
handle_subscribe();
exit;
}
if (method == "INVITE") {
dialoginfo_set();
record_route();
}
if ($si == "a.b.c.d") {
$var(local) = "sip:" + $(hdr(X-PIDstAccount)[-1]) + "@anydomain";
lookup("opensips_location", "", "$var(local)");
} else {
$rd = "a.b.c.d";
}
t_relay();
}
}
(Add a bit of nat handling, registration handling and transaction
handling.)
Modules loaded are:
loadmodule "xlog.so"# logging (xlog)
loadmodule "sl.so" # stateless functions (sl_*)
loadmodule "tm.so" # t_*: transactions in memory
loadmodule "signaling.so" # send reply according to state
loadmodule "rr.so" # record route
loadmodule "nathelper.so" # fix_nated_*()
loadmodule "textops.so" # append_hf
loadmodule "uri.so" # has_totag
loadmodule "db_mysql.so"# mysql
loadmodule "auth.so"# digest auth
loadmodule "auth_db.so" # digest auth
loadmodule "group.so" # groups (for acls)
loadmodule "permissions.so" # permissions (provide acls together with
groups)
loadmodule "usrloc.so" # user location
loadmodule "registrar.so" # lookup/save/registered
loadmodule "dialog.so" # ...
loadmodule "presence.so"# handle SUBSCRIBE events
loadmodule "presence_dialoginfo.so" # handle SUBSCRIBE events for
dialoginfo
loadmodule "presence_xml.so"# handle SUBSCRIBE events for dialoginfo
loadmodule "pua.so" # ...
loadmodule "pua_dialoginfo.so" # ...
...
modparam("pua_dialoginfo", "presence_server", "sip:e.f.g.h:5060") # send
PUBLISH messages to self
Now, it's quite possible that I'm doing things wrong. My grandstream test
phone has not answered at all to the opensips NOTIFY's sent by
handle_publish().
I'll try re-adding and reorganising my config file to get back the
complete behaviour I want (with or without the deadlock). In the me
