Jerry Richards | 23 May 20:41

Controlling Source IP Address

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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Alexsander Petry | 17 May 15:17
Picon

[patch] NUTAG_SESSION_REFRESHER with nua_local_refresher don't works

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.

--
Alexsander Petry

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Anees K A | 14 May 08:37

Not receiving nua_r_unpublish

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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Anees K A | 11 May 11:18

How to add SIP E-Tag to PUBLISH Expiry message

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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Olivier Deme | 6 May 10:52

Lifetime of NUTAG_REFER_EVENT returned pointer

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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Jerry Richards | 30 Apr 18:18

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

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@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@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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
SourceForge.net | 28 Mar 18:09
Picon

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

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
Nick Knight | 28 Mar 09:23
Favicon

setting the caller id (number or name)

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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Alexsander Petry | 26 Mar 16:13
Picon

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

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.
--
Alexsander Petry

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Alexsander Petry | 26 Mar 15:22
Picon

[patch] fix warning of sentinel attribute on gcc lower than 4

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.
--
Alexsander Petry

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Francesco Lamonica | 23 Mar 18:43
Picon

nua_shutdown timeout

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

Gmane