[Sofia-sip-devel] [ sofia-sip-Bugs-3353910 ] FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi
Bugs item #3353910, was opened at 2011-07-04 20:27
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3353910&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Laurent Bigonville (bigon)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi
Initial Comment:
Hi,
sofia-sip FTBFS on debian and ubuntu with error like :
./sofia-sip/sip_extra.h:2:1: error: expected identifier or '(' before '}' token
More information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628247
--
Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2011-07-14 16:20
Message:
sip_extra.h is a generated file; perhaps something goes wrong in the
processing script. Can you post the file as it is created in that build
environment?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3353910&group_id=143636
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3353910 ] FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi
Bugs item #3353910, was opened at 2011-07-04 19:27
Message generated for change (Tracker Item Submitted) made by bigon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3353910&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Laurent Bigonville (bigon)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi
Initial Comment:
Hi,
sofia-sip FTBFS on debian and ubuntu with error like :
./sofia-sip/sip_extra.h:2:1: error: expected identifier or '(' before '}' token
More information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628247
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3353910&group_id=143636
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Feature Requests-3306245 ] Use default certificate paths from OpenSSL
Feature Requests item #3306245, was opened at 2011-05-23 14:29 Message generated for change (Tracker Item Submitted) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=3306245&group_id=143636 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: None Group: None Status: Open Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Use default certificate paths from OpenSSL Initial Comment: It should be possible to make OpenSSL use default paths to search CA certificates for verification. A branch with a quick and dirty implementation is available here: https://gitorious.org/~mzabaluev/sofia-sip/mzabaluev-sofia-sip/commits/system-ca-path A backwards-compatible change would have to add a tag to enable this behavior, retaining the previous path use by default. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=3306245&group_id=143636 -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3291837 ] error of compile sofia sip client
Bugs item #3291837, was opened at 2011-04-23 06:39 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3291837&group_id=143636 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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: error of compile sofia sip client Initial Comment: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/sofia-sip-1.12 -I/usr/local/include/sofia-sip-1.12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT ssc_sip.lo -MD -MP -MF .deps/ssc_sip.Tpo -c ssc_sip.c -fPIC -DPIC -o .libs/ssc_sip.o ssc_sip.c: In function 'ssc_i_state': ssc_sip.c:1036: error: 'soatag_local_sdp_str_ref' undeclared (first use in this function) ssc_sip.c:1036: error: (Each undeclared identifier is reported only once - sofia sip 1.12.11 sofia sip client 0.16 -- Comment By: https://www.google.com/accounts () Date: 2011-04-23 08:19 Message: This has been fixed in gitorious, please see http://gitorious.org/sofia-sip/sofia-sip/commit/bcd0f17fd83f2dfe570a3ab17249a5c7290b27f2/ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3291837&group_id=143636 -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3291837 ] error of compile sofia sip client
Bugs item #3291837, was opened at 2011-04-23 06:39 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3291837&group_id=143636 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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: error of compile sofia sip client Initial Comment: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/sofia-sip-1.12 -I/usr/local/include/sofia-sip-1.12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT ssc_sip.lo -MD -MP -MF .deps/ssc_sip.Tpo -c ssc_sip.c -fPIC -DPIC -o .libs/ssc_sip.o ssc_sip.c: In function 'ssc_i_state': ssc_sip.c:1036: error: 'soatag_local_sdp_str_ref' undeclared (first use in this function) ssc_sip.c:1036: error: (Each undeclared identifier is reported only once - sofia sip 1.12.11 sofia sip client 0.16 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3291837&group_id=143636 -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-3222227 ] Fix win32 install script (headers copy)
Patches item #327, was opened at 2011-03-18 10:48 Message generated for change (Tracker Item Submitted) made by bvallee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=327&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benoît Vallée (bvallee) Assigned to: Nobody/Anonymous (nobody) Summary: Fix win32 install script (headers copy) Initial Comment: Correct a mistake in the win32 install script (install.cmd): replace copy of .*.h by copy of *.h -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=327&group_id=143636 -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-3184900 ] support for 503 and SRV. RFC 3263
Patches item #3184900, was opened at 2011-02-17 15:39 Message generated for change (Tracker Item Submitted) made by adubovikov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=3184900&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Dubovikov (adubovikov) Assigned to: Nobody/Anonymous (nobody) Summary: support for 503 and SRV. RFC 3263 Initial Comment: RFC 3263 "For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP).Failure also occurs if the transaction layer times out without ever having received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the client SHOULD create a new request, which is identical to the previous ..." unfortanly, sofia try to retransmit method (for example REGISTER) to the same destination. The patch try to fix this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=3184900&group_id=143636 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 17:24 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None >Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- >Comment By: SourceForge Robot (sf-robot) Date: 2011-01-25 20:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Pekka Pessi (ppessi) Date: 2011-01-10 22:34 Message: Proposed fix merged to git. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 15:42 Message: A fix is offered for review at http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 19:46 Message: Could be simple, though, in outbound_register_response: ob->ob_rcontact = sip_contact_dup(ob->ob_home, request->sip_contact); This is a copy of all contact headers present in the request. It then goes on to populate any REGISTER request in the same dialog usage. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 19:02 Message: Marking down a suspicious place where accumulation of headers may occur: nua/nua_stack.c, line 629: nua_stack_authenticate(nua, nh, event, tags); The client request can be restarted with event tags added directly to cr_msg in the client request structure. This is probably not the case where the proxy sends us contact headers, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3027352 ] Unable nua_destroy(), since nua_r_shutdown never arrives
Bugs item #3027352, was opened at 2010-07-09 14:55 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3027352&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Scorp (scorpfa) Assigned to: Nobody/Anonymous (nobody) Summary: Unable nua_destroy(), since nua_r_shutdown never arrives Initial Comment: Following Code for shutting down UA and Root is not working, because nua_r_shutdown event never comes through the event handler. nua_shutdown(m_nua); // <-- Here: endless waiting for nua_r_shutdown su_root_break(getRoot()); nua_destroy(m_nua); // <-- This would fail, since shutdown was not completed Cheers -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2011-01-18 15:29 Message: Do you use the glib mainloop integration? There is a problem in either nua_shutdown or nua_destroy where the event loop is iterated inside the function (which is a pretty daft idea), and glib event source processing does not allow this by default. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3027352&group_id=143636 -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2007672 ] IPv6 contact is used on IPv4 transport
Bugs item #2007672, was opened at 2008-07-01 15:38 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2007672&group_id=143636 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: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: IPv6 contact is used on IPv4 transport Initial Comment: Copied from Telepathy-SofiaSIP bug # 1988988: My client has both ipv4 and ipv6 addresses. It registers to a sip server with only ipv4. In the telepathy debug output i see: nta::contact: sip:sjoerd@[2a01:348:16d:0:20d:93ff:fe83:5a93]:44547> and on the server it says: Contact "user" -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2011-01-17 16:13 Message: Duplicate of 1751089. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 18:14 Message: There are some interesting race conditions when running tests on a dual-stack host which seem to be related to this problem: test_refer.c:502: check_sofia test_refer0() FAILED: nua_event_name(e->data->e_event) != nua_event_name(nua_i_notify) or "nua_i_bye" != "nua_i_notify" 75%: Checks: 8, Failures: 2, Errors: 0 suite_for_nua.c:114:F:with-proxy:with_proxy:0: Failure 'test_call_cancel(ctx)' occured suite_for_nua.c:144:F:with-proxy-and-nat:with_proxy_and_nat:0: Failure 'test_refer(ctx)' occured In the transport logs, I see the transport vs Via confusion: send 440 bytes to udp/[127.0.0.1]:40531 at 16:07:04.984607: SIP/2.0 200 OK Via: SIP/2.0/UDP [::1]:56324;rport=40531;branch=z9hG4bK889NQ3Uy3r82r;received=127.0.0.1 From: ;tag=HZgg3tZKtX00r To: ;tag=NDHFpHcQ597DN Call-ID: 83ee296f-8e08-122e-bd84-00218696a9bc CSeq: 6483350 BYE User-Agent: sofia-sip/1.12.10devel Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Content-Length: 0 ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2007672&group_id=143636 -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Settings changed) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None >Status: Pending Resolution: Fixed Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- Comment By: Pekka Pessi (ppessi) Date: 2011-01-11 00:34 Message: Proposed fix merged to git. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 17:42 Message: A fix is offered for review at http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:46 Message: Could be simple, though, in outbound_register_response: ob->ob_rcontact = sip_contact_dup(ob->ob_home, request->sip_contact); This is a copy of all contact headers present in the request. It then goes on to populate any REGISTER request in the same dialog usage. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:02 Message: Marking down a suspicious place where accumulation of headers may occur: nua/nua_stack.c, line 629: nua_stack_authenticate(nua, nh, event, tags); The client request can be restarted with event tags added directly to cr_msg in the client request structure. This is probably not the case where the proxy sends us contact headers, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None Status: Open >Resolution: Fixed Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- >Comment By: Pekka Pessi (ppessi) Date: 2011-01-11 00:34 Message: Proposed fix merged to git. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 17:42 Message: A fix is offered for review at http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:46 Message: Could be simple, though, in outbound_register_response: ob->ob_rcontact = sip_contact_dup(ob->ob_home, request->sip_contact); This is a copy of all contact headers present in the request. It then goes on to populate any REGISTER request in the same dialog usage. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:02 Message: Marking down a suspicious place where accumulation of headers may occur: nua/nua_stack.c, line 629: nua_stack_authenticate(nua, nh, event, tags); The client request can be restarted with event tags added directly to cr_msg in the client request structure. This is probably not the case where the proxy sends us contact headers, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 18:02 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- >Comment By: Pekka Pessi (ppessi) Date: 2011-01-11 00:31 Message: I've merged Misha's patches to the git repo. -- Comment By: Pacho Ramos (pacho2) Date: 2011-01-05 21:47 Message: Thanks -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2011-01-05 18:41 Message: The fix is merged into master. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 20:12 Message: A fix is available for review: http://gitorious.org/sofia-sip/sofia-sip/merge_requests/3 -- Comment By: Pacho Ramos (pacho2) Date: 2010-09-03 13:24 Message: Yes, of course $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 17:02 Message generated for change (Comment added) made by pacho2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- >Comment By: Pacho Ramos (pacho2) Date: 2011-01-05 20:47 Message: Thanks -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2011-01-05 17:41 Message: The fix is merged into master. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 19:12 Message: A fix is available for review: http://gitorious.org/sofia-sip/sofia-sip/merge_requests/3 -- Comment By: Pacho Ramos (pacho2) Date: 2010-09-03 12:24 Message: Yes, of course $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 18:02 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2011-01-05 18:41 Message: The fix is merged into master. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 20:12 Message: A fix is available for review: http://gitorious.org/sofia-sip/sofia-sip/merge_requests/3 -- Comment By: Pacho Ramos (pacho2) Date: 2010-09-03 13:24 Message: Yes, of course $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --d
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 18:02 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 20:12 Message: A fix is available for review: http://gitorious.org/sofia-sip/sofia-sip/merge_requests/3 -- Comment By: Pacho Ramos (pacho2) Date: 2010-09-03 13:24 Message: Yes, of course $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enabl
[Sofia-sip-devel] [ sofia-sip-Bugs-2007672 ] IPv6 contact is used on IPv4 transport
Bugs item #2007672, was opened at 2008-07-01 15:38 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2007672&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: IPv6 contact is used on IPv4 transport Initial Comment: Copied from Telepathy-SofiaSIP bug # 1988988: My client has both ipv4 and ipv6 addresses. It registers to a sip server with only ipv4. In the telepathy debug output i see: nta::contact: sip:sjo...@[2a01:348:16d:0:20d:93ff:fe83:5a93]:44547> and on the server it says: Contact "user" -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 18:14 Message: There are some interesting race conditions when running tests on a dual-stack host which seem to be related to this problem: test_refer.c:502: check_sofia test_refer0() FAILED: nua_event_name(e->data->e_event) != nua_event_name(nua_i_notify) or "nua_i_bye" != "nua_i_notify" 75%: Checks: 8, Failures: 2, Errors: 0 suite_for_nua.c:114:F:with-proxy:with_proxy:0: Failure 'test_call_cancel(ctx)' occured suite_for_nua.c:144:F:with-proxy-and-nat:with_proxy_and_nat:0: Failure 'test_refer(ctx)' occured In the transport logs, I see the transport vs Via confusion: send 440 bytes to udp/[127.0.0.1]:40531 at 16:07:04.984607: SIP/2.0 200 OK Via: SIP/2.0/UDP [::1]:56324;rport=40531;branch=z9hG4bK889NQ3Uy3r82r;received=127.0.0.1 From: ;tag=HZgg3tZKtX00r To: ;tag=NDHFpHcQ597DN Call-ID: 83ee296f-8e08-122e-bd84-00218696a9bc CSeq: 6483350 BYE User-Agent: sofia-sip/1.12.10devel Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Content-Length: 0 ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2007672&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-29 17:42 Message: A fix is offered for review at http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:46 Message: Could be simple, though, in outbound_register_response: ob->ob_rcontact = sip_contact_dup(ob->ob_home, request->sip_contact); This is a copy of all contact headers present in the request. It then goes on to populate any REGISTER request in the same dialog usage. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:02 Message: Marking down a suspicious place where accumulation of headers may occur: nua/nua_stack.c, line 629: nua_stack_authenticate(nua, nh, event, tags); The client request can be restarted with event tags added directly to cr_msg in the client request structure. This is probably not the case where the proxy sends us contact headers, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:46 Message: Could be simple, though, in outbound_register_response: ob->ob_rcontact = sip_contact_dup(ob->ob_home, request->sip_contact); This is a copy of all contact headers present in the request. It then goes on to populate any REGISTER request in the same dialog usage. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:02 Message: Marking down a suspicious place where accumulation of headers may occur: nua/nua_stack.c, line 629: nua_stack_authenticate(nua, nh, event, tags); The client request can be restarted with event tags added directly to cr_msg in the client request structure. This is probably not the case where the proxy sends us contact headers, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-28 21:02 Message: Marking down a suspicious place where accumulation of headers may occur: nua/nua_stack.c, line 629: nua_stack_authenticate(nua, nh, event, tags); The client request can be restarted with event tags added directly to cr_msg in the client request structure. This is probably not the case where the proxy sends us contact headers, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Settings changed) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded
Bugs item #3146414, was opened at 2010-12-27 19:24 Message generated for change (Tracker Item Submitted) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Expired contact entries are never discarded Initial Comment: As reported in: https://bugs.maemo.org/show_bug.cgi?id=8615 https://bugs.freedesktop.org/show_bug.cgi?id=32615 When two sofia-sip stacks meet each other, one as the UA and the other as a proxy, they happily accumulate outdated Contact headers without end. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3146414&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-27 19:20 Message: Fixed in commit 01baa987b3bdc2791118c1be9b74b625f76d6b1c -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 16:58 Message: The CNAME problem with proxy01.sipphone.com is still there with the recent trunk changes. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:34 Message: It breaks with proxy01.sipphone.com, too. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:05 Message: The patch regresses a case where SRV refers to a CNAME. Granted it's not allowed by strict DNS spec, but it used to work. telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._udp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._udp.sip1.cosmicparrot.net IN SRV 0 0 5063 sip1.cosmicparrot.net. (udp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._tcp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._tcp.sip1.cosmicparrot.net IN SRV 0 0 5062 sip1.cosmicparrot.net. (tcp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net" A (cached) telepathy-sofiasip[2040]: GLIB DEBUG default - tpsip_connection_sofia_callback: event nua_r_register: 503 DNS Error ;; QUESTION SECTION: ;sip1.cosmicparrot.net. IN A ;; ANSWER SECTION: sip1.cosmicparrot.net. 86400 IN CNAME svc.cosmicparrot.net. svc.cosmicparrot.net. 49472 IN A 217.152.255.16 -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 19:17 Message: Fri Jan 23 19:13:41 EET 2009 Pekka Pessi * sresolv: caching SRES_RECORD_ERR in case a CNAME is returned, too Tracing the CNAMEs when doing cache lookups. Misha, please verify. -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 18:18 Message: Looks like sres does not check that it got what it asked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1633969 ] nua stack timer runs too frequently
Bugs item #1633969, was opened at 2007-01-12 13:04 Message generated for change (Settings changed) made by kaiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1633969&group_id=143636 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: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kai Vehmanen (kaiv) Assigned to: Pekka Pessi (ppessi) Summary: nua stack timer runs too frequently Initial Comment: The nua stack timer runs current at 1Hz. This is too frequent for some uses, so either the timer interval should be decreased, it should be made configurable, or completely replaced by more fine-grained timers (as was done in sresolv). -- >Comment By: Kai Vehmanen (kaiv) Date: 2010-12-13 13:52 Message: Closing as per previous comment. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-07 11:43 Message: This has been fixed by making the timers deferrable. Now the timers can use a pacemaker on platforms where battery life matters. I'm lost in this new interface, it seems I cannot close this bug myself. -- Comment By: Pekka Pessi (ppessi) Date: 2007-01-23 18:53 Message: Logged In: YES user_id=52043 Originator: NO The nta timer run at 16 Hz by default, too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1633969&group_id=143636 -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1633969 ] nua stack timer runs too frequently
Bugs item #1633969, was opened at 2007-01-12 13:04 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1633969&group_id=143636 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: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Kai Vehmanen (kaiv) Assigned to: Pekka Pessi (ppessi) Summary: nua stack timer runs too frequently Initial Comment: The nua stack timer runs current at 1Hz. This is too frequent for some uses, so either the timer interval should be decreased, it should be made configurable, or completely replaced by more fine-grained timers (as was done in sresolv). -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2010-12-07 11:43 Message: This has been fixed by making the timers deferrable. Now the timers can use a pacemaker on platforms where battery life matters. I'm lost in this new interface, it seems I cannot close this bug myself. -- Comment By: Pekka Pessi (ppessi) Date: 2007-01-23 18:53 Message: Logged In: YES user_id=52043 Originator: NO The nta timer run at 16 Hz by default, too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1633969&group_id=143636 -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3065356 ] More robust behavior with pbxes.org (SCTP)
Bugs item #3065356, was opened at 2010-09-13 14:29 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3065356&group_id=143636 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: None Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: More robust behavior with pbxes.org (SCTP) Initial Comment: Originally reported in https://bugs.freedesktop.org/show_bug.cgi?id=30164 The stack is somehow tricked into using SCTP which is not supported by the kernel, and this makes a request fail. There should be a fallback for this, unless there is some DNS misconfiguration on behalf of pbxes.org. I could not find any, except them responding to any A query with an IP address. -- >Comment By: SourceForge Robot (sf-robot) Date: 2010-10-01 16:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Pekka Pessi (ppessi) Date: 2010-09-17 16:05 Message: The pbxes.org seems to have removed NAPTR and/or _sip._sctp. record. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3065356&group_id=143636 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3065356 ] More robust behavior with pbxes.org (SCTP)
Bugs item #3065356, was opened at 2010-09-13 17:29 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3065356&group_id=143636 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: None Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: More robust behavior with pbxes.org (SCTP) Initial Comment: Originally reported in https://bugs.freedesktop.org/show_bug.cgi?id=30164 The stack is somehow tricked into using SCTP which is not supported by the kernel, and this makes a request fail. There should be a fallback for this, unless there is some DNS misconfiguration on behalf of pbxes.org. I could not find any, except them responding to any A query with an IP address. -- >Comment By: Pekka Pessi (ppessi) Date: 2010-09-17 19:05 Message: The pbxes.org seems to have removed NAPTR and/or _sip._sctp. record. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3065356&group_id=143636 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3065356 ] More robust behavior with pbxes.org (SCTP)
Bugs item #3065356, was opened at 2010-09-13 17:29 Message generated for change (Tracker Item Submitted) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3065356&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: More robust behavior with pbxes.org (SCTP) Initial Comment: Originally reported in https://bugs.freedesktop.org/show_bug.cgi?id=30164 The stack is somehow tricked into using SCTP which is not supported by the kernel, and this makes a request fail. There should be a fallback for this, unless there is some DNS misconfiguration on behalf of pbxes.org. I could not find any, except them responding to any A query with an IP address. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3065356&group_id=143636 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 17:02 Message generated for change (Comment added) made by pacho2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- >Comment By: Pacho Ramos (pacho2) Date: 2010-09-03 12:24 Message: Yes, of course $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/python --enable-java-awt=gtk --enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix --enable-__cxa_ate
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 18:02 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- >Comment By: Pekka Pessi (ppessi) Date: 2010-08-04 17:47 Message: Which compiler is used there? Can you get gcc -v and cat /proc/cpuinfo from those who are bitten by this bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3035859 ] Sofia Stack not rejecting Invite with out CallID and To TAG
Bugs item #3035859, was opened at 2010-07-28 15:57 Message generated for change (Tracker Item Submitted) made by vikasverin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3035859&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vikas Bhat (vikasverin) Assigned to: Nobody/Anonymous (nobody) Summary: Sofia Stack not rejecting Invite with out CallID and To TAG Initial Comment: Sofia Stack is allowing the call with out CallID . Also Call is allowed without the TO TAG. Stack should reject the call without any one from the following fields : CallID ,or TO Tag or To or BranchID but call is allowed in the above scenerio. can you guide me if i need to do any change in stack side or use any particular version of Sofia. Thanks Vikas Bhat -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3035859&group_id=143636 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass
Bugs item #3034730, was opened at 2010-07-26 17:02 Message generated for change (Tracker Item Submitted) made by pacho2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 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: build system Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pacho Ramos (pacho2) Assigned to: Nobody/Anonymous (nobody) Summary: torture_url test fail to pass Initial Comment: This has been noticed downstream: http://bugs.gentoo.org/show_bug.cgi?id=328733#c2 PASS: run_test_sdp == All 2 tests passed == make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp' Making check in url make[2]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-am make[3]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make torture_url make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt -I./../su -I../su -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -MT torture_url.o -MD -MP -MF ".deps/torture_url.Tpo" -c -o torture_url.o torture_url.c; \ then mv -f ".deps/torture_url.Tpo" ".deps/torture_url.Po"; else rm -f ".deps/torture_url.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la ../su/libsu.la -lssl -lcrypto -lrt -lpthread i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb -Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o ./.libs/liburl.a ../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto -lrt -lpthread make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make check-TESTS make[4]: Entering directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' torture_url.c:279: torture_url test_sip() FAILED: url_query_as_header_string(home, url->url_headers) != "\n\nCANNED MSG" or NULL != " CANNED MSG" FAIL: torture_url === 1 of 1 tests failed === make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[2]: *** [check] Error 2 make[2]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua' make: *** [check-recursive] Error 1 And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6 Thanks a lot for solving this -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3034730&group_id=143636 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 18:06 Message generated for change (Comment added) made by gehrehmee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Jeremy Nickurak (gehrehmee) Date: 2010-07-19 15:39 Message: Reported against ekiga's bug tracker at: https://bugzilla.gnome.org/show_bug.cgi?id=624751 -- Comment By: Jeremy Nickurak (gehrehmee) Date: 2010-07-19 15:33 Message: Affecting Ubuntu via https://bugs.launchpad.net/ekiga/+bug/294994 , debian via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535796 , both via telepathy-sofiasip on https://bugs.freedesktop.org/show_bug.cgi?id=19328 -- Comment By: Johan Brannlund (jbrnd) Date: 2010-01-21 17:34 Message: I'm not 100% sure I did everything correctly, but using sofia-sip trunk didn't change anything for me. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-11-13 16:26 Message: What do you know, it works for me with the sofia-sip build we use in Maemo 5. Can somebody else confirm if it works with sofia-sip trunk? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-10-15 11:47 Message: > So, if the problem is with ekiga.net, has anyone contacted them about it yet? Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though. -- Comment By: Murray Cumming (murrayc) Date: 2009-10-13 05:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 13:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 09:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 18:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 19:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -----
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 18:06 Message generated for change (Comment added) made by gehrehmee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Jeremy Nickurak (gehrehmee) Date: 2010-07-19 15:33 Message: Affecting Ubuntu via https://bugs.launchpad.net/ekiga/+bug/294994 , debian via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535796 , both via telepathy-sofiasip on https://bugs.freedesktop.org/show_bug.cgi?id=19328 -- Comment By: Johan Brannlund (jbrnd) Date: 2010-01-21 17:34 Message: I'm not 100% sure I did everything correctly, but using sofia-sip trunk didn't change anything for me. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-11-13 16:26 Message: What do you know, it works for me with the sofia-sip build we use in Maemo 5. Can somebody else confirm if it works with sofia-sip trunk? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-10-15 11:47 Message: > So, if the problem is with ekiga.net, has anyone contacted them about it yet? Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though. -- Comment By: Murray Cumming (murrayc) Date: 2009-10-13 05:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 13:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 09:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 18:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 19:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- This SF.net email is sponsor
[Sofia-sip-devel] [ sofia-sip-Bugs-3027352 ] Unable nua_destroy(), since nua_r_shutdown never arrives
Bugs item #3027352, was opened at 2010-07-09 13:55 Message generated for change (Settings changed) made by scorpfa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3027352&group_id=143636 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: None Group: None Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Scorp (scorpfa) Assigned to: Nobody/Anonymous (nobody) Summary: Unable nua_destroy(), since nua_r_shutdown never arrives Initial Comment: Following Code for shutting down UA and Root is not working, because nua_r_shutdown event never comes through the event handler. nua_shutdown(m_nua); // <-- Here: endless waiting for nua_r_shutdown su_root_break(getRoot()); nua_destroy(m_nua); // <-- This would fail, since shutdown was not completed Cheers -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3027352&group_id=143636 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3027352 ] Unable nua_destroy(), since nua_r_shutdown never arrives
Bugs item #3027352, was opened at 2010-07-09 13:55 Message generated for change (Tracker Item Submitted) made by scorpfa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3027352&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Scorp (scorpfa) Assigned to: Nobody/Anonymous (nobody) Summary: Unable nua_destroy(), since nua_r_shutdown never arrives Initial Comment: Following Code for shutting down UA and Root is not working, because nua_r_shutdown event never comes through the event handler. nua_shutdown(m_nua); // <-- Here: endless waiting for nua_r_shutdown su_root_break(getRoot()); nua_destroy(m_nua); // <-- This would fail, since shutdown was not completed Cheers -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3027352&group_id=143636 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-3000830 ] sofia sip client with openimscore
Bugs item #3000830, was opened at 2010-05-13 01:32 Message generated for change (Tracker Item Submitted) made by wepawetmose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3000830&group_id=143636 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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: wepawetmose (wepawetmose) Assigned to: Nobody/Anonymous (nobody) Summary: sofia sip client with openimscore Initial Comment: Hi, im using sofia sip client with openimscore and i need to get it communicating each other. "...surely Expires is a nice to have header :-) I've added it to sofsip_cli and now both Alice and Bob appear as REGISTERED in FHoSS web interface" well, THIS is exactly what i wanna do but dont know how! if Starting the service: "sofsip_cli --media-impl=dummy --registrar=sip:open-ims.test --proxy=sip:pcscf.open-ims.test:4060 " I get: "su_source_port_create() returns 0x90a4234 ** (sofsip_cli:4350): DEBUG: ssc_media_class_init:124 ** (sofsip_cli:4350): DEBUG: ssc_media_init:169 ** Message: Selecting media implementation: dummy sofsip> UA: unknown event 'nua_r_set_params' (23): 200 OK ::tag_null: 0 NOTE: destroying handle (nil). sofsip> UA: nua_r_getparams: 200 OK sip::from: sip::from_str: "" nua::retry_count: 3 nua::max_subscriptions: 20 nua::media_enable: true nua::enableInvite: true nua::autoAlert: true nua::early_media: false nua::only183_100rel: false nua::autoAnswer: false nua::autoACK: true nua::invite_timer: 120 nua::session_timer: 0 nua::min_se: 120 nua::session_refresher: 0 nua::update_refresh: false nua::enableMessage: true nua::enableMessenger: false nua::callee_caps: false nua::media_features: false nua::service_route_enable: true nua::path_enable: true nua::refer_expires: 300 nua::refer_with_id: true nua::substate: 2 nua::substate: 3600 sip::supported: timer, 100rel sip::supported_str: "timer, 100rel" sip::allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE sip::allow_str: "INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE" nua::appl_method: "INVITE, REGISTER, PUBLISH, SUBSCRIBE" sip::user_agent: sofia-sip/1.12.10 sip::user_agent_str: "sofia-sip/1.12.10" nua::user_agent: "sofia-sip/1.12.10" nua::registrar: nua::keepalive: 12 nua::outbound: "natify" nta::contact: nta::udp_mtu: 1300 nta::max_proceeding: 4294967295 nta::sip_t1: 500 nta::sip_t2: 4000 nta::sip_t4: 5000 nta::sip_t1x64: 32000 nta::debug_drop_prob: 0 nta::default_proxy: nta::aliases: nta::sipflags: 2 soa::caps_sdp: v=0 o=- 7732089869805783786 4683031078712322020 IN IP4 172.16.6.159 s=- c=IN IP4 172.16.6.159 t=0 0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 soa::caps_sdp_str: "v=0 o=- 7732089869805783786 4683031078712322020 IN IP4 172.16.6.159 s=- c=IN IP4 172.16.6.159 t=0 0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 " soa::user_sdp: v=0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 soa::user_sdp_str: "v=0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 " soa::local_sdp_str: soa::af: 3 soa::srtp_enable: false soa::srtp_confidentiality: false soa::srtp_integrity: false ::tag_null: 0 Starting sofsip-cli in interactive mode. Issue 'h' to get list of available commands. sofsip>" witch is good, so far. then: "addr sip:b...@open-ims.test sofsip> UA: unknown event 'nua_r_set_params' (23): 200 OK ::tag_null: 0 NOTE: destroying handle (nil). sofsip> " not so good, but works! BUT after: "sofsip> r UA: REGISTER sip:b...@open-ims.test - updating existing registration sofsip> UA: REGISTER: 401 Unauthorized - Challenging the UE Server auth: Digest realm="open-ims.test", nonce="97FmRP9GLEaTRubVfl5/CDSc+jk9dQAAi7fVOC81s9I=", algorithm=AKAv1-MD5, qop="auth,auth-int" Please authenticate 'Digest' with the 'k' command (e.g. 'k password', or 'k [method:realm:username:]password') sofsip> " I get an error in openimscore: "ERR: P-CSCF:cscf_get_authorization: Message does not contain Authorization header." Can anyone help me? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3000830&group_id=143636 -- ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-2966302 ] Allow : character in authentication realms
Patches item #2966302, was opened at 2010-03-09 12:26 Message generated for change (Tracker Item Submitted) made by darrenb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2966302&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darren Bane (darrenb) Assigned to: Nobody/Anonymous (nobody) Summary: Allow : character in authentication realms Initial Comment: According to the SIP RFC, they should be allowed (quoted-string). And we've seen this done by an ITSP. -- Darren Bane, Emutex Ltd. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2966302&group_id=143636 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2914940 ] Crash in 1.12.10
Bugs item #2914940, was opened at 2009-12-15 15:57 Message generated for change (Comment added) made by fabiomargarido You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2914940&group_id=143636 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: None Group: None Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Fabio Margarido (fabiomargarido) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in 1.12.10 Initial Comment: We've been observing recurring crashes in one of our clients' applications and after a bit of digging around and successfully setting up the client's environment to run valgrind, we were able to obtain the following backtrace for the problem: ==2608== ==2608== Thread 11: ==2608== Invalid read of size 4 ==2608==at 0x40BEE93: nua_prack_server_report (nua_session.c:2893) ==2608==by 0x40A74CE: nua_server_report (nua_stack.c:1827) ==2608==by 0x40A6AC3: nua_stack_respond (nua_stack.c:1633) ==2608==by 0x40A45BF: nua_stack_signal (nua_stack.c:650) ==2608==by 0x40FF0B3: su_base_port_execute_msgs (su_base_port.c:276) ==2608==by 0x40FEE1F: su_base_port_getmsgs (su_base_port.c:198) ==2608==by 0x40FF175: su_base_port_run (su_base_port.c:331) ==2608==by 0x40FCFCA: su_port_run (su_port.h:310) ==2608==by 0x40FC2BF: su_root_run (su_root.c:689) ==2608==by 0x40FFCF7: su_pthread_port_clone_main (su_pthread_port.c:321) ==2608==by 0x41B30CD: pthread_start_thread (manager.c:291) ==2608==by 0x4321739: clone (in /lib/libc-2.2.4.so) ==2608== Address 0x4c3d67c is 68 bytes inside a block of size 72 free'd ==2608==at 0x401A61F: free (m_replacemalloc/vg_replace_malloc.c:323) ==2608==by 0x40F7464: su_free (su_alloc.c:838) ==2608==by 0x40A688F: nua_server_request_destroy (nua_stack.c:1504) ==2608==by 0x40BE3AE: process_ack (nua_session.c:2573) ==2608==by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2608==by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2608==by 0x408CAD3: incoming_ack (nta.c:6009) ==2608==by 0x40852BD: agent_recv_request (nta.c:2891) ==2608==by 0x4084478: agent_recv_message (nta.c:2722) ==2608==by 0x4111903: tport_base_deliver (tport.c:3013) ==2608==by 0x4111896: tport_deliver (tport.c:3002) ==2608==by 0x4111456: tport_parse (tport.c:2919) Further investigation showed other crashes in similar conditions, such as this one: ==2714== ==2714== Thread 11: ==2714== Invalid read of size 4 ==2714==at 0x40A67D3: nua_server_request_destroy (nua_stack.c:1488) ==2714==by 0x40BE3AE: process_ack (nua_session.c:2573) ==2714==by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2714==by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2714==by 0x408CAD3: incoming_ack (nta.c:6009) ==2714==by 0x40852BD: agent_recv_request (nta.c:2891) ==2714==by 0x4084478: agent_recv_message (nta.c:2722) ==2714==by 0x4111903: tport_base_deliver (tport.c:3013) ==2714==by 0x4111896: tport_deliver (tport.c:3002) ==2714==by 0x4111456: tport_parse (tport.c:2919) ==2714==by 0x401: tport_recv_event (tport.c:2861) ==2714==by 0x4110D7D: tport_base_wakeup (tport.c:2763) ==2714== Address 0x5451cb4 is 68 bytes inside a block of size 72 free'd ==2714==at 0x401A61F: free (m_replacemalloc/vg_replace_malloc.c:323) ==2714==by 0x40F7464: su_free (su_alloc.c:838) ==2714==by 0x40A688F: nua_server_request_destroy (nua_stack.c:1504) ==2714==by 0x40BB93A: nua_session_usage_shutdown (nua_session.c:1575) ==2714==by 0x40AC554: nua_dialog_usage_shutdown (nua_dialog.c:603) ==2714==by 0x40AA6DA: nua_base_client_response (nua_stack.c:3257) ==2714==by 0x40BA5BB: nua_session_client_response (nua_session.c:1007) ==2714==by 0x40B99FB: nua_invite_client_response (nua_session.c:865) ==2714==by 0x40A98D7: nua_client_response (nua_stack.c:2914) ==2714==by 0x40A9646: nua_client_return (nua_stack.c:2835) ==2714==by 0x40B931C: nua_invite_client_init (nua_session.c:745) ==2714==by 0x40A87DE: nua_client_init_request0 (nua_stack.c:2448) ==2714== ==2714== Invalid read of size 4 ==2714==at 0x40A67EE: nua_server_request_destroy (nua_stack.c:1491) ==2714==by 0x40BE3AE: process_ack (nua_session.c:2573) ==2714==by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2714==by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2714==by 0x408CAD3: incoming_ack (nta.c:6009) ==2714==by 0x40852BD: agent_recv_request (nta.c:2891) ==2714==by 0x4084478: agent_recv_message (nta.c:2722) ==2714==by 0x4111903: tport_base_deliver (tport.c:3013) ==2714==by 0x4111896: tport_deliver (tport.c:3002) ==2714==by 0x4111456: tport_parse (tport.c:2919) ==2714==by 0x401: tport_recv_event (tport.c:2861) ==2714==by 0x
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 10:06 Message generated for change (Comment added) made by jbrnd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Johan Brannlund (jbrnd) Date: 2010-01-21 09:34 Message: I'm not 100% sure I did everything correctly, but using sofia-sip trunk didn't change anything for me. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-11-13 08:26 Message: What do you know, it works for me with the sofia-sip build we use in Maemo 5. Can somebody else confirm if it works with sofia-sip trunk? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-10-15 04:47 Message: > So, if the problem is with ekiga.net, has anyone contacted them about it yet? Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though. -- Comment By: Murray Cumming (murrayc) Date: 2009-10-12 22:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 06:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 02:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 10:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 05:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 11:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___
[Sofia-sip-devel] [ sofia-sip-Bugs-2926032 ] Crash in AUTH_CLIENT_IS_EXTENDED
Bugs item #2926032, was opened at 2010-01-05 16:37
Message generated for change (Tracker Item Submitted) made by daniellemadeley
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2926032&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Danielle Madeley (daniellemadeley)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in AUTH_CLIENT_IS_EXTENDED
Initial Comment:
Program received signal SIGSEGV, Segmentation fault.
0x0039362e in ca_credentials (ca=0x8083550, scheme=0x80844d8 "NTLM",
realm=0x80844dd "\"SIP Communications Service\"", user=0x80844fa "test",
pass=0x80844ff "") at auth_client.c:404
404 if (AUTH_CLIENT_IS_EXTENDED(ca))
(gdb) p *ca
$3 = {ca_home = {{suh_size = 78, suh_blocks = 0x8084358, suh_lock = 0x0}},
ca_auc = 0x0, ca_next = 0x0, ca_scheme = 0x8083599 "NTLM",
ca_realm = 0x808357c "\"SIP Communications Service\"",
ca_user = 0x8077968 "test", ca_pass = 0x8079638 "",
ca_credential_class = 0x0, ca_clear = 0}
ca_auc is NULL
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2926032&group_id=143636
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2914940 ] Crash in 1.12.10
Bugs item #2914940, was opened at 2009-12-15 15:57 Message generated for change (Tracker Item Submitted) made by fabiomargarido You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2914940&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabio Margarido (fabiomargarido) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in 1.12.10 Initial Comment: We've been observing recurring crashes in one of our clients' applications and after a bit of digging around and successfully setting up the client's environment to run valgrind, we were able to obtain the following backtrace for the problem: ==2608== ==2608== Thread 11: ==2608== Invalid read of size 4 ==2608==at 0x40BEE93: nua_prack_server_report (nua_session.c:2893) ==2608==by 0x40A74CE: nua_server_report (nua_stack.c:1827) ==2608==by 0x40A6AC3: nua_stack_respond (nua_stack.c:1633) ==2608==by 0x40A45BF: nua_stack_signal (nua_stack.c:650) ==2608==by 0x40FF0B3: su_base_port_execute_msgs (su_base_port.c:276) ==2608==by 0x40FEE1F: su_base_port_getmsgs (su_base_port.c:198) ==2608==by 0x40FF175: su_base_port_run (su_base_port.c:331) ==2608==by 0x40FCFCA: su_port_run (su_port.h:310) ==2608==by 0x40FC2BF: su_root_run (su_root.c:689) ==2608==by 0x40FFCF7: su_pthread_port_clone_main (su_pthread_port.c:321) ==2608==by 0x41B30CD: pthread_start_thread (manager.c:291) ==2608==by 0x4321739: clone (in /lib/libc-2.2.4.so) ==2608== Address 0x4c3d67c is 68 bytes inside a block of size 72 free'd ==2608==at 0x401A61F: free (m_replacemalloc/vg_replace_malloc.c:323) ==2608==by 0x40F7464: su_free (su_alloc.c:838) ==2608==by 0x40A688F: nua_server_request_destroy (nua_stack.c:1504) ==2608==by 0x40BE3AE: process_ack (nua_session.c:2573) ==2608==by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2608==by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2608==by 0x408CAD3: incoming_ack (nta.c:6009) ==2608==by 0x40852BD: agent_recv_request (nta.c:2891) ==2608==by 0x4084478: agent_recv_message (nta.c:2722) ==2608==by 0x4111903: tport_base_deliver (tport.c:3013) ==2608==by 0x4111896: tport_deliver (tport.c:3002) ==2608==by 0x4111456: tport_parse (tport.c:2919) Further investigation showed other crashes in similar conditions, such as this one: ==2714== ==2714== Thread 11: ==2714== Invalid read of size 4 ==2714==at 0x40A67D3: nua_server_request_destroy (nua_stack.c:1488) ==2714==by 0x40BE3AE: process_ack (nua_session.c:2573) ==2714==by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2714==by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2714==by 0x408CAD3: incoming_ack (nta.c:6009) ==2714==by 0x40852BD: agent_recv_request (nta.c:2891) ==2714==by 0x4084478: agent_recv_message (nta.c:2722) ==2714==by 0x4111903: tport_base_deliver (tport.c:3013) ==2714==by 0x4111896: tport_deliver (tport.c:3002) ==2714==by 0x4111456: tport_parse (tport.c:2919) ==2714==by 0x401: tport_recv_event (tport.c:2861) ==2714==by 0x4110D7D: tport_base_wakeup (tport.c:2763) ==2714== Address 0x5451cb4 is 68 bytes inside a block of size 72 free'd ==2714==at 0x401A61F: free (m_replacemalloc/vg_replace_malloc.c:323) ==2714==by 0x40F7464: su_free (su_alloc.c:838) ==2714==by 0x40A688F: nua_server_request_destroy (nua_stack.c:1504) ==2714==by 0x40BB93A: nua_session_usage_shutdown (nua_session.c:1575) ==2714==by 0x40AC554: nua_dialog_usage_shutdown (nua_dialog.c:603) ==2714==by 0x40AA6DA: nua_base_client_response (nua_stack.c:3257) ==2714==by 0x40BA5BB: nua_session_client_response (nua_session.c:1007) ==2714==by 0x40B99FB: nua_invite_client_response (nua_session.c:865) ==2714==by 0x40A98D7: nua_client_response (nua_stack.c:2914) ==2714==by 0x40A9646: nua_client_return (nua_stack.c:2835) ==2714==by 0x40B931C: nua_invite_client_init (nua_session.c:745) ==2714==by 0x40A87DE: nua_client_init_request0 (nua_stack.c:2448) ==2714== ==2714== Invalid read of size 4 ==2714==at 0x40A67EE: nua_server_request_destroy (nua_stack.c:1491) ==2714==by 0x40BE3AE: process_ack (nua_session.c:2573) ==2714==by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2714==by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2714==by 0x408CAD3: incoming_ack (nta.c:6009) ==2714==by 0x40852BD: agent_recv_request (nta.c:2891) ==2714==by 0x4084478: agent_recv_message (nta.c:2722) ==2714==by 0x4111903: tport_base_deliver (tport.c:3013) ==2714==by 0x4111896: tport_deliver (tport.c:3002) ==2714==by 0x4111456: tport_parse (tport.c:2919) ==2714==by 0x401: tport_recv_event (tport.c:2861) ==2714==by
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-11-13 18:26 Message: What do you know, it works for me with the sofia-sip build we use in Maemo 5. Can somebody else confirm if it works with sofia-sip trunk? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-10-15 14:47 Message: > So, if the problem is with ekiga.net, has anyone contacted them about it yet? Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though. -- Comment By: Murray Cumming (murrayc) Date: 2009-10-13 08:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 16:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 12:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 20:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 15:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 21:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-10-15 14:47 Message: > So, if the problem is with ekiga.net, has anyone contacted them about it yet? Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though. -- Comment By: Murray Cumming (murrayc) Date: 2009-10-13 08:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 16:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 12:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 20:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 15:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 21:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 18:06 Message generated for change (Comment added) made by murrayc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Murray Cumming (murrayc) Date: 2009-10-13 05:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 13:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 09:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 18:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 19:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-2865716 ] Don't force the default CA file for TLS
Patches item #2865716, was opened at 2009-09-24 16:29 Message generated for change (Tracker Item Submitted) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2865716&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Don't force the default CA file for TLS Initial Comment: This patch removes the code that initializes the default CA file name for OpenSSL, if it is not set by the application. This causes TLS transport to fail if there is no such file available to the process. In Maemo 5 and other distributions, OpenSSL has the default CA path set up just fine, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2865716&group_id=143636 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-2865713 ] Deferrable timer fixes
Patches item #2865713, was opened at 2009-09-24 16:24 Message generated for change (Tracker Item Submitted) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2865713&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Deferrable timer fixes Initial Comment: >From the Maemo 5 branch: These patches fix a crash in deferrable timer processing for a GLib mainloop. Also, the NUA stack timer and the transport timer are set as deferrable. I hope this does not break anything :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2865713&group_id=143636 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-2858690 ] Fix an endless loop
Patches item #2858690, was opened at 2009-09-14 19:50 Message generated for change (Tracker Item Submitted) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2858690&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Fix an endless loop Initial Comment: There is a copy-and-paste error in an inner loop, causing an endless busy loop in some circumstances. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2858690&group_id=143636 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 16:54 Message: I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies. The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 12:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 20:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 15:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 21:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 18:06 Message generated for change (Comment added) made by riot69 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Andre Klapper (riot69) Date: 2009-04-09 09:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 18:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 19:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2625814 ] Assertion "b == bend" when calling nua_invite
Bugs item #2625814, was opened at 2009-02-21 23:52 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 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: None Group: None >Status: Closed Resolution: Works For Me Priority: 8 Private: No Submitted By: Silvo (silvo79) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion "b == bend" when calling nua_invite Initial Comment: Under (for me) non-deterministic circumstances a call of nua_invite ends up with the following output and the whole app crashes: nua: nua_invite: entering VCCenter: nua_stack.c:508: nua_signal: Assertion `b == bend' failed. Aborted -- >Comment By: SourceForge Robot (sf-robot) Date: 2009-03-18 18:56 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Pekka Pessi (ppessi) Date: 2009-02-26 22:52 Message: This usually indicates that nua_invite() arguments were fishy, either they point to uninitialized memory or they are changed during the call to nua_invite(). Running under valgrind or purify could show the culprit. Have a peek in tags passed to nua_invite() in debugger and post a backtrace if you think everything is OK... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 20:49 Message: It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 15:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 21:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 16:58 Message: The CNAME problem with proxy01.sipphone.com is still there with the recent trunk changes. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:34 Message: It breaks with proxy01.sipphone.com, too. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:05 Message: The patch regresses a case where SRV refers to a CNAME. Granted it's not allowed by strict DNS spec, but it used to work. telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._udp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._udp.sip1.cosmicparrot.net IN SRV 0 0 5063 sip1.cosmicparrot.net. (udp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._tcp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._tcp.sip1.cosmicparrot.net IN SRV 0 0 5062 sip1.cosmicparrot.net. (tcp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net" A (cached) telepathy-sofiasip[2040]: GLIB DEBUG default - tpsip_connection_sofia_callback: event nua_r_register: 503 DNS Error ;; QUESTION SECTION: ;sip1.cosmicparrot.net. IN A ;; ANSWER SECTION: sip1.cosmicparrot.net. 86400 IN CNAME svc.cosmicparrot.net. svc.cosmicparrot.net. 49472 IN A 217.152.255.16 -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 19:17 Message: Fri Jan 23 19:13:41 EET 2009 Pekka Pessi * sresolv: caching SRES_RECORD_ERR in case a CNAME is returned, too Tracing the CNAMEs when doing cache lookups. Misha, please verify. -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 18:18 Message: Looks like sres does not check that it got what it asked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2625814 ] Assertion "b == bend" when calling nua_invite
Bugs item #2625814, was opened at 2009-02-22 01:52 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 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: None Group: None >Status: Pending >Resolution: Works For Me Priority: 8 Private: No Submitted By: Silvo (silvo79) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion "b == bend" when calling nua_invite Initial Comment: Under (for me) non-deterministic circumstances a call of nua_invite ends up with the following output and the whole app crashes: nua: nua_invite: entering VCCenter: nua_stack.c:508: nua_signal: Assertion `b == bend' failed. Aborted -- >Comment By: Pekka Pessi (ppessi) Date: 2009-02-27 00:52 Message: This usually indicates that nua_invite() arguments were fishy, either they point to uninitialized memory or they are changed during the call to nua_invite(). Running under valgrind or purify could show the culprit. Have a peek in tags passed to nua_invite() in debugger and post a backtrace if you think everything is OK... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2625814 ] Assertion "b == bend" when calling nua_invite
Bugs item #2625814, was opened at 2009-02-22 00:52 Message generated for change (Settings changed) made by silvo79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 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: None Group: None Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Silvo (silvo79) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion "b == bend" when calling nua_invite Initial Comment: Under (for me) non-deterministic circumstances a call of nua_invite ends up with the following output and the whole app crashes: nua: nua_invite: entering VCCenter: nua_stack.c:508: nua_signal: Assertion `b == bend' failed. Aborted -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2625814 ] Assertion "b == bend" when calling nua_invite
Bugs item #2625814, was opened at 2009-02-22 00:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Silvo (silvo79) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion "b == bend" when calling nua_invite Initial Comment: Under (for me) non-deterministic circumstances a call of nua_invite ends up with the following output and the whole app crashes: nua: nua_invite: entering VCCenter: nua_stack.c:508: nua_signal: Assertion `b == bend' failed. Aborted -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2625814&group_id=143636 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:34 Message: It breaks with proxy01.sipphone.com, too. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:05 Message: The patch regresses a case where SRV refers to a CNAME. Granted it's not allowed by strict DNS spec, but it used to work. telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._udp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._udp.sip1.cosmicparrot.net IN SRV 0 0 5063 sip1.cosmicparrot.net. (udp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._tcp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._tcp.sip1.cosmicparrot.net IN SRV 0 0 5062 sip1.cosmicparrot.net. (tcp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net" A (cached) telepathy-sofiasip[2040]: GLIB DEBUG default - tpsip_connection_sofia_callback: event nua_r_register: 503 DNS Error ;; QUESTION SECTION: ;sip1.cosmicparrot.net. IN A ;; ANSWER SECTION: sip1.cosmicparrot.net. 86400 IN CNAME svc.cosmicparrot.net. svc.cosmicparrot.net. 49472 IN A 217.152.255.16 -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 19:17 Message: Fri Jan 23 19:13:41 EET 2009 Pekka Pessi * sresolv: caching SRES_RECORD_ERR in case a CNAME is returned, too Tracing the CNAMEs when doing cache lookups. Misha, please verify. -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 18:18 Message: Looks like sres does not check that it got what it asked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-02-04 20:05 Message: The patch regresses a case where SRV refers to a CNAME. Granted it's not allowed by strict DNS spec, but it used to work. telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._udp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._udp.sip1.cosmicparrot.net IN SRV 0 0 5063 sip1.cosmicparrot.net. (udp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "_sip._tcp.sip1.cosmicparrot.net" SRV telepathy-sofiasip[2040]: nta: _sip._tcp.sip1.cosmicparrot.net IN SRV 0 0 5062 sip1.cosmicparrot.net. (tcp) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net." A (cached) telepathy-sofiasip[2040]: nta: for "sip1.cosmicparrot.net" query "sip1.cosmicparrot.net" A (cached) telepathy-sofiasip[2040]: GLIB DEBUG default - tpsip_connection_sofia_callback: event nua_r_register: 503 DNS Error ;; QUESTION SECTION: ;sip1.cosmicparrot.net. IN A ;; ANSWER SECTION: sip1.cosmicparrot.net. 86400 IN CNAME svc.cosmicparrot.net. svc.cosmicparrot.net. 49472 IN A 217.152.255.16 -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 19:17 Message: Fri Jan 23 19:13:41 EET 2009 Pekka Pessi * sresolv: caching SRES_RECORD_ERR in case a CNAME is returned, too Tracing the CNAMEs when doing cache lookups. Misha, please verify. -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 18:18 Message: Looks like sres does not check that it got what it asked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2537240 ] _t namespace is reserved.
Bugs item #2537240, was opened at 2009-01-26 11:52 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2537240&group_id=143636 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: None Group: None >Status: Closed >Resolution: Later Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: _t namespace is reserved. Initial Comment: Hi, it would be nice to avoid the use of foo_t types, the "_t" namespace is reserved for POSIX symbols, so future extensions of POSIX may clobber with the symbols defined by sofia. -- >Comment By: Pekka Pessi (ppessi) Date: 2009-01-26 16:57 Message: This is what Kai V. said some 8 year ago. ;) Perhaps in 2.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2537240&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Feature Requests-2537671 ] Log sofia-sip modules through su_log()
Feature Requests item #2537671, was opened at 2009-01-26 13:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2537671&group_id=143636 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: None Group: None Status: Open Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: Log sofia-sip modules through su_log() Initial Comment: Currently sofia-sip only permits to log through a custom logger function only the messages issued by the su module, for the other messages there is the X_PORT/X_DEBUG/X_DUMP mechanism which uses environment variables to set for each module a distinct log file and level. Exporting in the public headers a su_log_t struct for each module (nua_log, tport_log, nth_log etc.) should make possible to define a logger for each one of the modules. This way should be possible to integrate the sofia logging facility (not only those related to the su module) into one's application log system. I'm still trying to undestand how to do that, but Pekka noted in the list that there could be some difficulties involving the exporting of arrays in the windows and symbian platforms. Anyway I think it would be a nice feature, I'll try to provide a patch eventually. Best regards. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2537671&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Feature Requests-2537249 ] Doxygenation in the headers.
Feature Requests item #2537249, was opened at 2009-01-26 09:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2537249&group_id=143636 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: None Group: None Status: Open Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: Doxygenation in the headers. Initial Comment: Hi, documentation for public functions/structures should stay in the headers, while currently the doxygenation is scattered amongst .h and .c files (often duplicated). It would be nice to clean this, having the doxygenation for sofia public symbols just in the headers. Thanks, regards. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2537249&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2537240 ] _t namespace is reserved.
Bugs item #2537240, was opened at 2009-01-26 09:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2537240&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: _t namespace is reserved. Initial Comment: Hi, it would be nice to avoid the use of foo_t types, the "_t" namespace is reserved for POSIX symbols, so future extensions of POSIX may clobber with the symbols defined by sofia. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2537240&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Settings changed) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- >Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 19:17 Message: Fri Jan 23 19:13:41 EET 2009 Pekka Pessi * sresolv: caching SRES_RECORD_ERR in case a CNAME is returned, too Tracing the CNAMEs when doing cache lookups. Misha, please verify. -- Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 18:18 Message: Looks like sres does not check that it got what it asked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) >Assigned to: Pekka Pessi (ppessi) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- >Comment By: Pekka Pessi (ppessi) Date: 2009-01-23 18:18 Message: Looks like sres does not check that it got what it asked. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results
Bugs item #2531152, was opened at 2009-01-23 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Does not cache some DNS results Initial Comment: In some circumstances, Sofia-SIP keeps requesting DNS records over and over again with every SIP request. See the attached log. Note also how NAPTR is requested repeatedly, even though nothing useful is obtained from the responses. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2531152&group_id=143636 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1904805 ] Build on Visual Studio 2005 with Platform SDK for Vista
Bugs item #1904805, was opened at 2008-02-29 16:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 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: build system Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Filippo Della Betta (fdellabetta) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Visual Studio 2005 with Platform SDK for Vista Initial Comment: There are some incompatibilities of sofia-sip when Windows SDK for Vista is installed (and integrated with Visual Studio 2005): 1) if not defined elsewhere, _WIN32_WINNT is 0x0600 (targeting Vista) and either inet_ntop and inet_pton are already defined in ws2tcpip.h (and therefore implemented in ws2_32.dll shipped with Windows Vista). My suggestion is to put something like #if defined (_WIN32_WINNT) && (_WIN32_WINNT < 0x0600) before declaration and definition of inet_ntop and inet_pton (in order to use inet_ntop and inet_pton of ws2_32.dll), or to re-define inet_ntop and inet_pton to other name when same condition occurs (in order to user internal implementation of inet_ntop and inet_pton) 2) IPPROTO_IPV6 is not anymore defined as a macro in Winsock2.h!! Now it has become an enum in ws2def.h (included by winsock2.h). Therefore #if(n)def IPPROTO_IPV6 doesn't work anymore especially in sresolv/sres.c. 3) in stun.c, stun_common.c, stun_mini.c there are warnings about getenv, srand, calloc, free, rand, malloc... undefined (and since warnings are treated as error you got compiler error). My suggestion is to put #if defined(HAVE_STDLIB_H) #include #endif in stun_internal.h 4) MSG_TRUNC is already defined in ws2def.h (included by winsock2.h). There is a compiler warning (an therefore error since warnings are treated as error) in tport_internal.h since MSG_TRUNC is redefined (the right value in Windows is 0x0100 not 0) -- >Comment By: SourceForge Robot (sf-robot) Date: 2008-12-13 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-28 15:02 Message: To be released in Sofia-SIP 1.12.10. -- Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-28 09:18 Message: You can close the bug, everything is ok now, Thanks -- Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-27 08:14 Message: The only problem I see now is on line 70 file su.h #if defined(IPPROTO_IPV6) || (_WIN32_WINNT >= 0x0600) that is incorrect since IPPROTO_IPV6 is not yet a #define, and _WIN32_WINNT >=0x0501 is better since means XP and later (>=0x0600 means Vista and later). If you are targeting XP and later you get, infact, an error since you are trying to include tpipv6.h that is useless. In the tarball you sent (and in the darcs as well), I found that there is a (minor) problem regarding line 2528 of file nua_session.c. There is a signed/unsigned mismatch and since warnings are threated as errors (flag /WX), the main projects do not compile. I tried it with msvc 2005 and 2008 -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 20:20 Message: Mike's patch last February 27th should have fixed these issues, however, I have not closed this bug. Please confirm if the current Darcs version or latest release candidate from http://sofia-sip.org/~ppessi/sofia-sip-1.12.9pre10rc1.tar.gz works with msvc 2005 and 2008. -- Comment By: Stefan Brozinski (sbmat) Date: 2008-11-24 15:29 Message: I kindly request to use Visual Studio 2008 instead of 2005 when addressing this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 15:17 Message: >The UA application must take care of the contact address by: >-Using some kind of STUN mechanism >- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 21:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:44 Message: The fix has been confirmed. Unfortunately, it does not solve the problem with ekiga.net. -- Comment By: Sjoerd Simons (ssimons) Date: 2008-12-08 14:03 Message: I've tried the attached patch, but it doesn't seem to help :( Some progress on this would be good as a lot of people would like to use empathy etc with ekiga.net... -- Comment By: Guillaume Desmottes (gdesmott) Date: 2008-12-04 23:45 Message: I can confirm this bug. I'm unable to login to ekiga.net using telepathy-sofiasip git master. -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 21:32 Message: Mikhaila's patch is available in darcs. -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 21:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 19:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. -
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Settings changed) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:44 Message: The fix has been confirmed. Unfortunately, it does not solve the problem with ekiga.net. -- Comment By: Sjoerd Simons (ssimons) Date: 2008-12-08 14:03 Message: I've tried the attached patch, but it doesn't seem to help :( Some progress on this would be good as a lot of people would like to use empathy etc with ekiga.net... -- Comment By: Guillaume Desmottes (gdesmott) Date: 2008-12-04 23:45 Message: I can confirm this bug. I'm unable to login to ekiga.net using telepathy-sofiasip git master. -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 21:32 Message: Mikhaila's patch is available in darcs. -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 21:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 19:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. --
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Comment added) made by incarose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- Comment By: Inca Rose (incarose) Date: 2008-12-09 21:48 Message: Why do you think this is a sofia-sip problem ? There is nothing wrong whit that. Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address. The UA application must take care of the contact address by: -Using some kind of STUN mechanism - Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER - or not taking care at all and failing to get incoming calls. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails
Bugs item #2412241, was opened at 2008-12-09 20:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 12:47 Message generated for change (Comment added) made by ssimons You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Sjoerd Simons (ssimons) Date: 2008-12-08 13:03 Message: I've tried the attached patch, but it doesn't seem to help :( Some progress on this would be good as a lot of people would like to use empathy etc with ekiga.net... -- Comment By: Guillaume Desmottes (gdesmott) Date: 2008-12-04 22:45 Message: I can confirm this bug. I'm unable to login to ekiga.net using telepathy-sofiasip git master. -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 20:32 Message: Mikhaila's patch is available in darcs. -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 20:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 18:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 19:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 16:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 14:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 14:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 10:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 ---
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 12:47 Message generated for change (Comment added) made by gdesmott You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Guillaume Desmottes (gdesmott) Date: 2008-12-04 22:45 Message: I can confirm this bug. I'm unable to login to ekiga.net using telepathy-sofiasip git master. -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 20:32 Message: Mikhaila's patch is available in darcs. -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 20:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 18:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 19:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 16:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 14:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 14:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 10:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___
[Sofia-sip-devel] [ sofia-sip-Bugs-1878039 ] Memory leak in handling of incoming ACK request
Bugs item #1878039, was opened at 2008-01-23 13:55
Message generated for change (Comment added) made by ppessi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1878039&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tirthankar Saha (tirthankarsaha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in handling of incoming ACK request
Initial Comment:
Valgrind reports leaks in a simple UAS application written using Sofia-NUA
library (1.12.7). One possible leak which has been noticed is in handling of
incoming ACK request for 2xx response.
Prelim analysis suggests that the memory home for the incoming ACK request is
not un-ref-ed (since it is not stored as separate irq object in any saved list)
Adding the following code block (delimited by PATCH_START comment in code
snippet below) at the end of nua_event() function in nua.c fixes the leak. This
may not be the proper fix.
/*# Receive event from protocol machine and hand it over to application */
void nua_event(nua_t *root_magic, su_msg_r sumsg, event_t *e)
{
nua_t *nua;
nua_handle_t *nh = e->e_nh;
enter;
e->e_nh = NULL;
if (nh) {
if (!nh->nh_ref_by_user && nh->nh_valid) {
nh->nh_ref_by_user = 1;
nua_handle_ref(nh);
}
}
if (!nh || !nh->nh_valid) { /* Handle has been destroyed */
if (nua_log->log_level >= 7) {
char const *name = nua_event_name(e->e_event) + 4;
SU_DEBUG_7(("nua(%p): event %s dropped\n", (void *)nh, name));
}
if (nh && !NH_IS_DEFAULT(nh) && nua_handle_unref(nh)) {
#if HAVE_NUA_HANDLE_DEBUG
SU_DEBUG_0(("nua(%p): freed by application\n", (void *)nh));
#else
SU_DEBUG_9(("nua(%p): freed by application\n", (void *)nh));
#endif
}
if (e->e_msg)
msg_destroy(e->e_msg), e->e_msg = NULL;
return;
}
nua = nh->nh_nua; assert(nua);
if (NH_IS_DEFAULT(nh))
nh = NULL;
if (e->e_event == nua_r_shutdown && e->e_status >= 200)
nua->nua_shutdown_final = 1;
if (nua->nua_callback) {
nua_event_frame_t frame[1];
su_msg_remove_refs(sumsg);/* Remove references to tasks */
su_msg_save(frame->nf_saved, sumsg);
frame->nf_nua = nua;
frame->nf_next = nua->nua_current, nua->nua_current = frame;
nua->nua_callback(e->e_event, e->e_status, e->e_phrase,
nua, nua->nua_magic,
nh, nh ? nh->nh_magic : NULL,
e->e_msg ? sip_object(e->e_msg) : NULL,
e->e_tags);
su_msg_destroy(frame->nf_saved);
if (frame->nf_nua == NULL)
return;
nua->nua_current = frame->nf_next;
}
/* __PATCH_START__ */
if (e && e->e_msg && e->e_event == nua_i_ack)
{
/*specific for ACK event*/
su_home_unref(msg_home(e->e_msg));
}
/* __PATCH_END__ */
if (nh && nua_handle_unref(nh)) {
#if HAVE_NUA_HANDLE_DEBUG
SU_DEBUG_0(("nua(%p): freed by application\n", (void *)nh));
#else
SU_DEBUG_9(("nua(%p): freed by application\n", (void *)nh));
#endif
}
}
--
Comment By: Pekka Pessi (ppessi)
Date: 2008-12-03 15:19
Message:
Looks like this has been fixed already in 1.12.9.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1878039&group_id=143636
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1904805 ] Build on Visual Studio 2005 with Platform SDK for Vista
Bugs item #1904805, was opened at 2008-02-29 18:37 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 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: build system Group: None >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Filippo Della Betta (fdellabetta) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Visual Studio 2005 with Platform SDK for Vista Initial Comment: There are some incompatibilities of sofia-sip when Windows SDK for Vista is installed (and integrated with Visual Studio 2005): 1) if not defined elsewhere, _WIN32_WINNT is 0x0600 (targeting Vista) and either inet_ntop and inet_pton are already defined in ws2tcpip.h (and therefore implemented in ws2_32.dll shipped with Windows Vista). My suggestion is to put something like #if defined (_WIN32_WINNT) && (_WIN32_WINNT < 0x0600) before declaration and definition of inet_ntop and inet_pton (in order to use inet_ntop and inet_pton of ws2_32.dll), or to re-define inet_ntop and inet_pton to other name when same condition occurs (in order to user internal implementation of inet_ntop and inet_pton) 2) IPPROTO_IPV6 is not anymore defined as a macro in Winsock2.h!! Now it has become an enum in ws2def.h (included by winsock2.h). Therefore #if(n)def IPPROTO_IPV6 doesn't work anymore especially in sresolv/sres.c. 3) in stun.c, stun_common.c, stun_mini.c there are warnings about getenv, srand, calloc, free, rand, malloc... undefined (and since warnings are treated as error you got compiler error). My suggestion is to put #if defined(HAVE_STDLIB_H) #include #endif in stun_internal.h 4) MSG_TRUNC is already defined in ws2def.h (included by winsock2.h). There is a compiler warning (an therefore error since warnings are treated as error) in tport_internal.h since MSG_TRUNC is redefined (the right value in Windows is 0x0100 not 0) -- >Comment By: Pekka Pessi (ppessi) Date: 2008-11-28 17:02 Message: To be released in Sofia-SIP 1.12.10. -- Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-28 11:18 Message: You can close the bug, everything is ok now, Thanks -- Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-27 10:14 Message: The only problem I see now is on line 70 file su.h #if defined(IPPROTO_IPV6) || (_WIN32_WINNT >= 0x0600) that is incorrect since IPPROTO_IPV6 is not yet a #define, and _WIN32_WINNT >=0x0501 is better since means XP and later (>=0x0600 means Vista and later). If you are targeting XP and later you get, infact, an error since you are trying to include tpipv6.h that is useless. In the tarball you sent (and in the darcs as well), I found that there is a (minor) problem regarding line 2528 of file nua_session.c. There is a signed/unsigned mismatch and since warnings are threated as errors (flag /WX), the main projects do not compile. I tried it with msvc 2005 and 2008 -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 22:20 Message: Mike's patch last February 27th should have fixed these issues, however, I have not closed this bug. Please confirm if the current Darcs version or latest release candidate from http://sofia-sip.org/~ppessi/sofia-sip-1.12.9pre10rc1.tar.gz works with msvc 2005 and 2008. -- Comment By: Stefan Brozinski (sbmat) Date: 2008-11-24 17:29 Message: I kindly request to use Visual Studio 2008 instead of 2005 when addressing this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1904805 ] Build on Visual Studio 2005 with Platform SDK for Vista
Bugs item #1904805, was opened at 2008-02-29 17:37 Message generated for change (Comment added) made by fdellabetta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 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: build system Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Filippo Della Betta (fdellabetta) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Visual Studio 2005 with Platform SDK for Vista Initial Comment: There are some incompatibilities of sofia-sip when Windows SDK for Vista is installed (and integrated with Visual Studio 2005): 1) if not defined elsewhere, _WIN32_WINNT is 0x0600 (targeting Vista) and either inet_ntop and inet_pton are already defined in ws2tcpip.h (and therefore implemented in ws2_32.dll shipped with Windows Vista). My suggestion is to put something like #if defined (_WIN32_WINNT) && (_WIN32_WINNT < 0x0600) before declaration and definition of inet_ntop and inet_pton (in order to use inet_ntop and inet_pton of ws2_32.dll), or to re-define inet_ntop and inet_pton to other name when same condition occurs (in order to user internal implementation of inet_ntop and inet_pton) 2) IPPROTO_IPV6 is not anymore defined as a macro in Winsock2.h!! Now it has become an enum in ws2def.h (included by winsock2.h). Therefore #if(n)def IPPROTO_IPV6 doesn't work anymore especially in sresolv/sres.c. 3) in stun.c, stun_common.c, stun_mini.c there are warnings about getenv, srand, calloc, free, rand, malloc... undefined (and since warnings are treated as error you got compiler error). My suggestion is to put #if defined(HAVE_STDLIB_H) #include #endif in stun_internal.h 4) MSG_TRUNC is already defined in ws2def.h (included by winsock2.h). There is a compiler warning (an therefore error since warnings are treated as error) in tport_internal.h since MSG_TRUNC is redefined (the right value in Windows is 0x0100 not 0) -- >Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-28 10:18 Message: You can close the bug, everything is ok now, Thanks -- Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-27 09:14 Message: The only problem I see now is on line 70 file su.h #if defined(IPPROTO_IPV6) || (_WIN32_WINNT >= 0x0600) that is incorrect since IPPROTO_IPV6 is not yet a #define, and _WIN32_WINNT >=0x0501 is better since means XP and later (>=0x0600 means Vista and later). If you are targeting XP and later you get, infact, an error since you are trying to include tpipv6.h that is useless. In the tarball you sent (and in the darcs as well), I found that there is a (minor) problem regarding line 2528 of file nua_session.c. There is a signed/unsigned mismatch and since warnings are threated as errors (flag /WX), the main projects do not compile. I tried it with msvc 2005 and 2008 -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 21:20 Message: Mike's patch last February 27th should have fixed these issues, however, I have not closed this bug. Please confirm if the current Darcs version or latest release candidate from http://sofia-sip.org/~ppessi/sofia-sip-1.12.9pre10rc1.tar.gz works with msvc 2005 and 2008. -- Comment By: Stefan Brozinski (sbmat) Date: 2008-11-24 16:29 Message: I kindly request to use Visual Studio 2008 instead of 2005 when addressing this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1904805 ] Build on Visual Studio 2005 with Platform SDK for Vista
Bugs item #1904805, was opened at 2008-02-29 17:37 Message generated for change (Comment added) made by fdellabetta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 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: build system Group: None >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Filippo Della Betta (fdellabetta) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Visual Studio 2005 with Platform SDK for Vista Initial Comment: There are some incompatibilities of sofia-sip when Windows SDK for Vista is installed (and integrated with Visual Studio 2005): 1) if not defined elsewhere, _WIN32_WINNT is 0x0600 (targeting Vista) and either inet_ntop and inet_pton are already defined in ws2tcpip.h (and therefore implemented in ws2_32.dll shipped with Windows Vista). My suggestion is to put something like #if defined (_WIN32_WINNT) && (_WIN32_WINNT < 0x0600) before declaration and definition of inet_ntop and inet_pton (in order to use inet_ntop and inet_pton of ws2_32.dll), or to re-define inet_ntop and inet_pton to other name when same condition occurs (in order to user internal implementation of inet_ntop and inet_pton) 2) IPPROTO_IPV6 is not anymore defined as a macro in Winsock2.h!! Now it has become an enum in ws2def.h (included by winsock2.h). Therefore #if(n)def IPPROTO_IPV6 doesn't work anymore especially in sresolv/sres.c. 3) in stun.c, stun_common.c, stun_mini.c there are warnings about getenv, srand, calloc, free, rand, malloc... undefined (and since warnings are treated as error you got compiler error). My suggestion is to put #if defined(HAVE_STDLIB_H) #include #endif in stun_internal.h 4) MSG_TRUNC is already defined in ws2def.h (included by winsock2.h). There is a compiler warning (an therefore error since warnings are treated as error) in tport_internal.h since MSG_TRUNC is redefined (the right value in Windows is 0x0100 not 0) -- >Comment By: Filippo Della Betta (fdellabetta) Date: 2008-11-27 09:14 Message: The only problem I see now is on line 70 file su.h #if defined(IPPROTO_IPV6) || (_WIN32_WINNT >= 0x0600) that is incorrect since IPPROTO_IPV6 is not yet a #define, and _WIN32_WINNT >=0x0501 is better since means XP and later (>=0x0600 means Vista and later). If you are targeting XP and later you get, infact, an error since you are trying to include tpipv6.h that is useless. In the tarball you sent (and in the darcs as well), I found that there is a (minor) problem regarding line 2528 of file nua_session.c. There is a signed/unsigned mismatch and since warnings are threated as errors (flag /WX), the main projects do not compile. I tried it with msvc 2005 and 2008 -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 21:20 Message: Mike's patch last February 27th should have fixed these issues, however, I have not closed this bug. Please confirm if the current Darcs version or latest release candidate from http://sofia-sip.org/~ppessi/sofia-sip-1.12.9pre10rc1.tar.gz works with msvc 2005 and 2008. -- Comment By: Stefan Brozinski (sbmat) Date: 2008-11-24 16:29 Message: I kindly request to use Visual Studio 2008 instead of 2005 when addressing this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1904805 ] Build on Visual Studio 2005 with Platform SDK for Vista
Bugs item #1904805, was opened at 2008-02-29 18:37 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 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: build system Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Filippo Della Betta (fdellabetta) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Visual Studio 2005 with Platform SDK for Vista Initial Comment: There are some incompatibilities of sofia-sip when Windows SDK for Vista is installed (and integrated with Visual Studio 2005): 1) if not defined elsewhere, _WIN32_WINNT is 0x0600 (targeting Vista) and either inet_ntop and inet_pton are already defined in ws2tcpip.h (and therefore implemented in ws2_32.dll shipped with Windows Vista). My suggestion is to put something like #if defined (_WIN32_WINNT) && (_WIN32_WINNT < 0x0600) before declaration and definition of inet_ntop and inet_pton (in order to use inet_ntop and inet_pton of ws2_32.dll), or to re-define inet_ntop and inet_pton to other name when same condition occurs (in order to user internal implementation of inet_ntop and inet_pton) 2) IPPROTO_IPV6 is not anymore defined as a macro in Winsock2.h!! Now it has become an enum in ws2def.h (included by winsock2.h). Therefore #if(n)def IPPROTO_IPV6 doesn't work anymore especially in sresolv/sres.c. 3) in stun.c, stun_common.c, stun_mini.c there are warnings about getenv, srand, calloc, free, rand, malloc... undefined (and since warnings are treated as error you got compiler error). My suggestion is to put #if defined(HAVE_STDLIB_H) #include #endif in stun_internal.h 4) MSG_TRUNC is already defined in ws2def.h (included by winsock2.h). There is a compiler warning (an therefore error since warnings are treated as error) in tport_internal.h since MSG_TRUNC is redefined (the right value in Windows is 0x0100 not 0) -- >Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 22:20 Message: Mike's patch last February 27th should have fixed these issues, however, I have not closed this bug. Please confirm if the current Darcs version or latest release candidate from http://sofia-sip.org/~ppessi/sofia-sip-1.12.9pre10rc1.tar.gz works with msvc 2005 and 2008. -- Comment By: Stefan Brozinski (sbmat) Date: 2008-11-24 17:29 Message: I kindly request to use Visual Studio 2008 instead of 2005 when addressing this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Pekka Pessi (ppessi) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- >Comment By: Pekka Pessi (ppessi) Date: 2008-11-26 21:32 Message: Mikhaila's patch is available in darcs. -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 21:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 19:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Settings changed) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) >Assigned to: Pekka Pessi (ppessi) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 21:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 19:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1904805 ] Build on Visual Studio 2005 with Platform SDK for Vista
Bugs item #1904805, was opened at 2008-02-29 17:37 Message generated for change (Comment added) made by sbmat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 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: build system Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Filippo Della Betta (fdellabetta) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Visual Studio 2005 with Platform SDK for Vista Initial Comment: There are some incompatibilities of sofia-sip when Windows SDK for Vista is installed (and integrated with Visual Studio 2005): 1) if not defined elsewhere, _WIN32_WINNT is 0x0600 (targeting Vista) and either inet_ntop and inet_pton are already defined in ws2tcpip.h (and therefore implemented in ws2_32.dll shipped with Windows Vista). My suggestion is to put something like #if defined (_WIN32_WINNT) && (_WIN32_WINNT < 0x0600) before declaration and definition of inet_ntop and inet_pton (in order to use inet_ntop and inet_pton of ws2_32.dll), or to re-define inet_ntop and inet_pton to other name when same condition occurs (in order to user internal implementation of inet_ntop and inet_pton) 2) IPPROTO_IPV6 is not anymore defined as a macro in Winsock2.h!! Now it has become an enum in ws2def.h (included by winsock2.h). Therefore #if(n)def IPPROTO_IPV6 doesn't work anymore especially in sresolv/sres.c. 3) in stun.c, stun_common.c, stun_mini.c there are warnings about getenv, srand, calloc, free, rand, malloc... undefined (and since warnings are treated as error you got compiler error). My suggestion is to put #if defined(HAVE_STDLIB_H) #include #endif in stun_internal.h 4) MSG_TRUNC is already defined in ws2def.h (included by winsock2.h). There is a compiler warning (an therefore error since warnings are treated as error) in tport_internal.h since MSG_TRUNC is redefined (the right value in Windows is 0x0100 not 0) -- Comment By: Stefan Brozinski (sbmat) Date: 2008-11-24 16:29 Message: I kindly request to use Visual Studio 2008 instead of 2005 when addressing this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1904805&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 03:47 Message generated for change (Comment added) made by jbrnd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Johan Brannlund (jbrnd) Date: 2008-11-16 11:49 Message: In the thread http://comments.gmane.org/gmane.comp.freedesktop.telepathy/2115 , Mikhail Zabaluev said that not being able to log into ekiga.net with Empathy is due to this bug. If that's really the case, then this bug is not fixed. I'm running Empathy on Ubuntu 8.10 which has sofiasip 1.12.9 and I still can't login (actually, this used to work with older versions). -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 09:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 11:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 07:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 05:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 05:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 01:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Settings changed) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None >Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 19:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2270819 ] Automatic NOTIFY uses stale handle
Bugs item #2270819, was opened at 2008-11-12 19:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2270819&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Automatic NOTIFY uses stale handle Initial Comment: The nua handle gets recycled and reference counting fails if a NOTIFY is generated by a stack after handle is destroyed. -- Due to a slightly non-standard SIP flow in an attended transfer implementation I encountered, I've found a way to crash the Sofia stack. It's a race condition, and is difficult to reproduce, but I can usually get it to happen after about an hour of execution on our test system here. I am willing to run some tests of fixes on our set-up here, if need be. I have the transferer and transferee running on the same host, sharing the same Sofia nua stack instance. The transfer destination is running on another host. The transferee's handle for its dialog with the transferer is getting deallocated (ref count reaches zero) while it is still on the handle list. The deallocation memsets the entire handle to 0xaa. The next time nua_stack_timer runs, it calls nh_call_pending for the deallocated handle, which dereferences a pointer found inside the handle, and BOOM! I get a bus error due to an unaligned memory address access (it's trying to load a 32-bit word from 0x + 0x20). Further investigation shows that the stack is getting into this situation as follows: 1. Transferer has sent INVITE to transfer destination and received a 100 Trying and 180 Ringing, but transfer destination hasn't answered the call. 2. Transferer sends REFER to transferee, immediately followed by a BYE (This is the non-"standard" part. The transferer should really be waiting to send the BYE when it gets the NOTIFY [200 OK]). 3. Transferee receives the REFER and sends an INVITE to the transfer destination (starts dialog D3). 4. Transferee receives BYE indications, etc., with the last being a "Terminated" from Sofia for D1, which the transferee responds to by calling nua_handle_destroy. 5. Transferee's nua "protocol thread" processes an r_destroy signal for D1's handle, thereby removing that handle from the handle list. 6. Transfer destination sends 100 Trying and 180 Ringing to transferee for D3. 7. Transferee's nua "protocol thread" processes an r_notify signal in nua_stack_signal. At line 549, in nua_stack.c, the handle is seen to not be on the handle list, and is added back onto the list. 8. 180 Ringing arrives for D3 from the transfer destination just as the transferee hangs up (calls nua_bye for) D3, because the automated test system ended the call. 9. Transferee receives a bunch of indications from nua for D3 (as a result of receiving the 487 Request Terminated), the last of which is a "Terminated" indication. The transferee responds to the "Terminated" indication by calling nua_handle_destroy for D3's handle. 10. Transferee's nua "protocol thread" processes an r_notify signal for D1's handle. The handle is unrefd, and the ref count reaches zero. The handle is deallocated, but it's still on the handle list. Of course, the next time the timer expires and runs nua_stack_timer, the handle list is traversed, and my thread catches the SIGBUS to hell. ;) It seems like the NOTIFY code needs to remove the handle from the handle list when the subscription terminates, but I don't really know what I'm talking about here. Maybe there's some other reason why the handle needs to remain on the handle list, in which case, there must be a missing call to nua_handle_ref somewhere. I have a workaround that I'm testing right now. I've changed the transferee such that it waits until after D3 has either become active or terminated before it calls nua_destroy_handle for the terminated dialog D1. This seems to be working, but I'll run it for a few days to be sure. Cheers. --Jen -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2270819&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event an
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Comment added) made by ppessi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- >Comment By: Pekka Pessi (ppessi) Date: 2008-11-12 19:41 Message: Fixed in 1.12.9. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Feature Requests-2206064 ] apply 'APPL_METHOD' on "CANCEL"
Feature Requests item #2206064, was opened at 2008-10-29 09:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2206064&group_id=143636 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: None Group: None Status: Open Priority: 5 Private: No Submitted By: kandy yang (heaventear) Assigned to: Nobody/Anonymous (nobody) Summary: apply 'APPL_METHOD' on "CANCEL" Initial Comment: Current sofia stack responds automatically with 200OK to CANCEL, and then 487 after that. I propose to make it more flexible so that application programmer could control the behavior or insert new TAG parameters. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2206064&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Feature Requests-2204637 ] Dialog should stick to one remote transport address
Feature Requests item #2204637, was opened at 2008-10-28 18:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2204637&group_id=143636 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: None Group: None Status: Open Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Dialog should stick to one remote transport address Initial Comment: In some cases there are several request destination addresses available for a target URL, such as when an SRV lookup returns entries of the same priority. Requests in a dialog should stick to one transport address chosen for the initial request. This prevents confusion on the server side, where the alternative proxies often know nothing about each other's dialogs. This also applies to resubmissions of INVITE requests after an authentication challenge. If authentication responses are fanned around multiple proxies which know nothing of each other's challenges, the number of steps needed to make the authentication succeed is not deterministic. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2204637&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None >Status: Open >Resolution: None >Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-10-27 20:15 Message: There is a patch in Darcs mainline (searchable by this bug ID) that had the fix for the problem. Unfortunately, it was an overkill, so now even those contacts get submitted with expires=0 which were never successfully registered. This breaks registration with proxies that dislike the unsuccessful contact (e.g. for being in a private IP address segment), even if it has expired. Reopening because the requirement for "successful" registration in the bug description was not met. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2116555 ] Memory corruption in test_nta
Bugs item #2116555, was opened at 2008-09-17 20:39 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2116555&group_id=143636 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: None Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Memory corruption in test_nta Initial Comment: Sometimes test_nta crashes with the following backtrace in my Maemo scratchbox for x86: (gdb) bt #0 0xb7d71314 in free () from /lib/libc.so.6 #1 0x080d4574 in _su_home_deinit (home=0x8148f38) at su_alloc.c:1016 #2 0x080d39b5 in su_home_unref (home=0x8148f38) at su_alloc.c:679 #3 0x080c043d in msg_destroy (msg=0x8148f38) at msg.c:168 #4 0x08086d8c in outgoing_reclaim (orq=0x8149928) at nta.c:7953 #5 0x08086aa2 in outgoing_free (orq=0x8149928) at nta.c:7912 #6 0x08071b87 in nta_agent_destroy (agent=0x80feb30) at nta.c:573 #7 0x08053d8a in test_deinit (ag=0xbfc3380c) at test_nta.c:782 #8 0x0806fe42 in main (argc=1, argv=0xbfc339a4) at test_nta.c:3954 (gdb) frame 1 #1 0x080d4574 in _su_home_deinit (home=0x8148f38) at su_alloc.c:1016 1016 free(b->sub_stats); Retraced to just before freeing, the data under the pointer look like garbage. Valgrind dumps earlier, with a possible culprit: ==15537== Access not within mapped region at address 0xAC16 ==15537==at 0x8086BCF: outgoing_htable_remove (nta.c:6470) ==15537==by 0x8086B00: outgoing_cut_off (nta.c:7925) ==15537==by 0x8086A93: outgoing_free (nta.c:7911) ==15537==by 0x8086F0C: outgoing_destroy (nta.c:8003) ==15537==by 0x8083DCC: nta_outgoing_destroy (nta.c:6887) ==15537==by 0x8066DE2: invite_client_deinit (test_nta.c:2878) ==15537==by 0x80514F5: client_deinit (test_nta.c:443) ==15537==by 0x805164B: client_run_with (test_nta.c:479) ==15537==by 0x80518E4: client_run_until_acked (test_nta.c:521) ==15537==by 0x806B985: test_prack (test_nta.c:3434) ==15537==by 0x806FDBA: main (test_nta.c:3951) -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-09-18 14:50 Message: The test doesn't fail in the latest trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2116555&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2116555 ] Memory corruption in test_nta
Bugs item #2116555, was opened at 2008-09-17 20:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2116555&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Memory corruption in test_nta Initial Comment: Sometimes test_nta crashes with the following backtrace in my Maemo scratchbox for x86: (gdb) bt #0 0xb7d71314 in free () from /lib/libc.so.6 #1 0x080d4574 in _su_home_deinit (home=0x8148f38) at su_alloc.c:1016 #2 0x080d39b5 in su_home_unref (home=0x8148f38) at su_alloc.c:679 #3 0x080c043d in msg_destroy (msg=0x8148f38) at msg.c:168 #4 0x08086d8c in outgoing_reclaim (orq=0x8149928) at nta.c:7953 #5 0x08086aa2 in outgoing_free (orq=0x8149928) at nta.c:7912 #6 0x08071b87 in nta_agent_destroy (agent=0x80feb30) at nta.c:573 #7 0x08053d8a in test_deinit (ag=0xbfc3380c) at test_nta.c:782 #8 0x0806fe42 in main (argc=1, argv=0xbfc339a4) at test_nta.c:3954 (gdb) frame 1 #1 0x080d4574 in _su_home_deinit (home=0x8148f38) at su_alloc.c:1016 1016 free(b->sub_stats); Retraced to just before freeing, the data under the pointer look like garbage. Valgrind dumps earlier, with a possible culprit: ==15537== Access not within mapped region at address 0xAC16 ==15537==at 0x8086BCF: outgoing_htable_remove (nta.c:6470) ==15537==by 0x8086B00: outgoing_cut_off (nta.c:7925) ==15537==by 0x8086A93: outgoing_free (nta.c:7911) ==15537==by 0x8086F0C: outgoing_destroy (nta.c:8003) ==15537==by 0x8083DCC: nta_outgoing_destroy (nta.c:6887) ==15537==by 0x8066DE2: invite_client_deinit (test_nta.c:2878) ==15537==by 0x80514F5: client_deinit (test_nta.c:443) ==15537==by 0x805164B: client_run_with (test_nta.c:479) ==15537==by 0x80518E4: client_run_until_acked (test_nta.c:521) ==15537==by 0x806B985: test_prack (test_nta.c:3434) ==15537==by 0x806FDBA: main (test_nta.c:3951) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2116555&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2041747 ] SIPTAG_ORGANIZATION_TAG_STR crash
Bugs item #2041747, was opened at 2008-08-07 17:19
Message generated for change (Comment added) made by ppessi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2041747&group_id=143636
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: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Stefano Sabatini (stesaba)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIPTAG_ORGANIZATION_TAG_STR crash
Initial Comment:
Hi dear libsofia devs,
this bug seems related to the use of the SIPTAG_ORGANIZATION_STR() in
nua_invite(), after the incoming BYE it crashes.
This is what gdb tells:
nua: nua_application_event: entering
Arrived event number 6
I have received the event nua_i_active with status 200: Call active
tport_wakeup_pri(0x804d778): events IN
tport_recv_event(0x804d778)
tport_recv_iovec(0x804d778) msg 0x8053cd8 from (udp/10.88.3.67:5060) has 391
bytes, veclen = 1
tport_deliver(0x804d778): msg 0x8053cd8 (391 bytes) from
udp/10.88.3.204:5060/sip next=(nil)
nta: received BYE sip:10.xx.x.67 SIP/2.0 (CSeq 708415049)
nta: canonizing sip:10.xx.x.67 with contact
nta: BYE (708415049) going to existing leg
nua: nua_stack_process_request: entering
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b54b90 (LWP 31017)]
0xb7edd771 in msg_hclass_offset (mc=0xb7fd1f80, mo=0x8054ac4, hc=0x75706552) at
msg_parser.c:2475
(gdb) bt
#0 0xb7edd771 in msg_hclass_offset (mc=0xb7fd1f80, mo=0x8054ac4,
hc=0x75706552) at msg_parser.c:2475
#1 0xb7edda6c in msg_header_add_dup (msg=0x8054a28, pub=0x8054ac4,
src=0x804f0e0) at msg_parser.c:2567
#2 0xb7f45dee in sip_add_dup (msg=0x8054a28, sip=0x8054ac4, o=0x804f0e0) at
sip_header.c:119
#3 0xb7f18e1a in nua_server_respond (sr=0xb7b53d68, tags=0x0) at
nua_stack.c:1718
#4 0xb7f185d5 in nua_stack_process_request (nh=0x804ef08, leg=0x804d940,
irq=0x80543f8, sip=0x8053d74) at nua_stack.c:1459
#5 0xb7efcbd1 in incoming_callback (leg=0x804d940, irq=0x80543f8,
sip=0x8053d74) at nta.c:4857
#6 0xb7efb220 in leg_recv (leg=0x804d940, msg=0x8053cd8, sip=0x8053d74,
tport=0x804d778) at nta.c:4174
#7 0xb7ef5c3a in agent_recv_request (agent=0x804c308, msg=0x8053cd8,
sip=0x8053d74, tport=0x804d778) at nta.c:2463
#8 0xb7ef4776 in agent_recv_message (agent=0x804c308, tport=0x804d778,
msg=0x8053cd8, tport_via=0x804ea80, now={tv_sec = 3427107229, tv_usec =
100484}) at nta.c:2244
#9 0xb7f879fa in tport_base_deliver (self=0x804d778, msg=0x8053cd8,
now={tv_sec = 3427107229, tv_usec = 100484}) at tport.c:3013
#10 0xb7f8798d in tport_deliver (self=0x804d778, msg=0x8053cd8, next=0x0,
sc=0x0, now={tv_sec = 3427107229, tv_usec = 100484}) at tport.c:3002
#11 0xb7f874a8 in tport_parse (self=0x804d778, complete=1, now={tv_sec =
3427107229, tv_usec = 100484}) at tport.c:2919
#12 0xb7f87178 in tport_recv_event (self=0x804d778) at tport.c:2861
#13 0xb7f86deb in tport_base_wakeup (self=0x804d778, events=1) at tport.c:2763
#14 0xb7f86b81 in tport_wakeup_pri (m=0x804b4b8, w=0x804baa0, self=0x804d778)
at tport.c:2726
#15 0xb7f76331 in su_epoll_port_wait_events (self=0x804b790, tout=1000) at
su_epoll_port.c:506
#16 0xb7f72d6b in su_base_port_run (self=0x804b790) at su_base_port.c:342
#17 0xb7f6fc69 in su_port_run (self=0x804b790) at su_port.h:310
#18 0xb7f6fc46 in su_root_run (self=0x804bc18) at su_root.c:689
#19 0xb7f73841 in su_pthread_port_clone_main (varg=0xbf959eec) at
su_pthread_port.c:321
#20 0xb7b754fb in start_thread () from /lib/i686/cmov/libpthread.so.0
#21 0xb7df7d7e in clone () from /lib/i686/cmov/libc.so.6
(gdb) f 0
#0 0xb7edd771 in msg_hclass_offset (mc=0xb7fd1f80, mo=0x8054ac4,
hc=0x75706552) at msg_parser.c:2475
(gdb) p *mc->mc_hash_size
Cannot access memory at address 0x7f
(gdb) p mc->mc_hash_size
$14 = 127
(gdb) p hc
$15 = (const struct msg_hclass_s *) 0x75706552
(gdb) p *hc
Cannot access memory at address 0x75706552
If I put the same TAG in nua_create then the application crashes immediately.
I'm attaching the simple application which reproduces the issue.
Regards.
--
>Comment By: Pekka Pessi (ppessi)
Date: 2008-08-08 15:11
Message:
Logged In: YES
user_id=52043
Originator: NO
Fixed in darcs. Thanks for reporting this.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2041747&group_id=143636
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
htt
[Sofia-sip-devel] [ sofia-sip-Bugs-2041747 ] SIPTAG_ORGANIZATION_TAG_STR crash
Bugs item #2041747, was opened at 2008-08-07 14:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2041747&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stefano Sabatini (stesaba)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIPTAG_ORGANIZATION_TAG_STR crash
Initial Comment:
Hi dear libsofia devs,
this bug seems related to the use of the SIPTAG_ORGANIZATION_STR() in
nua_invite(), after the incoming BYE it crashes.
This is what gdb tells:
nua: nua_application_event: entering
Arrived event number 6
I have received the event nua_i_active with status 200: Call active
tport_wakeup_pri(0x804d778): events IN
tport_recv_event(0x804d778)
tport_recv_iovec(0x804d778) msg 0x8053cd8 from (udp/10.88.3.67:5060) has 391
bytes, veclen = 1
tport_deliver(0x804d778): msg 0x8053cd8 (391 bytes) from
udp/10.88.3.204:5060/sip next=(nil)
nta: received BYE sip:10.xx.x.67 SIP/2.0 (CSeq 708415049)
nta: canonizing sip:10.xx.x.67 with contact
nta: BYE (708415049) going to existing leg
nua: nua_stack_process_request: entering
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b54b90 (LWP 31017)]
0xb7edd771 in msg_hclass_offset (mc=0xb7fd1f80, mo=0x8054ac4, hc=0x75706552) at
msg_parser.c:2475
(gdb) bt
#0 0xb7edd771 in msg_hclass_offset (mc=0xb7fd1f80, mo=0x8054ac4,
hc=0x75706552) at msg_parser.c:2475
#1 0xb7edda6c in msg_header_add_dup (msg=0x8054a28, pub=0x8054ac4,
src=0x804f0e0) at msg_parser.c:2567
#2 0xb7f45dee in sip_add_dup (msg=0x8054a28, sip=0x8054ac4, o=0x804f0e0) at
sip_header.c:119
#3 0xb7f18e1a in nua_server_respond (sr=0xb7b53d68, tags=0x0) at
nua_stack.c:1718
#4 0xb7f185d5 in nua_stack_process_request (nh=0x804ef08, leg=0x804d940,
irq=0x80543f8, sip=0x8053d74) at nua_stack.c:1459
#5 0xb7efcbd1 in incoming_callback (leg=0x804d940, irq=0x80543f8,
sip=0x8053d74) at nta.c:4857
#6 0xb7efb220 in leg_recv (leg=0x804d940, msg=0x8053cd8, sip=0x8053d74,
tport=0x804d778) at nta.c:4174
#7 0xb7ef5c3a in agent_recv_request (agent=0x804c308, msg=0x8053cd8,
sip=0x8053d74, tport=0x804d778) at nta.c:2463
#8 0xb7ef4776 in agent_recv_message (agent=0x804c308, tport=0x804d778,
msg=0x8053cd8, tport_via=0x804ea80, now={tv_sec = 3427107229, tv_usec =
100484}) at nta.c:2244
#9 0xb7f879fa in tport_base_deliver (self=0x804d778, msg=0x8053cd8,
now={tv_sec = 3427107229, tv_usec = 100484}) at tport.c:3013
#10 0xb7f8798d in tport_deliver (self=0x804d778, msg=0x8053cd8, next=0x0,
sc=0x0, now={tv_sec = 3427107229, tv_usec = 100484}) at tport.c:3002
#11 0xb7f874a8 in tport_parse (self=0x804d778, complete=1, now={tv_sec =
3427107229, tv_usec = 100484}) at tport.c:2919
#12 0xb7f87178 in tport_recv_event (self=0x804d778) at tport.c:2861
#13 0xb7f86deb in tport_base_wakeup (self=0x804d778, events=1) at tport.c:2763
#14 0xb7f86b81 in tport_wakeup_pri (m=0x804b4b8, w=0x804baa0, self=0x804d778)
at tport.c:2726
#15 0xb7f76331 in su_epoll_port_wait_events (self=0x804b790, tout=1000) at
su_epoll_port.c:506
#16 0xb7f72d6b in su_base_port_run (self=0x804b790) at su_base_port.c:342
#17 0xb7f6fc69 in su_port_run (self=0x804b790) at su_port.h:310
#18 0xb7f6fc46 in su_root_run (self=0x804bc18) at su_root.c:689
#19 0xb7f73841 in su_pthread_port_clone_main (varg=0xbf959eec) at
su_pthread_port.c:321
#20 0xb7b754fb in start_thread () from /lib/i686/cmov/libpthread.so.0
#21 0xb7df7d7e in clone () from /lib/i686/cmov/libc.so.6
(gdb) f 0
#0 0xb7edd771 in msg_hclass_offset (mc=0xb7fd1f80, mo=0x8054ac4,
hc=0x75706552) at msg_parser.c:2475
(gdb) p *mc->mc_hash_size
Cannot access memory at address 0x7f
(gdb) p mc->mc_hash_size
$14 = 127
(gdb) p hc
$15 = (const struct msg_hclass_s *) 0x75706552
(gdb) p *hc
Cannot access memory at address 0x75706552
If I put the same TAG in nua_create then the application crashes immediately.
I'm attaching the simple application which reproduces the issue.
Regards.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2041747&group_id=143636
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2037585 ] nta crash in a call termination
Bugs item #2037585, was opened at 2008-08-04 16:34
Message generated for change (Comment added) made by ppessi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2037585&group_id=143636
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: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
>Assigned to: Pekka Pessi (ppessi)
Summary: nta crash in a call termination
Initial Comment:
Copied from http://bugs.freedesktop.org/show_bug.cgi?id=16857 :
Using tp-sofiasip darcs HEAD as of 25-Jul-2008 and sofia-sip 1.12.9 (and an
experimental version of stream-engine for farsight2)
I call my PC from an N810 with diablo. A voice-only call is established.
Then I try to enable video from the N810.. The call is closed (by the n810)...
Then it crashes.. and obviously now that I want to file a bug, I can't
reproduce it to get a nice clean log...
#0 outgoing_other_destinations (orq=) at nta.c:9186
sr = (struct sipdns_resolver *) 0x63696d73
#1 0xb7e4b2b0 in outgoing_tport_error (agent=0x807b7e0, orq=0x8087890,
tp=0x8087618, msg=0x8090f68,
error=110) at nta.c:7642
tpn = (const tp_name_t *) 0x808765c
__PRETTY_FUNCTION__ = "outgoing_tport_error"
#2 0xb7eb9d07 in tport_pending_error (self=0x8087618, dst=0x0, error=110) at
tport.c:4187
i = 0
reported = 1
callbacks = 0
pending = (tport_pending_t *) 0x80938e0
msg = (msg_t *) 0x8090f68
__PRETTY_FUNCTION__ = "tport_pending_error"
#3 0xb7ec06ea in tport_error_report (self=0x8087618, errcode=110, addr=0x0) at
tport.c:2521
errmsg = 0xb7a54225 "Connection timed out"
__func__ = "tport_error_report"
#4 0xb7ec083e in tport_error_event (self=0x8087618) at tport.c:4046
errcode =
name = {{su_dummy = 0, su_family = 0, su_array = '\0' , su_array16 = {
0 }, su_array32 = {0, 0, 0, 0, 0, 0, 0, 0}, su_sa =
{sa_family = 0,
sa_data = '\0' }, su_sin = {sin_family = 0, sin_port =
0, sin_addr = {s_addr = 0},
sin_zero = "\000\000\000\000\000\000\000"}, su_sin6 = {sin6_family = 0,
sin6_port = 0,
sin6_flowinfo = 0, sin6_addr = {in6_u = {u6_addr8 = '\0' , u6_addr16 = {0, 0, 0, 0,
0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}}
#5 0xb7ec262f in tport_connected (magic=0x8073810, w=0x808e690,
self=0x8087618) at tport.c:2667
events = 24
mr = (tport_master_t *) 0x807ca58
wait = {{fd = -1, events = 0, revents = 0}}
error =
__PRETTY_FUNCTION__ = "tport_connected"
#6 0xb7f0faf3 in su_source_dispatch (gs=0x806fcb0, callback=0, user_data=0x0)
at su_source.c:492
root =
i = 16
waits =
n = 18
version = 20
self = (su_port_t *) 0x806fce4
__func__ = "su_source_dispatch"
--
>Comment By: Pekka Pessi (ppessi)
Date: 2008-08-07 16:15
Message:
Logged In: YES
user_id=52043
Originator: NO
There was a problem with nta changing the transport during transaction
lifetime.
The patch "nta: fix to #2037585: always release error callback when
changing transports" should fix the problem.
--
Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2008-08-04 16:38
Message:
Logged In: YES
user_id=313104
Originator: YES
Might be related to bug 1877480:
https://sourceforge.net/tracker/index.php?func=detail&aid=1877480&group_id=143636&atid=756076
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2037585&group_id=143636
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2037585 ] nta crash in a call termination
Bugs item #2037585, was opened at 2008-08-04 16:34
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2037585&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: nta crash in a call termination
Initial Comment:
Copied from http://bugs.freedesktop.org/show_bug.cgi?id=16857 :
Using tp-sofiasip darcs HEAD as of 25-Jul-2008 and sofia-sip 1.12.9 (and an
experimental version of stream-engine for farsight2)
I call my PC from an N810 with diablo. A voice-only call is established.
Then I try to enable video from the N810.. The call is closed (by the n810)...
Then it crashes.. and obviously now that I want to file a bug, I can't
reproduce it to get a nice clean log...
#0 outgoing_other_destinations (orq=) at nta.c:9186
sr = (struct sipdns_resolver *) 0x63696d73
#1 0xb7e4b2b0 in outgoing_tport_error (agent=0x807b7e0, orq=0x8087890,
tp=0x8087618, msg=0x8090f68,
error=110) at nta.c:7642
tpn = (const tp_name_t *) 0x808765c
__PRETTY_FUNCTION__ = "outgoing_tport_error"
#2 0xb7eb9d07 in tport_pending_error (self=0x8087618, dst=0x0, error=110) at
tport.c:4187
i = 0
reported = 1
callbacks = 0
pending = (tport_pending_t *) 0x80938e0
msg = (msg_t *) 0x8090f68
__PRETTY_FUNCTION__ = "tport_pending_error"
#3 0xb7ec06ea in tport_error_report (self=0x8087618, errcode=110, addr=0x0) at
tport.c:2521
errmsg = 0xb7a54225 "Connection timed out"
__func__ = "tport_error_report"
#4 0xb7ec083e in tport_error_event (self=0x8087618) at tport.c:4046
errcode =
name = {{su_dummy = 0, su_family = 0, su_array = '\0' , su_array16 = {
0 }, su_array32 = {0, 0, 0, 0, 0, 0, 0, 0}, su_sa =
{sa_family = 0,
sa_data = '\0' }, su_sin = {sin_family = 0, sin_port =
0, sin_addr = {s_addr = 0},
sin_zero = "\000\000\000\000\000\000\000"}, su_sin6 = {sin6_family = 0,
sin6_port = 0,
sin6_flowinfo = 0, sin6_addr = {in6_u = {u6_addr8 = '\0' , u6_addr16 = {0, 0, 0, 0,
0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}}
#5 0xb7ec262f in tport_connected (magic=0x8073810, w=0x808e690,
self=0x8087618) at tport.c:2667
events = 24
mr = (tport_master_t *) 0x807ca58
wait = {{fd = -1, events = 0, revents = 0}}
error =
__PRETTY_FUNCTION__ = "tport_connected"
#6 0xb7f0faf3 in su_source_dispatch (gs=0x806fcb0, callback=0, user_data=0x0)
at su_source.c:492
root =
i = 16
waits =
n = 18
version = 20
self = (su_port_t *) 0x806fce4
__func__ = "su_source_dispatch"
--
>Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2008-08-04 16:38
Message:
Logged In: YES
user_id=313104
Originator: YES
Might be related to bug 1877480:
https://sourceforge.net/tracker/index.php?func=detail&aid=1877480&group_id=143636&atid=756076
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2037585&group_id=143636
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2037585 ] nta crash in a call termination
Bugs item #2037585, was opened at 2008-08-04 16:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2037585&group_id=143636
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: nta crash in a call termination
Initial Comment:
Copied from http://bugs.freedesktop.org/show_bug.cgi?id=16857 :
Using tp-sofiasip darcs HEAD as of 25-Jul-2008 and sofia-sip 1.12.9 (and an
experimental version of stream-engine for farsight2)
I call my PC from an N810 with diablo. A voice-only call is established.
Then I try to enable video from the N810.. The call is closed (by the n810)...
Then it crashes.. and obviously now that I want to file a bug, I can't
reproduce it to get a nice clean log...
#0 outgoing_other_destinations (orq=) at nta.c:9186
sr = (struct sipdns_resolver *) 0x63696d73
#1 0xb7e4b2b0 in outgoing_tport_error (agent=0x807b7e0, orq=0x8087890,
tp=0x8087618, msg=0x8090f68,
error=110) at nta.c:7642
tpn = (const tp_name_t *) 0x808765c
__PRETTY_FUNCTION__ = "outgoing_tport_error"
#2 0xb7eb9d07 in tport_pending_error (self=0x8087618, dst=0x0, error=110) at
tport.c:4187
i = 0
reported = 1
callbacks = 0
pending = (tport_pending_t *) 0x80938e0
msg = (msg_t *) 0x8090f68
__PRETTY_FUNCTION__ = "tport_pending_error"
#3 0xb7ec06ea in tport_error_report (self=0x8087618, errcode=110, addr=0x0) at
tport.c:2521
errmsg = 0xb7a54225 "Connection timed out"
__func__ = "tport_error_report"
#4 0xb7ec083e in tport_error_event (self=0x8087618) at tport.c:4046
errcode =
name = {{su_dummy = 0, su_family = 0, su_array = '\0' , su_array16 = {
0 }, su_array32 = {0, 0, 0, 0, 0, 0, 0, 0}, su_sa =
{sa_family = 0,
sa_data = '\0' }, su_sin = {sin_family = 0, sin_port =
0, sin_addr = {s_addr = 0},
sin_zero = "\000\000\000\000\000\000\000"}, su_sin6 = {sin6_family = 0,
sin6_port = 0,
sin6_flowinfo = 0, sin6_addr = {in6_u = {u6_addr8 = '\0' , u6_addr16 = {0, 0, 0, 0,
0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}}
#5 0xb7ec262f in tport_connected (magic=0x8073810, w=0x808e690,
self=0x8087618) at tport.c:2667
events = 24
mr = (tport_master_t *) 0x807ca58
wait = {{fd = -1, events = 0, revents = 0}}
error =
__PRETTY_FUNCTION__ = "tport_connected"
#6 0xb7f0faf3 in su_source_dispatch (gs=0x806fcb0, callback=0, user_data=0x0)
at su_source.c:492
root =
i = 16
waits =
n = 18
version = 20
self = (su_port_t *) 0x806fce4
__func__ = "su_source_dispatch"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2037585&group_id=143636
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-2037573 ] Implement ssc_media_state_name() function
Patches item #2037573, was opened at 2008-08-04 13:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2037573&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: Implement ssc_media_state_name() function Initial Comment: This function is inspired upon the nua_callstate_name() from the libsofia-sip API, sligthly improves messages reporting. Regards. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2037573&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Feature Requests-2031629 ] Remove trailing whitespaces from the code
Feature Requests item #2031629, was opened at 2008-07-29 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2031629&group_id=143636 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: None Group: None Status: Open Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing whitespaces from the code Initial Comment: Hi, trailing whitespaces take useless storage space/bandwith, and make more difficult to provide clean patches since it's easy to change the number of them, also they're ugly to see ;-). So it would be nice to avoid them, then maybe to set an hook a-la SVN to reject commits/patches containing them. A script could easily eliminate all of them from the code (I can provide it or the patch if you like it). Regards. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756079&aid=2031629&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Patches-2031162 ] Fix an sdp module usage example codec compilation error
Patches item #2031162, was opened at 2008-07-29 08:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2031162&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Sabatini (stesaba) Assigned to: Nobody/Anonymous (nobody) Summary: Fix an sdp module usage example codec compilation error Initial Comment: Hi, as in the summary. Regards. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756078&aid=2031162&group_id=143636 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-2007672 ] IPv6 contact is used on IPv4 transport
Bugs item #2007672, was opened at 2008-07-01 15:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2007672&group_id=143636 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: IPv6 contact is used on IPv4 transport Initial Comment: Copied from Telepathy-SofiaSIP bug # 1988988: My client has both ipv4 and ipv6 addresses. It registers to a sip server with only ipv4. In the telepathy debug output i see: nta::contact: sip:[EMAIL PROTECTED]:348:16d:0:20d:93ff:fe83:5a93]:44547> and on the server it says: Contact "user" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2007672&group_id=143636 --------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected
Bugs item #1930055, was opened at 2008-03-31 13:47 Message generated for change (Comment added) made by mzabaluev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 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: None Group: None >Status: Closed Resolution: Works For Me Priority: 1 Private: No Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Unregister when a new public binding is detected Initial Comment: When outbound detects a new address binding, any successful registration by the same NUA handle should be explicitly unregistered. This may be needed in two cases: 1) weird configurations with NAT and no authentication; 2) when the binding changes on a NAT middle box. See also the discussion on a maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3056 -- >Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 17:01 Message: Logged In: YES user_id=313104 Originator: YES It's been working as described, the bug is invalid. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-04 15:43 Message: Logged In: YES user_id=313104 Originator: YES > The previous contact is added to the new REGISTER request with expires=0 parameter. Was it implemented in Sofia-SIP for a long time? -- Comment By: Pekka Pessi (ppessi) Date: 2008-04-04 15:37 Message: Logged In: YES user_id=52043 Originator: NO The previous contact is added to the new REGISTER request with expires=0 parameter. In other words, the REGISTER request is used to both unregister the old contact and register the newly discovered contact. While this is very basic REGISTER functionality from pre-RFC-2543 era, it may confuse some proxies. Please confirm if that is so. -- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-04-02 11:59 Message: Logged In: YES user_id=313104 Originator: YES Maybe it's not a good idea to unregister _before_ the contact is updated. But it could be done afterwards (after the whole update transaction, or perhaps just firing an un-REGISTER request right after the REGISTER with a contact update is sent?). OTOH, it can bring more issues with saner proxies, than it solves with a few not-so-sane examples. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636 ----- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
