<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.telephony.sofia-sip.devel">
    <title>gmane.comp.telephony.sofia-sip.devel</title>
    <link>http://blog.gmane.org/gmane.comp.telephony.sofia-sip.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4437"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4436"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4435"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4433"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4432"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4431"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4430"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4429"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4428"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4427"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4426"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4425"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4423"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4422"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4421"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4420"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4417"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4415"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4414"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4413"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4437">
    <title>Trouble Porting sofia-sip 1.11 to ARM (Android)</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4437</link>
    <description>&lt;pre&gt;Hello:

I am using the Android NDK (v6b) to successfully cross-compile
sofia-sip for Android.  The results MOSTLY work, but crash with weird
string problems in INVITE.

Has anyone build sofia-sip for Android and successfully used the
results?  The cross-compile for Android is clean (no errors/warnings)
but there are definitely problems with my port.

Please tell me anything you can about how to get sofia-sip to work
properly on ARM (compilation flags, etc.)

Thanks,
Craig Vanderborgh
Voxware Incorporated

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Craig Vanderborgh</dc:creator>
    <dc:date>2012-05-24T17:17:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4436">
    <title>Controlling Source IP Address</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4436</link>
    <description>&lt;pre&gt;I have a Freeswitch issue, where I have softphones connected to two separate subnets (one on eth0 and the other on eth1).  When I send an IM (i.e. SIP MESSAGE) from the eth1 phone to the eth0 phone, a wireshark trace shows the source IP address of the eth1 server address, rather than the eth0 server address.  The eth1 address makes no sense on the eth0 subnet, so the softphone does not reply.

Is there a sofia tag to control the source IP in this case?  The message is going out the right interface; the issue is just that the source IP address is wrong.

Thanks,
Jerry
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Sofia-&lt;/pre&gt;</description>
    <dc:creator>Jerry Richards</dc:creator>
    <dc:date>2012-05-23T18:41:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4435">
    <title>[patch] NUTAG_SESSION_REFRESHER withnua_local_refresher don't works</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4435</link>
    <description>&lt;pre&gt;Hi, NUTAG_SESSION_REFRESHER with nua_local_refresher don't works.

In commit 7e8db8127e88cc7578dd9a9804338ac91bbae57e (
https://gitorious.org/sofia-sip/sofia-sip/commit/7e8db8127e88cc7578dd9a9804338ac91bbae57e
),
by default, the refresher is always nua_local_refresher, and the
NUTAG_SESSION_REFRESHER with nua_local_refresher lost its effect.

But, in commit 49d7086522e62be5b2904d2c514e6cc4fbf83998 (
https://gitorious.org/sofia-sip/sofia-sip/commit/49d7086522e62be5b2904d2c514e6cc4fbf83998
),
by default, /* UAS defaults UAC to refreshing */  and /* UAC refreshes by
itself */, and the NUTAG_SESSION_REFRESHER with nua_local_refresher
continues without effect.

A patch to fix this problem is available on
https://gitorious.org/~alexsanderpetry/sofia-sip/alexsanderpetry-sofia-sip/commit/265b9c16226950c11829fc1aa700c4c878d65e46

Diff:
$ git diff
diff --git a/libsofia-sip-ua/nua/nua_session.c
b/libsofia-sip-ua/nua/nua_session.c
index 140dcaa..1a757f5 100644
--- a/libsofia-sip-ua/nua/nua_session.c
+++ b/libsofia-sip-u&lt;/pre&gt;</description>
    <dc:creator>Alexsander Petry</dc:creator>
    <dc:date>2012-05-17T13:17:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4433">
    <title>Not receiving nua_r_unpublish</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4433</link>
    <description>&lt;pre&gt;Hi,

When I make an un-publish request with Expirt set as 0, I am not receiving
the callback 'nua_r_unpublish' . Is this a bug or am I doing something
wrong ?

This is what I do to call un-publish

*nua_publish (op-&amp;gt;op_handle,*
*SIPTAG_EXPIRES_STR("0"),*
*SIPTAG_IF_MATCH_STR((strlen(s8SipIfMatch) &amp;gt; 0)?pstrRadioInfo-&amp;gt;s8Sip:NULL,*
*TAG_NULL());*

Any help is appreciated.

Regards

anees k A
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
&lt;/pre&gt;</description>
    <dc:creator>Anees K A</dc:creator>
    <dc:date>2012-05-14T06:37:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4432">
    <title>How to add SIP E-Tag to PUBLISH Expiry message</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4432</link>
    <description>&lt;pre&gt;Hi,

I am sending PUBLISH messages using nua_publish API. The Expiry for such
message is 600. I am modifying the PUBLISH using the SIP-If-Match header
when the next publish is being sent out.

The sofia stack seems to be sending A PUBLISH message with Expiry zero even
if my expiry is not met.

Also I see that in that message (Expires : 0), no SIP E-tag is present.
According to the documentation, application should take care of that. Can
you please tell me how to add SIP-ETag to Expires : 0 PUBLISH message?

Regards

anees k A
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel-5NW&lt;/pre&gt;</description>
    <dc:creator>Anees K A</dc:creator>
    <dc:date>2012-05-11T09:18:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4431">
    <title>Lifetime of NUTAG_REFER_EVENT returned pointer</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4431</link>
    <description>&lt;pre&gt;Hi,

I have a question with regards to the handling of the nua_i_refer event.
As indicated in the documentation, the application must get the refer  
event (NUTAG_REFER_EVENT()) and the referred by (SIPTAG_REFERRED_BY())  
pointers and pass these to the call to nua_invite to establish the  
session to the refer target.

What I am wondering is what is the lifetime of these pointers before  
they get released automatically by Sofia?
In particular:
1. Is it ok for the application to *not* call nua_invite in the  
nua_i_refer callback handler, but instead store these pointers and  
call nua_invite some time later from another entry point?
2. If the answer to 1 is yes, will the stack automatically free these  
pointers after some time (through a timer)?
3. If the answer to 2 is yes, does Sofia generates an event so that  
the application can tell if these pointers have been freed?

Many thanks for your assistance,
Olivier.

------------------------------------------------------------------------------
Live Securi&lt;/pre&gt;</description>
    <dc:creator>Olivier Deme</dc:creator>
    <dc:date>2012-05-06T08:52:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4430">
    <title>Preventing Listening on Ephemeral TCP Port(usually 1024 or 2048)</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4430</link>
    <description>&lt;pre&gt;Hello All,

We are using TLS in a high security phone application.  Sofia is listening for connections on an unencrypted ephemeral TCP port (usually 1024 or 2048).
This poses a security risk and we're looking for the correct way to prevent listening on TCP ports when TLS is enabled.

Does anyone know how to do this?

Thanks,
Jerry


From: Jerry Richards
Sent: Monday, February 20, 2012 11:04 AM
To: 'sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org'
Subject: RE: Port 1024 Open?

Okay, I found that TPTAG_SERVER is enabled by default.  This was causing port 1024 to be opened when when using TLS.  Why is this enabled by default?  I'm using sofia-sip for a phone application so this definitely needs to be disabled.

Thanks,
Jerry

From: Jerry Richards
Sent: Tuesday, February 14, 2012 8:08 AM
To: 'sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org'
Subject: Port 1024 Open?

Is it possible that sofia-sip is opening port 1024?  We did a port scan on our phone and port 1024 is open, but &lt;/pre&gt;</description>
    <dc:creator>Jerry Richards</dc:creator>
    <dc:date>2012-04-30T16:18:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4429">
    <title>[ sofia-sip-Bugs-2412241 ] Registration toEkiga.net fails</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4429</link>
    <description>&lt;pre&gt;Bugs item #2412241, was opened at 2008-12-09 10:06
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&amp;amp;atid=756076&amp;amp;aid=2412241&amp;amp;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:  ()
Date: 2012-03-28 09:09

Message:
Any updates?

----------------------------------------------------------------------

Commen&lt;/pre&gt;</description>
    <dc:creator>SourceForge.net</dc:creator>
    <dc:date>2012-03-28T16:09:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4428">
    <title>setting the caller id (number or name)</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4428</link>
    <description>&lt;pre&gt;Hi,

I am trying to set the caller id of a sofia client.

I think I need to do something with SIPTAG_CALL_INFO, but can't figure it
out.

Has someone got a little example please?

KR

Nick
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
&lt;/pre&gt;</description>
    <dc:creator>Nick Knight</dc:creator>
    <dc:date>2012-03-28T07:23:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4427">
    <title>[patch] adds NTATAG_TLS_ALIAS to support RFC 5923(only client side)</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4427</link>
    <description>&lt;pre&gt;Hi, patch that adds NTATAG_TLS_ALIAS to support RFC 5923 (only client
side) available
on
https://gitorious.org/~alexsanderpetry/sofia-sip/alexsanderpetry-sofia-sip


--- a/libsofia-sip-ua/nta/nta.c
+++ b/libsofia-sip-ua/nta/nta.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -244,6 +244,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct nta_agent_s
   unsigned sa_tcp_rport:1;     /**&amp;lt; Use rport with tcp, too */
   unsigned sa_tls_rport:1;     /**&amp;lt; Use rport with tls, too */

+  unsigned sa_tls_alias:1;     /**&amp;lt; Use alias with tls */
+
   unsigned sa_auto_comp:1;     /**&amp;lt; Automatically create compartments */
   unsigned sa_in_timer:1;      /**&amp;lt; Set when executing timers */
   unsigned sa_use_timer_c:1;   /**&amp;lt; Application has set value for timer C
*/
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -837,6 +839,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; su_log_t nta_log[] = { SU_LOG_INIT("nta", "NTA_DEBUG",
SU_DEBUG) };
  * NTATAG_STATELESS(),
  * NTATAG_TAG_3261(), NTATAG_TCP_RPORT(), NTATAG_TIMEOUT_408(),
  * NTATAG_TLS_RPORT(),
+ * NTATAG_TLS_ALIAS(),
  * NTATAG_TIMER_C(), NTATAG_MAX_PROCEEDING(),
  * NTATAG_UA(), NTATAG_UDP_MTU(), NTATAG_USER_VIA(),
  * NTATAG_USE_NAPTR&lt;/pre&gt;</description>
    <dc:creator>Alexsander Petry</dc:creator>
    <dc:date>2012-03-26T14:13:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4426">
    <title>[patch] fix warning of sentinel attribute on gcclower than 4</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4426</link>
    <description>&lt;pre&gt;Hi, patch that fixes warning of sentinel attribute on gcc lower than 4
available
on
https://gitorious.org/~alexsanderpetry/sofia-sip/alexsanderpetry-sofia-sip

--- a/libsofia-sip-ua/su/sofia-sip/su_config.h
+++ b/libsofia-sip-ua/su/sofia-sip/su_config.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -41,6 +41,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

 #if defined(__GNUC__)
 /* Special attributes for GNU C */
+#if __GNUC__ &amp;lt; 4
+#define __sentinel__(x)
+#endif
 #if __GNUC__ &amp;lt; 3 &amp;amp;&amp;amp; (!defined(__GNUC_MINOR__) || __GNUC_MINOR__ &amp;lt; 96)
 #define __malloc__             /* avoid spurious warnigns */
 #endif


Regards.
&lt;/pre&gt;</description>
    <dc:creator>Alexsander Petry</dc:creator>
    <dc:date>2012-03-26T13:22:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4425">
    <title>nua_shutdown timeout</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4425</link>
    <description>&lt;pre&gt;Hi all,
sofia responded with a 500 status message to my nua_shutdown() call.
This seems to happen randomly on a linux machine that has a NIC that is
configured with multiple aliases (eth0, eth0:0, eth0:1) and two VLANs bound
to the same physical NIC.
what is the recommended practice?
should i try the nua_shutdown again?
can i destroy the nua nonetheless?
any hints on how to track down the problem?
thanks
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
&lt;/pre&gt;</description>
    <dc:creator>Francesco Lamonica</dc:creator>
    <dc:date>2012-03-23T17:43:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4423">
    <title>[ sofia-sip-Bugs-3510029 ] sofia sip crash onandroid</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4423</link>
    <description>&lt;pre&gt;Bugs item #3510029, was opened at 2012-03-22 03:14
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&amp;amp;atid=756076&amp;amp;aid=3510029&amp;amp;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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: sofia sip crash on android

Initial Comment:
When the TO sip header or FROM sip header starts with a '&amp;lt;', the code crash on android.   After tracking the problem it seems that there is an error in sip_basic.c. In the  method "sip_name_addr" you can see the variable is assigned to an empty string when the sip header starts with a '&amp;lt;'.

 if (s[n] == '&amp;lt;') {
      /* OK, we got a display name */
      display = s; s += n + 1;
      /* NUL terminate di&lt;/pre&gt;</description>
    <dc:creator>SourceForge.net</dc:creator>
    <dc:date>2012-03-22T10:14:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4422">
    <title>cross compiling with glib</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4422</link>
    <description>&lt;pre&gt;*Dear All,
    sorry for my previous wrong formatted post. I am trying to compile sofia-sip with glib support.

Until now I was able to cross compile the sofia-sip for arm9 with the option --without-glib.

I also tested it in the embedded environment with the “Hello world” sample project.

Since the sofsip-cli-0.16 requires glib I am now trying to cross-compile it with glib support.
I have the library for arm and I set the LDFLAGS as follow to reach the arm glib.



export LDFLAGS=-L/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/lib -L/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/usr/lib



The LDFLAGS are set correctly in the makefile but it seems that during make, the linker points to the host library in
“/usr/lib/libglib-2.0.so”.


**The*  option --with-glib-dir=&amp;lt;path to libglib-2.0.so&amp;gt;

I can compile when I substitute (temporarily) the i386 with arm version of the lib in /usr/lib.
However the same problem then happen when I compile the sofsip-cli-0.16.
(To compile this I also h&lt;/pre&gt;</description>
    <dc:creator>Mario Raffin</dc:creator>
    <dc:date>2012-03-21T17:32:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4421">
    <title>sofia sip crash on ARM processo</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4421</link>
    <description>&lt;pre&gt;Hello All,

I found the error about why sofia sip crashed on android.
The problem is in sip_basic.c in the the method sip_name_addr_d. there
you can find:

if (n&amp;gt;0)
  display[n] ='\0';
else
  display="";
...
if (return_display)
    *return_display = display;


Now if n=0 then the address for return_display  is undefined. if I
replace display="" with display=NULL, the incoming sip request works
fine.


regards,

Chris

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
&lt;/pre&gt;</description>
    <dc:creator>Chris Herssens</dc:creator>
    <dc:date>2012-03-21T12:13:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4420">
    <title>cross compiling with glib</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4420</link>
    <description>&lt;pre&gt;*I was able to cross compile the sofia-sip for arm9 with the option --without-glib.
I also tested it in the embedded environment with the "Hello world" sample project.

Since the sofsip-cli-0.16 requires glib I am now trying to cross-compile it with glib support. I have the library for arm and I set the LDFLAGS as follow to reach the arm glib.

export LDFLAGS=-L/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/lib -L/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/usr/lib

The LDFLAGS are set correctly in the makefile but it seems that during make, the linker points to the host library in "/usr/lib/libglib-2.0.so".

Till now I haven't found a way to link with the arm lib. Any help would be appreciated.

Thank you*

&lt;/pre&gt;</description>
    <dc:creator>Mario Raffin</dc:creator>
    <dc:date>2012-03-20T17:51:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4417">
    <title>sofia sip crash on ARM processor</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4417</link>
    <description>&lt;pre&gt;Hello all,


I still have problems running sofia-sip on a ARM processor. Sometimes
on incoming SIP requests, sofia-sip crash when calling  "tagi_t
*msghdrtag_dup(tagi_t *dst, tagi_t const *src, void **bb)". To find
out what is going
wrong I put some logs and it seems that the variable size (= SIZE_MAX
- (uintptr_t)b) is always bigger than ISSIZE_MAX. The crash happens
since after calling the function "b = hc-&amp;gt;hc_dup_one(h, o, b, size)",
b is not null.
Is it normal that size is always bigger than ISSIZE_MAX. Does someone
has the same problem on ARM  processor ? Maybe I need to add some
compile flags ?
I use sofia sip version 1.12.11


Regards,

Chris

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
&lt;/pre&gt;</description>
    <dc:creator>Chris Herssens</dc:creator>
    <dc:date>2012-03-15T08:49:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4415">
    <title>Patches for 1.12.11</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4415</link>
    <description>&lt;pre&gt;Hi,

I'd like to suggest several patches for the current version of Sofia sip
(1.12.11):

First an index out of bounds in check_sres_sip.c, in line 113 and 114 it
accesses su_addrinfo_t hint_udp_tcp_tls [2]

Index: libsofia-sip-ua/sresolv/check_sres_sip.c
================================================================
--- libsofia-sip-ua/sresolv/check_sres_sip.c    
+++ libsofia-sip-ua/sresolv/check_sres_sip.c    (working copy)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -66,7 +66,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 } x[1];

 static su_addrinfo_t hint_udp_tcp[2];
-static su_addrinfo_t hint_udp_tcp_tls[2];
+static su_addrinfo_t hint_udp_tcp_tls[3];
 static su_addrinfo_t hint_udp_tcp_ip4[2];
 static su_addrinfo_t hint_tls[1];
 static su_addrinfo_t hint_tls_udp_tcp[1];


Here I changed it to what it says in den method description to return
NUL, because the original might return something else.
Index: libsofia-sip-ua/http/http_basic.c
--- libsofia-sip-ua/http/http_basic.c  
+++ libsofia-sip-ua/http/http_basic.c   (working copy)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -587,9 +587,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
     if (date == 0)
       date =&lt;/pre&gt;</description>
    <dc:creator>ECKSCHLAGER Manfred</dc:creator>
    <dc:date>2012-03-12T17:16:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4414">
    <title>query regarding behaviour of UAS</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4414</link>
    <description>&lt;pre&gt;Hi,

      I have a small query regarding the behaviour of SIP UAS, i.e what
should be the response for  badly formatted ACK request received by UAS in
the below scenarios



1)  UAC                                         UAS

                                Invite
                               --------&amp;gt;

                             503 RESP
                             &amp;lt;----------

                               Cancle
                              ----------&amp;gt;

                             200 RESP
                             &amp;lt;----------

                               487 RESP
                             &amp;lt;----------

                    ACK(badly formatted)
                             -----------&amp;gt;            (how UAS has to
respond for this ACK???)




 2)      UAC                                         UAS

                   Invite(badly formatted)
                               --------&amp;gt;

                             400 RESP
                             &amp;lt;----------

                   Cancle(bad&lt;/pre&gt;</description>
    <dc:creator>manju nath</dc:creator>
    <dc:date>2012-03-08T04:09:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4413">
    <title>Origin SDP address overwritten by sofia whenanswering call.</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4413</link>
    <description>&lt;pre&gt;Hi,

Our sofia stack is running on a server with 2 IP addresses configured on 
the same network interface 172.28.2.95 (eth0) and 168.10.10.1(eth0:1) 
but is only bound to 172.28.2.95.

When we respond to an incoming call the "o" field in the SDP is always 
set to the lowest IP address that is available on the server. Even when 
we explicitly set the sdp origin address to 172.28.2.95 it still gets 
replaced by the lower IP address when we call nua_respond.

Why is sofia replacing the o address from 172.28.2.95 that we set in the 
nua_respond with the 168.10.10.1 address?


---------  Sofia Trace --------------------

  v=0
    o=- 122270307672969033 8110503422790704681 IN IP4 168.10.10.1
    s=-
    c=IN IP4 172.28.2.95
    t=0 0
    m=audio 10129 RTP/AVP 8

Many Thanks for your help.


------------------------------------------------------------------------------
Virtualization &amp;amp; Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowi&lt;/pre&gt;</description>
    <dc:creator>Olivier Deme</dc:creator>
    <dc:date>2012-03-07T12:32:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4411">
    <title>Problem while adding parser for new header.</title>
    <link>http://comments.gmane.org/gmane.comp.telephony.sofia-sip.devel/4411</link>
    <description>&lt;pre&gt;Hi All,
I am using Sofia-sip stact 1.12.11 for a B2BUA.
There is a requirement for me to parse new headers like History-Info where
Sofia stack is not supporting currently.
I added the typedef struct and the structure body in "sofia-sip/sip_extra.h"
and also documented the same in "sip_extra_headers.txt"
For simplicity I implemented all the bodies of the corresponding functions
in sip_extra.c
Before compiling I enabled the enable-maintainer-mode.

while compiling I am getting the following problems.

1) The auto generated sip_extra.h does not contain the added typedef and
structure body.
2) this is resulting the compilation errors for all the function
declarations that were auto generated.

Can you please suggest me where I am making the mistake while adding the
new parser.

Thanks,
Kiran .
------------------------------------------------------------------------------
Virtualization &amp;amp; Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on al&lt;/pre&gt;</description>
    <dc:creator>kiran kumar</dc:creator>
    <dc:date>2012-03-03T12:11:33</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.telephony.sofia-sip.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.telephony.sofia-sip.devel</link>
  </textinput>
</rdf:RDF>

