gmane.comp.telephony.sofia-sip.devel

Trouble Porting sofia-sip 1.11 to ARM (Android)

Craig Vanderborgh — 2012-05-24T17:17:50

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/

Controlling Source IP Address

Jerry Richards — 2012-05-23T18:41:29

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-sip-devel mailing list
Sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[patch] NUTAG_SESSION_REFRESHER withnua_local_refresher don't works

Alexsander Petry — 2012-05-17T13:17:40

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-ua/nua/nua_session.c
< at >< at > -4527,6 +4527,8 < at >< at > session_timer_negotiate(struct session_timer *t, int
uas)
     t->refresher = nua_local_refresher;
   else if (t->remote.refresher == nua_remote_refresher)
     t->refresher = nua_remote_refresher;
+  else if (t->local.refresher == nua_local_refresher)
+    t->refresher = nua_local_refresher;
   else if (uas)
     /* UAS defaults UAC to refreshing */
     t->refresher = nua_remote_refresher;
$


Best regards.

Re: How to add SIP E-Tag to PUBLISH Expiry message

Anees K A — 2012-05-14T10:26:56

HI all,

Can anyone please give me an answer on this ?

Regards

anees k A



On Fri, May 11, 2012 at 2:48 PM, Anees K A <anees.ka-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/< at >public.gmane.org>wrote:

------------------------------------------------------------------------------
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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Not receiving nua_r_unpublish

Anees K A — 2012-05-14T06:37:19

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->op_handle,*
*SIPTAG_EXPIRES_STR("0"),*
*SIPTAG_IF_MATCH_STR((strlen(s8SipIfMatch) > 0)?pstrRadioInfo->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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

How to add SIP E-Tag to PUBLISH Expiry message

Anees K A — 2012-05-11T09:18:42

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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Lifetime of NUTAG_REFER_EVENT returned pointer

Olivier Deme — 2012-05-06T08:52:04

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 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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Preventing Listening on Ephemeral TCP Port(usually 1024 or 2048)

Jerry Richards — 2012-04-30T16:18:57

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< at >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< at >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 I can't find what is opening it.  It's either sofia-sip or something else?

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-sip-devel mailing list
Sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[ sofia-sip-Bugs-2412241 ] Registration toEkiga.net fails

SourceForge.net — 2012-03-28T16:09:07

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&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:  ()
Date: 2012-03-28 09:09

Message:
Any updates?

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

Comment By: Jeremy Nickurak (gehrehmee)
Date: 2010-07-19 08: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 08: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 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:
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:
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

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

setting the caller id (number or name)

Nick Knight — 2012-03-28T07:23:36

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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[patch] adds NTATAG_TLS_ALIAS to support RFC 5923(only client side)

Alexsander Petry — 2012-03-26T14:13:44

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
< at >< at > -244,6 +244,8 < at >< at > struct nta_agent_s
   unsigned sa_tcp_rport:1;     /**< Use rport with tcp, too */
   unsigned sa_tls_rport:1;     /**< Use rport with tls, too */

+  unsigned sa_tls_alias:1;     /**< Use alias with tls */
+
   unsigned sa_auto_comp:1;     /**< Automatically create compartments */
   unsigned sa_in_timer:1;      /**< Set when executing timers */
   unsigned sa_use_timer_c:1;   /**< Application has set value for timer C
*/
< at >< at > -837,6 +839,7 < at >< at > 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(), NTATAG_USE_SRV() and NTATAG_USE_TIMESTAMP().
< at >< at > -1424,6 +1427,7 < at >< at > void agent_kill_terminator(nta_agent_t *agent)
  * 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(), NTATAG_USE_SRV() and NTATAG_USE_TIMESTAMP().
< at >< at > -1490,6 +1494,7 < at >< at > int agent_set_params(nta_agent_t *agent, tagi_t *tags)
   int server_rport    = agent->sa_server_rport;
   int tcp_rport       = agent->sa_tcp_rport;
   int tls_rport       = agent->sa_tls_rport;
+  int tls_alias       = agent->sa_tls_alias;
   unsigned preload         = agent->sa_preload;
   unsigned threadpool      = agent->sa_tport_threadpool;
   char const *sigcomp = agent->sa_sigcomp_options;
< at >< at > -1537,6 +1542,7 < at >< at > int agent_set_params(nta_agent_t *agent, tagi_t *tags)
              NTATAG_STATELESS_REF(stateless),
              NTATAG_TCP_RPORT_REF(tcp_rport),
              NTATAG_TLS_RPORT_REF(tls_rport),
+             NTATAG_TLS_ALIAS_REF(tls_alias),
              NTATAG_TIMEOUT_408_REF(timeout_408),
              NTATAG_UA_REF(ua),
              NTATAG_UDP_MTU_REF(udp_mtu),
< at >< at > -1711,6 +1717,7 < at >< at > int agent_set_params(nta_agent_t *agent, tagi_t *tags)
   agent->sa_rport = rport != 0;
   agent->sa_tcp_rport = tcp_rport != 0;
   agent->sa_tls_rport = tls_rport != 0;
+  agent->sa_tls_alias = tls_alias != 0;
   agent->sa_preload = preload;
   agent->sa_tport_threadpool = threadpool;

< at >< at > -2570,6 +2577,9 < at >< at > int outgoing_insert_via(nta_outgoing_t *orq,
        (self->sa_tls_rport && v->v_protocol == sip_transport_tls)))
     msg_header_add_param(msg_home(msg), v->v_common, "rport");

+  if (self->sa_tls_alias && v->v_protocol == sip_transport_tls)
+    msg_header_add_param(msg_home(msg), v->v_common, "alias");
+
   if (!orq->orq_tpn->tpn_comp)
     msg_header_remove_param(v->v_common, "comp");

diff --git a/libsofia-sip-ua/nta/nta_tag.c b/libsofia-sip-ua/nta/nta_tag.c
index 1c09016..62f0e64 100644
--- a/libsofia-sip-ua/nta/nta_tag.c
+++ b/libsofia-sip-ua/nta/nta_tag.c
< at >< at > -1399,6 +1399,32 < at >< at > tag_typedef_t ntatag_tcp_rport =
BOOLTAG_TYPEDEF(tcp_rport);
  */
 tag_typedef_t ntatag_tls_rport = BOOLTAG_TYPEDEF(tls_rport);

+/**< at >def NTATAG_TLS_ALIAS(x)
+ *
+ * Use alias with TLS.
+ *
+ * < at >par Used with
+ *    nua_create(), nua_set_params(),
+ *    nta_agent_create(), nta_agent_set_params()
+ *
+ * < at >par Parameter type
+ *    boolean: true (non-zero or non-NULL pointer)
+ *          or false (zero or NULL pointer)
+ *
+ * < at >par Values
+ *    - true - include alias parameter in the TLS via line on client side
+ *    - false - do not include alias parameter in the TLS via line
+ *      on client side
+ *
+ * < at >sa < at >RFC5923, < at >Via
+ *
+ * < at >NEW_1_12_12
+ */
+tag_typedef_t ntatag_tls_alias = BOOLTAG_TYPEDEF(tls_alias);
+
 /**< at >def NTATAG_PRELOAD(x)
  *
  * Preload by N bytes.
diff --git a/libsofia-sip-ua/nta/sofia-sip/nta_tag.h
b/libsofia-sip-ua/nta/sofia-sip/nta_tag.h
index 09f586c..a4cab2b 100644
--- a/libsofia-sip-ua/nta/sofia-sip/nta_tag.h
+++ b/libsofia-sip-ua/nta/sofia-sip/nta_tag.h
< at >< at > -375,6 +375,12 < at >< at > NTA_DLL extern tag_typedef_t ntatag_tls_rport;
 NTA_DLL extern tag_typedef_t ntatag_tls_rport_ref;
 #define NTATAG_TLS_RPORT_REF(x) ntatag_tls_rport_ref, tag_bool_vr(&(x))

+NTA_DLL extern tag_typedef_t ntatag_tls_alias;
+#define NTATAG_TLS_ALIAS(x) ntatag_tls_alias, tag_bool_v((x))
+
+NTA_DLL extern tag_typedef_t ntatag_tls_alias_ref;
+#define NTATAG_TLS_ALIAS_REF(x) ntatag_tls_alias_ref, tag_bool_vr(&(x))
+
 NTA_DLL extern tag_typedef_t ntatag_preload;
 #define NTATAG_PRELOAD(x) ntatag_preload, tag_uint_v((x))



Regards.

[patch] fix warning of sentinel attribute on gcclower than 4

Alexsander Petry — 2012-03-26T13:22:03

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
< at >< at > -41,6 +41,9 < at >< at >

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


Regards.

nua_shutdown timeout

Francesco Lamonica — 2012-03-23T17:43:19

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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: PRACK and 200 OK(INVITE) forking issue

Beppe Grillo — 2012-03-22T15:20:52

Hi,
I need to manage the PRACK side application, I set
NUTAG_APPL_METHOD("PRACK"), With this configuration are passed to the
application the 183.
How do I configure the stack to deliver the application only the PRACK?,
Thanks,
Beppe

2012/3/14 Timo Bruhn <voip_voip< at >web.de>:

------------------------------------------------------------------------------
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< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[ sofia-sip-Bugs-3510029 ] sofia sip crash onandroid

SourceForge.net — 2012-03-22T10:14:56

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&atid=756076&aid=3510029&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 '<', 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 '<'.

 if (s[n] == '<') {
      /* OK, we got a display name */
      display = s; s += n + 1;
      /* NUL terminate display name */
      while (n > 0 && IS_LWS(display[n - 1]))
n--;
      if (n > 0)
display[n] = '\0';
      else
       display="";

Since the address of display is assigned to *return_display, this gives problems on Android.
If we change display="" with display=NULL the code doesn't crashed.



   



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=3510029&group_id=143636

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

cross compiling with glib

Mario Raffin — 2012-03-21T17:32:13

*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=<path to libglib-2.0.so>

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 have to add a typedef in soa_tag.h for "soatag_local_sdp_str_ref" which seems to be undefined)

*
Till now I haven’t found a way to link with the arm libs. Any help would be appreciated.

Thank you*

sofia sip crash on ARM processo

Chris Herssens — 2012-03-21T12:13:49

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>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

cross compiling with glib

Mario Raffin — 2012-03-20T17:51:30

*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*

Re: Patches for 1.12.11

Benoît Vallée — 2012-03-20T10:22:40

Hi!

Thanks for the patches!

I don't know what is the best way to submit patches, but you can use the 
tracker on sourceforge: 
http://sourceforge.net/tracker/?group_id=143636&atid=756078 
<http://sourceforge.net/tracker/?group_id=143636&atid=756078>
(you have to register before submitting a patch)

Benoît

------------------------------------------------------------------------------
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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: PRACK and 200 OK(INVITE) forking issue

Nauman Sulaiman — 2012-03-16T20:08:31

Hi Timo

No we don't have a solution, we looked into it and it needs major changes so we left it.

Regards 




________________________________
 From: Timo Bruhn <voip_voip-S0/GAf8tV78< at >public.gmane.org>
To: nauman762-home< at >yahoo.co.uk 
Cc: sofia-sip-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org 
Sent: Wednesday, 14 March 2012, 11:04
Subject: Re: [Sofia-sip-devel] PRACK and 200 OK(INVITE) forking issue
 
Hi Nauman,

did you find a solution for the problem when forking is combined with PRACK?
Currently we are running into same problems with sofia-sip connecting to a server that uses forking.

Seems that disabling PRACK and soa engine works. But what if PRACK is required?

Thanks,
Timo



___________________________________________________________
Ihr WEB.DE Postfach immer dabei: die kostenlose WEB.DE Mail App für iPhone und Android.
https://produkte.web.de/freemail_mobile_startseite/------------------------------------------------------------------------------
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< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

sofia sip crash on ARM processor

Chris Herssens — 2012-03-15T08:49:01

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->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