[Sofia-sip-devel] Windows msvc 2005 build

[Michael Jerris]

I posted a patch for the windows build that fixes several
issues including building on msvc .net 2005. One major issue was several
of the files in tree (including the pthread win32 header files) were filled with
mac line endings. These files need to keep unix line endings or MSVC has
issues. The patch is posted on sourceforge.



Thanks

Mike

Re: [Sofia-sip-devel] OOPS, From sip:123456789@ vs From sip:12.34.56.789

[Michael Jerris]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Henrik Nordstrom
 Sent: Monday, August 28, 2006 7:59 AM
 To: Matt Klein
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] OOPS,From sip:123456789@ vs From
 sip:12.34.56.789
 
 On Sun, 2006-08-27 at 21:14 -0700, Matt Klein wrote:
 
  instead of From sip:12.34.56.789
 
  it should be From sip:[EMAIL PROTECTED]
 
  I am playing with nua_set_params to do this
 
  Is that the correct function?
 
 Probably. If a single user identity then yes.
 
  Additionally, the flag I am playing with is SIPTAG_FROM_STR, and I
have
  played with NUTAG_IDENTITY
 
 NUTAG_IDENTITY is only needed if you need to maintain more than one
user
 identity. If you only need to maintain a single user identity then
 supplying the SIPTAG_FROM to nua_set_params or the request in question
 is sufficient.
 

We definitely need to maintain multiple user identity's for this
situation.  Can someone post an example for NUTAG_IDENTITY usage.

Mike


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] MSVC detected 64 bit issues.

[Michael Jerris]

For reference on __w64: 

http://msdn2.microsoft.com/en-us/library/s04b5w00.aspx

Mike

 -Original Message-
 From: Kai Vehmanen [mailto:[EMAIL PROTECTED]
 Sent: Friday, September 01, 2006 2:33 PM
 To: Michael Jerris
 Cc: Pekka Pessi; sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] MSVC detected 64 bit issues.
 
 Hi,
 
 On Thu, 31 Aug 2006, Michael Jerris wrote:
 
  Attached is a patch that I think addresses the hash_value_t for msvc
64
  without breaking anything else, for your review.  The first ifdef
may
  need to be changed to #if _MSC_VER = 1400 depending on how VC 6
and/or
  mingw behaves on that block of code, unfortunately I don't have
those to
  test against.  Also, please let me know how you would like to
proceed on
 
 seems good to me (Mike explained on #sofia-sip that __w64 is not a
type
 modifier but just a hint to compiler). I'll test this later with VC6.
 
 Pekka, ...? I'm just thinking what the users of the hash table are
really
 expecting (and should expect) from the value type -- should we add
some
 asserts just in case?
 
  the other part of the patch for addressing the other 64bit issues.
On
  closer review, we may want to have some typedefs similar to this
block
  and use that for the casting on the pointer math that I replaced
with
  size_t in the previous patch.
 
 For pointers, we might prefer to explicitly use intptr_t or uintptr_t.
 They are guaranteed to hold any 'void*'.
 
 --
   under work: Sofia-SIP at http://sofia-sip.sf.net

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] MSVC detected 64 bit issues.

[Michael Jerris]

Patch attached that does the double casting, as long as you are sure
this is safe, works fine for me.

Mike

 -Original Message-
 From: Pekka Pessi [mailto:[EMAIL PROTECTED]
 Sent: Monday, September 04, 2006 8:04 AM
 To: Michael Jerris
 Cc: sofia-sip-devel@lists.sourceforge.net; Kai Vehmanen
 Subject: Re: [Sofia-sip-devel] MSVC detected 64 bit issues.
 
 On 8/31/06, Michael Jerris [EMAIL PROTECTED] wrote:
  Attached is a patch that I think addresses the hash_value_t for msvc
64
  without breaking anything else, for your review.  The first ifdef
may
  need to be changed to #if _MSC_VER = 1400 depending on how VC 6
and/or
  mingw behaves on that block of code, unfortunately I don't have
those to
  test against.
 
 I don't think we use hash_value_t to store pointers anywhere. It is
 used, however, when converting a pointer to a hash value, like
 
 htable_hash(hash_value_t x)
 {
return table[x % size];
 }
 
 and then hashing function is used like
 
 htable_hash((hash_value_t)pointer)
 
 I suppose the WIN64 compiler issues a warning when htable_hash is
 called because a pointer is casted to a narrower integer. The warning
 is warranted, but the only problem here is hash table will be slightly
 skewed (if we have, say, a hash table of 1 million entries, the first
 slot is occupied with 0.002 % bigger probability than the last slot).
 
 I hope we can do away casting the pointer twice like
 
 htable_hash((hash_value_t)(uintptr_t)pointer)
 
 which will make the intention clear to the compiler and silence the
 warning.
 
 I guess optimal fix would be to give hash_value_t as a part of
 template instantation macros: if a wide hash_value_t is needed, we
 could pass it, but otherwise, we could do with a narrow one.
 
   Also, please let me know how you would like to proceed on
  the other part of the patch for addressing the other 64bit issues.
On
  closer review, we may want to have some typedefs similar to this
block
  and use that for the casting on the pointer math that I replaced
with
  size_t in the previous patch.
 
 I'm going through your patch and trying to figure out if there are
 some real problems (as opposed of an overflow if an URL is longer than
 2 GB).
 
 The only thing really breaking things is the socklen_t/size_t
 mismatch, especially in struct addrinfo. Depending on the IPv6 support
 flavor (RFC 2133 v. RFC 3493), struct addrinfo field ai_addrlen is
 either size_t (potentially 64 bit) or socklen_t.
 
 Now we have the msg_addrlen() function - it was marked as deprecated,
 but I never got around to remove it from the API - which actually
 returns pointer to the ai_addrlen field inside msg_t object. So, on
 64-bit systems with RFC 2133 struct addrinfo we actually take a
 pointer to size_t, a 64-bit int and treat it as a pointer to
 socklen_t, 32-bit int. With little-endian processors, it works fine
 unless you got a struct sockaddr longer than 4GB, butit does not work
 at all if the 64-bit processor is big-endian.
 
 Kai, what about removing the msg_addr() and msg_addrlen()  - they are
 not used by anything inside library nor they are tested anymore, and
 they have been marked as deprecated since 1.11.8...
 
 --
 Pekka.Pessi mail at nokia.com


msvchashvalue2.patch
Description: msvchashvalue2.patch
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip changes (2006-09-11)

[Michael Jerris]

 ./libsofia-sip-ua/sdp/sdp_parse.c 1033
-  int i, n, N;
+  size_t i;
+  int n, N;
hunk ./libsofia-sip-ua/sresolv/sres.c 68
+extern int inet_pton(int af, char const *src, void *dst);
+extern const char *inet_ntop(int af, void const *src,
+ char *dst, size_t size);
}

Context:

[sres.c: small fixes with size_t usage. 
[EMAIL PROTECTED]
 
 Note that sresolv module tries very hard not to depend on sofia-sip/su.h.
] 
[fix safe to fix msvc 2005 level 3 warnings with /w64 by changing many types of 
variables internal to fuctions, to be more strongly typed to function 
prototypes and returns
[EMAIL PROTECTED] 
[fix msvc 2005 level 3 warnings
[EMAIL PROTECTED] 
[soa.c: soa_set_sdp() uses now issize_t, too.
[EMAIL PROTECTED] 
[su_win32/sofia-sip/su_configure.h: take 3 on defining suitable values for 
win32/win64. Now use __w64 as explained by Michael Jerris.
[EMAIL PROTECTED] 
[win32/sofia-sip/su_configure.h: using values from basetsd.h
[EMAIL PROTECTED]
 
 Always defining isize_t, usize_t as size_t on Windows, issize_t as ssize_t. 
 
 Note that limits.h with _POSIX_ on VC uses 16-bit values for SSIZE_MAX,
 for instance.
] 
[sofia-sip/su_types.h: documenting isize_t, issize_t, and usize_t.
[EMAIL PROTECTED] 
[Added a workaround for platforms such as VC6 that do not support %z modifier 
for printing size/ssize_t (a C99 feature).
[EMAIL PROTECTED] 
[Avoid preprocessor warning in tport about redefining version.
[EMAIL PROTECTED] 
[Allow test_nta.c to be built without dirent.h interface.
[EMAIL PROTECTED] 
[Fixed a segfault handling an invalid tagtype in su_taglist.
[EMAIL PROTECTED] 
[Warn users that NUTAG_IDENTITY is not yet implemented.
[EMAIL PROTECTED] 
[Updated TODO list.
[EMAIL PROTECTED] 
[Added ability to select transport to use by passing NTATAG_TPORT() to 
nta_outgoing_*create() functions.
Kai Vehmanen [EMAIL PROTECTED]**20060907132931] 
[RELEASE: describing nutag_early_answer, isize_tco.
[EMAIL PROTECTED] 
[nua: optionally include answer in 1XX response.
[EMAIL PROTECTED]
 
 The SDP answer is included in non-realiable 1XX response, if
 NUTAG_EARLY_ANSWER(1) is included in nua_response() tags, or the user SDP is
 specified with SOATAG_USER_SDP() or SOATAG_USER_SDP_STR() in nua_response()
 tags. 
 
 test_basic_call.c: added test_basic_call_2() for testing the call setup
 where 180 contains the answer and the SDP in 200 OK is ignored.
] 
[win32/sofia-sip/su_configure.h: fixed SU_INTPTR_T definition. Defining 
SIZE_MAX and SSIZE_MAX if needed.
[EMAIL PROTECTED] 
[su_tag_inline.h: fixed t_xtra() return type (size_t instead of int).
[EMAIL PROTECTED] 
[su: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Internally using size_t.
] 
[nth_client.c: not using su_salloc().
[EMAIL PROTECTED] 
[nua: using isize_t, size_t.
[EMAIL PROTECTED] 
[nta: using usize_t in tport API.
[EMAIL PROTECTED] 
[sres.c: using size_t.
[EMAIL PROTECTED] 
[su_configure.h.in, sac-su2.m4: added compatibility types for size parameters.
[EMAIL PROTECTED]
 
 Sofia-SIP 1.12 API passes size in int or unsigned int in numerous places.
 Now use typedes isize_t (used instead of int), usize_t (used instead of
 unsigned) and issize_t (used instead of int when returning signed size).
 
 With --disable-size-compat, make API to use size_t or ssize_t instead of
 int/unsigned int.
 
 win32/sofia-sip/su_configure.h: define suitable values for isize_t, usize_t
 and issize_t.
] 
[url module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED] 
[msg module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
] 
[tport module: using isize_t/usize_t/issize_t in API.
[EMAIL PROTECTED] 
[soa module: using isize_t/usize_t/issize_t in API.
[EMAIL PROTECTED] 
[sdp module: using isize_t in API.
[EMAIL PROTECTED] 
[iptsec: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Fixed basic authentication crashing with too long username/password.
] 
[sip module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED] 
[bnf module: using isize_t and issize_t in API.
[EMAIL PROTECTED] 
[http: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Internally using size_t/ssize_t.
] 
[tport module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Using internally size_t.
] 
[stun: using isize_t, usize_t, and issize_t in API.
[EMAIL PROTECTED]
 
 Internally, this looks like all mess. 
] 
[tport.c, nta.c. nth_client.c: using msg_addr() sparingly.
[EMAIL PROTECTED] 
[ipt: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Internally using size_t.
] 
[fix msvc warnings for hash_value_t
Michael Jerris [EMAIL PROTECTED]**20060904182655] 
[Using su_socket() and su_socket_t. Added socket_tag_class, tag_socket_v(), 
tag_socket_vr().
[EMAIL PROTECTED] 
[su module: use socklen_t where appropriate.
[EMAIL PROTECTED]
 
 su.h, su_localinfo.h (li_addrlen), su_addrinfo.c, su_localinfo.c.
] 
[htable.h: allow template user to define hash value type.
[EMAIL PROTECTED]
 
 Added HTABLE_DECLARE_WITH

[Sofia-sip-devel] Yet another patch!

[Michael Jerris]

+#endif
hunk ./libsofia-sip-ua/su/su_port.c 468
-su_close(self-sup_mbox[0]); self-sup_mbox[0] = SOCKET_ERROR;
+su_close(self-sup_mbox[0]); self-sup_mbox[0] = (su_socket_t)SOCKET_ERROR;
hunk ./libsofia-sip-ua/su/su_port.c 470
-su_close(self-sup_mbox[1]); self-sup_mbox[1] = SOCKET_ERROR;
+su_close(self-sup_mbox[1]); self-sup_mbox[1] = (su_socket_t)SOCKET_ERROR;
hunk ./libsofia-sip-ua/su/su_port.c 1162
+#if HAVE_POLL
hunk ./libsofia-sip-ua/su/su_port.c 1164
+#endif
hunk ./libsofia-sip-ua/tport/tport.c 539
-tp-tp_socket = SOCKET_ERROR;
+tp-tp_socket = (su_socket_t)SOCKET_ERROR;
hunk ./libsofia-sip-ua/tport/tport.c 1006
-  self-tp_socket = -1;
+  self-tp_socket = (su_socket_t)-1;
hunk ./libsofia-sip-ua/tport/tport.c 2343
-  su_socket_t s = SOCKET_ERROR, l = pri-pri_primary-tp_socket;
+  su_socket_t s = (su_socket_t)SOCKET_ERROR, l = pri-pri_primary-tp_socket;
hunk ./libsofia-sip-ua/tport/tport.c 3869
-  unsigned i, reported, callbacks;
+  unsigned i, callbacks;
+  int reported;
hunk ./libsofia-sip-ua/tport/tport.c 3915
-  unsigned i, reported, callbacks;
+  unsigned i, callbacks;
+  int reported;
hunk ./libsofia-sip-ua/tport/tport.c 4121
-int resolved = 0, sulen, cmp;
+int resolved = 0, cmp;
+   unsigned sulen;
hunk ./libsofia-sip-ua/tport/tport.c 4233
-  int salen, cmp;
+  int cmp;
+  unsigned salen;
hunk ./libsofia-sip-ua/tport/tport_type_udp.c 226
-recv(self-tp_socket, sample, 1, 0);
+recv(self-tp_socket, (void *)sample, 1, 0);
hunk ./libsofia-sip-ua/url/url.c 143
-static char *url_canonize2(char *d, char const *s, size_t n, 
+static char *url_canonize2(char *d, char const *s, issize_t n, 
hunk ./libsofia-sip-ua/url/url.c 305
-char *url_canonize2(char *d, char const *s, size_t n, 
+char *url_canonize2(char *d, char const *s, issize_t n, 
hunk ./libsofia-sip-ua/url/url.c 360
-char *url_canonize3(char *d, char const *s, size_t n, 
+char *url_canonize3(char *d, char const *s, issize_t n, 
hunk ./libsofia-sip-ua/url/url.c 366
-for (;*s  s - s0  (unsigned)n; d++, s++) 
+for (;*s  s - s0  n; d++, s++) 
hunk ./libsofia-sip-ua/url/url.c 370
-  for (;*s  s - s0  (unsigned)n; d++, s++) {
+  for (;*s  s - s0  n; d++, s++) {
hunk ./libsofia-sip-ua/url/url.c 898
-  assert(b - buffer == m - n);
+  assert((size_t)(b - buffer) == (size_t)(m - n));
hunk ./win32/config.h.in 451
+/* Temorarily disable high frequency, low value warnings.  We may still want 
to re-enable and fix these */
+#pragma warning( disable : 4132 4100 4127 4295 4152 )
}

Context:

[su_tagarg.h: ta_start() initializes all of ta_list in all cases.
[EMAIL PROTECTED] 
[Fixed build error caused by undefined REF_MAX.
[EMAIL PROTECTED] 
[Doxygen documentation fixes.
[EMAIL PROTECTED] 
[msg module: using size_t. Checking for input value for offsets.
[EMAIL PROTECTED] 
[msg module: updated documentation.
[EMAIL PROTECTED] 
[iptsec: fixed doxygen errors.
[EMAIL PROTECTED] 
[features: made most feature variables non-const. Fixed documentation.
[EMAIL PROTECTED] 
[su_alloc.c: defining REF_MAX.
[EMAIL PROTECTED] 
[more msvc warning fixes
[EMAIL PROTECTED] 
[Fixed build error caused by undefined REF_MAX.
[EMAIL PROTECTED] 
[libsofia-sip-ua: more 64-bit fixes: internally using size_t instead of int.
[EMAIL PROTECTED] 
[sres.c: small fixes with size_t usage. 
[EMAIL PROTECTED]
 
 Note that sresolv module tries very hard not to depend on sofia-sip/su.h.
] 
[fix safe to fix msvc 2005 level 3 warnings with /w64 by changing many types of 
variables internal to fuctions, to be more strongly typed to function 
prototypes and returns
[EMAIL PROTECTED] 
[fix msvc 2005 level 3 warnings
[EMAIL PROTECTED] 
[soa.c: soa_set_sdp() uses now issize_t, too.
[EMAIL PROTECTED] 
[su_win32/sofia-sip/su_configure.h: take 3 on defining suitable values for 
win32/win64. Now use __w64 as explained by Michael Jerris.
[EMAIL PROTECTED] 
[win32/sofia-sip/su_configure.h: using values from basetsd.h
[EMAIL PROTECTED]
 
 Always defining isize_t, usize_t as size_t on Windows, issize_t as ssize_t. 
 
 Note that limits.h with _POSIX_ on VC uses 16-bit values for SSIZE_MAX,
 for instance.
] 
[sofia-sip/su_types.h: documenting isize_t, issize_t, and usize_t.
[EMAIL PROTECTED] 
[Added a workaround for platforms such as VC6 that do not support %z modifier 
for printing size/ssize_t (a C99 feature).
[EMAIL PROTECTED] 
[Avoid preprocessor warning in tport about redefining version.
[EMAIL PROTECTED] 
[Allow test_nta.c to be built without dirent.h interface.
[EMAIL PROTECTED] 
[Fixed a segfault handling an invalid tagtype in su_taglist.
[EMAIL PROTECTED] 
[Warn users that NUTAG_IDENTITY is not yet implemented.
[EMAIL PROTECTED] 
[Updated TODO list.
[EMAIL PROTECTED] 
[Added ability to select transport to use by passing NTATAG_TPORT() to 
nta_outgoing_*create() functions.
Kai Vehmanen [EMAIL PROTECTED]**20060907132931] 
[RELEASE: describing nutag_early_answer, isize_tco.
[EMAIL PROTECTED] 
[nua: optionally include answer in 1XX response.
[EMAIL PROTECTED

Re: [Sofia-sip-devel] (no subject)

[Michael Jerris]

This issue is fixed in the latest darcs
tree. The tpipv6.h is from the preview ipv6 code that in newer sdks (ie
the ones that come with vs 2005) have all that code in Winsock2.h.



To fix this in your local copy, change
su.h to be like:



# if defined(IPPROTO_IPV6)

/* IPv6 defined in ws2tcpip.h */

# elif SU_HAVE_IN6 

# include tpipv6.h /* From IPv6 Tech
Preview */

# else

# error Winsock with IPv6 support required

# endif





And sres.c to be like 



#if !defined(IPPROTO_IPV6)

#if HAVE_SIN6

#include tpipv6.h

#else

#if !defined(__MINGW32__)

struct sockaddr_storage {

 short ss_family;

 char ss_pad[126];

};

#endif

#endif

#endif





Mike

















From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of PICT BEPROJECT
Sent: Wednesday, September 13,
2006 7:13 AM
To:
sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] (no
subject)





 
hi!..
we are working on sofia
stack based on windows platform .
we are facing a lot of errors in the file SIP_DIG.C . Th errrors are attached
in file ERRORS SOFIA.TXT attached here with .
Looking for your support
Thnax.. 

Mayur Toshniwal 
Varun Jain 
Ameya Swar 

PICT










-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] NUTAG_IDENTITY and contact header

[Michael Jerris]

It appears that from everything that is said, the current tags regarding
user and identity tend to only work with something that we register to.
What about something that we do not need or want to register too, but
still need to serve up a specific identity and auth profile to when
registering, ect.

Mike

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Pekka Pessi
 Sent: Thursday, September 14, 2006 5:13 AM
 To: Henrik Nordstrom
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] NUTAG_IDENTITY and contact header
 
 On 9/14/06, Henrik Nordstrom [EMAIL PROTECTED] wrote:
   I added yesterday a tag called NUTAG_M_USERNAME() to nua ('M'
stands
   for contact). Its contents will be used as the URL username when
the
   stack generates the Contact header for nua_register().  Hope it
helps.
 
  Looks like a good start. But if you have specified this to
  nua_register(), how does one bring the generated contact adresses
  forward to nua_invite() and other SIP operations which require a
local
  contact?
 
 That is the job for NUTAG_IDENTITY().
 
 Just now the contact is selected based on the From header (when
 sending INVITE) or To header (when responding to INVITE). If the
 From/To URI matches with the AoR URI used with nua_register(), the
 contact from that registration is used. Or so it is supposed to work.
 
 --
 Pekka.Pessi mail at nokia.com
 


-
 Using Tomcat but need to do more? Need to support web services,
security?
 Get stuff done quickly with pre-integrated technology to make your job
 easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo

http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip changes (2006-09-19)

[Michael Jerris]

 
 One more round, this file includes 3 patches, one that lets it compile
 again on windows, 1 that resolves the level 3 64 bit warnings (beware
of
 what I did for tport.c, that one needs some review), and one that
resolves
 the remaining level 4 warnings.
 
 The first patch also includes a fix: pass correct url, not param to
 url_has_param in the file nta.c
 
 Mike
 
  -Original Message-
  From: [EMAIL PROTECTED]
[mailto:sofia-sip-
  [EMAIL PROTECTED] On Behalf Of Sofia-SIP Darcs
 Changes
  Sent: Tuesday, September 19, 2006 2:56 PM
  To: sofia-sip-devel@lists.sourceforge.net
  Subject: [Sofia-sip-devel] sofia-sip changes (2006-09-19)
 
  This posting was generated automatically from darcs repo
  http://sofia-sip.org/repos.
 
  Tue Sep 19 19:30:42 EEST 2006  [EMAIL PROTECTED]
* torture_sip.c: removed tests for deprecated q-parameter of
Accept-
  Contact header.
 
  M ./libsofia-sip-ua/sip/torture_sip.c -3 +3
 
  Tue Sep 19 17:35:39 EEST 2006  [EMAIL PROTECTED]
* torture_sip.c: added msg_copy() to test_manipulation()
 
  M ./libsofia-sip-ua/sip/torture_sip.c -2 +6
 
  Thu Sep  7 16:10:37 EEST 2006  [EMAIL PROTECTED]
* torture_sip.c: added tests for header manipulation.
 
  M ./libsofia-sip-ua/sip/torture_sip.c +40
 
  Thu Sep  7 16:09:18 EEST 2006  [EMAIL PROTECTED]
* torture_sip.c: moved main to the end.
 
  M ./libsofia-sip-ua/sip/torture_sip.c -97 +67
 
  Thu Sep  7 16:08:12 EEST 2006  [EMAIL PROTECTED]
* sip_util.c: sip_aor_strip() now uses memmove() when copying
  overlapping strings.
 
  M ./libsofia-sip-ua/sip/sip_util.c -1 +1
 
  Tue Sep 19 19:23:31 EEST 2006  [EMAIL PROTECTED]
* nua_session.c, test_100rel.c: allow restart (authentication) of
 PRACK
  request. test it, too.
 
  M ./libsofia-sip-ua/nua/nua_session.c -67 +181
  M ./libsofia-sip-ua/nua/test_100rel.c -265 +537
  M ./libsofia-sip-ua/nua/test_nua.c -3 +14
  M ./libsofia-sip-ua/nua/test_nua.h -1 +13
 
  Tue Sep 19 16:45:37 EEST 2006  [EMAIL PROTECTED]
* nua_stack.c: nua_stack_event() now allows sending after-1.12.0
 events
  to application
 
  M ./libsofia-sip-ua/nua/nua_stack.c -2 +6
 
  Tue Sep 19 18:37:27 EEST 2006  [EMAIL PROTECTED]
* Added comment on TAG_NULL vs TAG_END.
 
  M ./libsofia-sip-ua/su/sofia-sip/su_tag.h -2 +2
 
  Tue Sep 19 16:33:29 EEST 2006  [EMAIL PROTECTED]
* Fixes for using size_t/ssize_t/su_socket_t and
  isize_t/usize_t/issize_t.
 
su, sip, msg, http, url, sdp, soa, etc..
 
  M ./libsofia-sip-ua/http/http_header.c -9 +14
  M ./libsofia-sip-ua/iptsec/auth_module.c -17 +23
  M ./libsofia-sip-ua/iptsec/sofia-sip/auth_plugin.h -6 +6
  M ./libsofia-sip-ua/msg/msg_mclass.c -15 +17
  M ./libsofia-sip-ua/msg/msg_parser.c -4 +10
  M ./libsofia-sip-ua/msg/sofia-sip/msg_types.h +2
  M ./libsofia-sip-ua/nta/nta.c -9 +8
  M ./libsofia-sip-ua/nta/portbind.c -2 +2
  M ./libsofia-sip-ua/nta/sl_utils_print.c -12 +12
  M ./libsofia-sip-ua/nta/sofia-sip/sl_utils.h -1 +1
  M ./libsofia-sip-ua/nta/test_nta.c -2 +2
  M ./libsofia-sip-ua/nth/nth_server.c -2 +6
  M ./libsofia-sip-ua/nth/nth_test.c -3 +3
  M ./libsofia-sip-ua/nua/test_nat.c -12 +12
  M ./libsofia-sip-ua/sdp/sdp_parse.c -14 +16
  M ./libsofia-sip-ua/sdp/sofia-sip/sdp.h -2 +3
  M ./libsofia-sip-ua/sip/sip_basic.c -2 +2
  M ./libsofia-sip-ua/sip/sip_parser.c -6 +11
  M ./libsofia-sip-ua/soa/soa.c -9 +9
  M ./libsofia-sip-ua/soa/soa_static.c -5 +7
  M ./libsofia-sip-ua/sresolv/sres.c -41 +72
  M ./libsofia-sip-ua/sresolv/sres_blocking.c -9 +12
  M ./libsofia-sip-ua/sresolv/sresolv.c -16 +17
  M ./libsofia-sip-ua/sresolv/test_sresolv.c -4 +4
  M ./libsofia-sip-ua/stun/stun.c -14 +13
  M ./libsofia-sip-ua/stun/stun_common.c -2 +3
  M ./libsofia-sip-ua/stun/stun_dns.c -16 +5
  M ./libsofia-sip-ua/stun/stun_mini.c -5 +5 r3
  M ./libsofia-sip-ua/su/sofia-sip/su.h -13 +34
  M ./libsofia-sip-ua/su/sofia-sip/su_alloc_stat.h -3 +3
  M ./libsofia-sip-ua/su/sofia-sip/su_strlst.h -1 +1
  M ./libsofia-sip-ua/su/sofia-sip/su_vector.h -4 +4
  M ./libsofia-sip-ua/su/sofia-sip/tstdef.h -2 +2
  M ./libsofia-sip-ua/su/su.c -14 +68
  M ./libsofia-sip-ua/su/su_alloc.c -10 +13
  M ./libsofia-sip-ua/su/su_localinfo.c -1 +5
  M ./libsofia-sip-ua/su/su_port.c -4 +4
  M ./libsofia-sip-ua/su/su_proxy.c -2 +2
  M ./libsofia-sip-ua/su/su_strlst.c -1 +1
  M ./libsofia-sip-ua/su/su_vector.c -1 +1
  M ./libsofia-sip-ua/su/su_wait.c -2 +2
  M ./libsofia-sip-ua/tport/tport.c -34 +30
  M ./libsofia-sip-ua/tport/tport_internal.h -4 +4
  M ./libsofia-sip-ua/tport/tport_sigcomp.c -1 +1
  M ./libsofia-sip-ua/tport/tport_stub_sigcomp.c -1 +1
  M ./libsofia-sip-ua/tport/tport_type_sctp.c -7 +1
  M ./libsofia-sip-ua/tport/tport_type_tcp.c -4 +5
  M ./libsofia-sip-ua/tport/tport_type_udp.c -2 +2
  M ./libsofia-sip-ua/url/url.c -24 +26
 

Re: [Sofia-sip-devel] sofia-sip changes (2006-09-26)

[Michael Jerris]

.
[EMAIL PROTECTED] 
[New interface for su_glib. The old one is still there but deprecated. 
libsofia-sip-ua-glib interface version to 1:0:1.
[EMAIL PROTECTED] 
[Big update to to nua_glib. Separated nua_glib operator code to 
nua_glib_oper.c, improved documentation, and error handling.
[EMAIL PROTECTED] 
[Fixed doxygen documentation for libsofia-sip-ua-glib (closed bug #1485968. 
Added example code to the su_glib doxygen documentation.
[EMAIL PROTECTED] 
[su_tagarg.h: ta_start() initializes all of ta_list in all cases.
[EMAIL PROTECTED] 
[Fixed build error caused by undefined REF_MAX.
[EMAIL PROTECTED] 
[Doxygen documentation fixes.
[EMAIL PROTECTED] 
[msg module: using size_t. Checking for input value for offsets.
[EMAIL PROTECTED] 
[msg module: updated documentation.
[EMAIL PROTECTED] 
[iptsec: fixed doxygen errors.
[EMAIL PROTECTED] 
[features: made most feature variables non-const. Fixed documentation.
[EMAIL PROTECTED] 
[su_alloc.c: defining REF_MAX.
[EMAIL PROTECTED] 
[more msvc warning fixes
[EMAIL PROTECTED] 
[Fixed build error caused by undefined REF_MAX.
[EMAIL PROTECTED] 
[libsofia-sip-ua: more 64-bit fixes: internally using size_t instead of int.
[EMAIL PROTECTED] 
[sres.c: small fixes with size_t usage. 
[EMAIL PROTECTED]
 
 Note that sresolv module tries very hard not to depend on sofia-sip/su.h.
] 
[fix safe to fix msvc 2005 level 3 warnings with /w64 by changing many types of 
variables internal to fuctions, to be more strongly typed to function 
prototypes and returns
[EMAIL PROTECTED] 
[fix msvc 2005 level 3 warnings
[EMAIL PROTECTED] 
[soa.c: soa_set_sdp() uses now issize_t, too.
[EMAIL PROTECTED] 
[su_win32/sofia-sip/su_configure.h: take 3 on defining suitable values for 
win32/win64. Now use __w64 as explained by Michael Jerris.
[EMAIL PROTECTED] 
[win32/sofia-sip/su_configure.h: using values from basetsd.h
[EMAIL PROTECTED]
 
 Always defining isize_t, usize_t as size_t on Windows, issize_t as ssize_t. 
 
 Note that limits.h with _POSIX_ on VC uses 16-bit values for SSIZE_MAX,
 for instance.
] 
[sofia-sip/su_types.h: documenting isize_t, issize_t, and usize_t.
[EMAIL PROTECTED] 
[Added a workaround for platforms such as VC6 that do not support %z modifier 
for printing size/ssize_t (a C99 feature).
[EMAIL PROTECTED] 
[Avoid preprocessor warning in tport about redefining version.
[EMAIL PROTECTED] 
[Allow test_nta.c to be built without dirent.h interface.
[EMAIL PROTECTED] 
[Fixed a segfault handling an invalid tagtype in su_taglist.
[EMAIL PROTECTED] 
[Warn users that NUTAG_IDENTITY is not yet implemented.
[EMAIL PROTECTED] 
[Updated TODO list.
[EMAIL PROTECTED] 
[Added ability to select transport to use by passing NTATAG_TPORT() to 
nta_outgoing_*create() functions.
Kai Vehmanen [EMAIL PROTECTED]**20060907132931] 
[RELEASE: describing nutag_early_answer, isize_tco.
[EMAIL PROTECTED] 
[nua: optionally include answer in 1XX response.
[EMAIL PROTECTED]
 
 The SDP answer is included in non-realiable 1XX response, if
 NUTAG_EARLY_ANSWER(1) is included in nua_response() tags, or the user SDP is
 specified with SOATAG_USER_SDP() or SOATAG_USER_SDP_STR() in nua_response()
 tags. 
 
 test_basic_call.c: added test_basic_call_2() for testing the call setup
 where 180 contains the answer and the SDP in 200 OK is ignored.
] 
[win32/sofia-sip/su_configure.h: fixed SU_INTPTR_T definition. Defining 
SIZE_MAX and SSIZE_MAX if needed.
[EMAIL PROTECTED] 
[su_tag_inline.h: fixed t_xtra() return type (size_t instead of int).
[EMAIL PROTECTED] 
[su: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Internally using size_t.
] 
[nth_client.c: not using su_salloc().
[EMAIL PROTECTED] 
[nua: using isize_t, size_t.
[EMAIL PROTECTED] 
[nta: using usize_t in tport API.
[EMAIL PROTECTED] 
[sres.c: using size_t.
[EMAIL PROTECTED] 
[su_configure.h.in, sac-su2.m4: added compatibility types for size parameters.
[EMAIL PROTECTED]
 
 Sofia-SIP 1.12 API passes size in int or unsigned int in numerous places.
 Now use typedes isize_t (used instead of int), usize_t (used instead of
 unsigned) and issize_t (used instead of int when returning signed size).
 
 With --disable-size-compat, make API to use size_t or ssize_t instead of
 int/unsigned int.
 
 win32/sofia-sip/su_configure.h: define suitable values for isize_t, usize_t
 and issize_t.
] 
[url module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED] 
[msg module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
] 
[tport module: using isize_t/usize_t/issize_t in API.
[EMAIL PROTECTED] 
[soa module: using isize_t/usize_t/issize_t in API.
[EMAIL PROTECTED] 
[sdp module: using isize_t in API.
[EMAIL PROTECTED] 
[iptsec: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED]
 
 Fixed basic authentication crashing with too long username/password.
] 
[sip module: using isize_t, usize_t, issize_t in API.
[EMAIL PROTECTED] 
[bnf module: using isize_t and issize_t in API.
[EMAIL PROTECTED] 
[http: using isize_t, usize_t, issize_t in API.
[EMAIL

[Sofia-sip-devel] Patches from irc, notifier: only send 100 when needed, and sdp in 200 when 183 w/o 100rel.

[Michael Jerris]

Pekka- 

These are the patches from irc from today.  Thanks again for
your help.

Mike


http://www.freeswitch.org/eg/ircpatches.txt



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Patches from irc, notifier: only send 100 when needed, and sdp in 200 when 183 w/o 100rel.

[Michael Jerris]

I this case, it appears to be exactly that, the cisco implementation
very clearly states in a debug message that it doesn't know what to do
when it gets the 200 ok w/o sdp, and immediately sends a bye.  Can we
add a tag to force sending sdp in that packet that can be passed
through, also, can you toss me an rfc reference about how we are not
supposed to send in the 200 ok after the 183 so we can file the bug with
cisco.

Thanks
Mike


 -Original Message-
 From: Pekka Pessi [mailto:[EMAIL PROTECTED]
 Sent: Monday, October 09, 2006 6:19 AM
 To: Michael Jerris
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: Patches from irc, notifier: only send 100 when needed,
and
 sdp in 200 when 183 w/o 100rel.
 
 On 10/7/06, Michael Jerris [EMAIL PROTECTED] wrote:
  These are the patches from irc from today.  Thanks again for
  your help.
 
 Thanks.
 
 Did you get everything working, or is there still some problems with
 the 100rel case?
 
 Including SDP in 200 OK even after it has been sent in a PRACKed 183
 might confuse some implementations.  If it is needed for
 bug-compatibility the stack could make the decision based on the
 User-Agent contents.
 
 --
 Pekka.Pessi mail at nokia.com

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Freebsd 5.3 build fixes and windows warning fixes.

[Michael Jerris]

Yet another patch.  

http://www.jerris.com/buildfixes.txt

Fixes new warnings on windows, and allows build on FreeBSD 5.3.

Thanks
Mike


New patches:

[msvc warnings fixes
[EMAIL PROTECTED] {
hunk ./libsofia-sip-ua/sip/sip_tag_class.c 425
-  else if (n == hc-hc_len  strncasecmp(hnv, hc-hc_name, n) == 0)
+  else if (n == (size_t)hc-hc_len  strncasecmp(hnv, hc-hc_name, n) == 
0)
hunk ./libsofia-sip-ua/su/sofia-sip/su_strlst.h 84
-SU_DLL char const *su_strlst_item(su_strlst_t const *, unsigned i);
+SU_DLL char const *su_strlst_item(su_strlst_t const *, usize_t i);
hunk ./libsofia-sip-ua/su/su_strlst.c 456
-char const *su_strlst_item(su_strlst_t const *self, unsigned i)
+char const *su_strlst_item(su_strlst_t const *self, usize_t i)
}

[Freebsd 5.3 build fix
[EMAIL PROTECTED] {
hunk ./libsofia-sip-ua/su/sofia-sip/su_errno.h 61
-#if defined(__APPLE_CC__) || defined(__OpenBSD__) || defined(__NetBSD__)
+#if defined(__APPLE_CC__) || defined(__OpenBSD__) || defined(__NetBSD__) || 
defined(__FreeBSD__)
}

[msvc warnings fixes
[EMAIL PROTECTED] {
hunk ./win32/config.h.in 453
-#pragma warning( disable : 4132 4100 4127 4295 4152 )
+#pragma warning( disable : 4132 4100 4127 4295 4152 4114)
}

[Freebsd 5.3 build fix
[EMAIL PROTECTED] {
hunk ./libsofia-sip-ua/su/su_uniqueid.c 62
+
+#if HAVE_SYS_TIME_H
+#include sys/time.h
+#endif
}

Context:

[su: updated documentation of debugging logs.
[EMAIL PROTECTED] 
[RELEASE: updated.
[EMAIL PROTECTED] 
[nua_session.c: clarified the offer/answer code when responding to INVITE.
[EMAIL PROTECTED] 
[nua: added NUTAG_INCLUDE_EXTRA_SDP().
[EMAIL PROTECTED] 
[Remove underlying libraries from pkg-config Libs
[EMAIL PROTECTED]
 
 The underlying libraries are only needed to link against sofia-sip-ua as 
 a static library. In addition, this is causing build failures/extraneous 
 dependencies in packages relying on sofia-sip.
 
] 
[Fix unresolved symbols in libsofia-sip-ua-glib
[EMAIL PROTECTED] 
[fixed missing defines + debugs
[EMAIL PROTECTED] 
[updated Makefile.am to contain tests for OSX
[EMAIL PROTECTED] 
[torture_su_root_osx follows now torture_su_root code
[EMAIL PROTECTED] 
[added test_su_osx for OSX run loop testing
[EMAIL PROTECTED] 
[nua_notifier.c: do not send immediate NOTIFY to an established dialog. 
[EMAIL PROTECTED] 
[test_su.c: do not enter.
[EMAIL PROTECTED] 
[nua_session: bugfix. Now sending answer in 200 OK too if it was already in 1XX 
without 100rel.
[EMAIL PROTECTED] 
[updated and more debug
[EMAIL PROTECTED] 
[more debugging output
[EMAIL PROTECTED] 
[OSX run loop rewritten and works partially
[EMAIL PROTECTED] 
[configure.ac, m4: autoupdated.
[EMAIL PROTECTED] 
[SIP_HEADER_INIT(): removed gcc warning about comma expression.
[EMAIL PROTECTED] 
[su_port.c: fixed registering high-priority events when epoll is not available.
[EMAIL PROTECTED] 
[sofia-sip.spec.in: using --with glib gobject openssl
[EMAIL PROTECTED]
 
 Autodetecting decent glib gobject openssl using pkg-config. Force
 BuildRequires with --with flags.
 
 Now configure generates a spec file with version number in its name. 
 
 Including su-glib in glib package even if gobject interface cannot be built.
] 
[Makefile.am: do not rebuild manpages
[EMAIL PROTECTED] 
[utils/Doxyfile.build.in: fixed make manpages using @INCLUDE_PATH 
[EMAIL PROTECTED] 
[sip_aor_strip(): using url_strip_transport(), url_strip_param_string().
[EMAIL PROTECTED] 
[nta_msg_request_complete(): create To header from request-URI, if needed.
[EMAIL PROTECTED] 
[nua_param.c: when converting NUTAG_URL() to To header remove extra parameters.
[EMAIL PROTECTED]
 
 Added test for encoding header from URL query string (in test_simple.c)
] 
[Fixed a silly typo in nua.c.
[EMAIL PROTECTED] 
[nua.h, nua.c: added nua_magic(), too. Renamed nua_handle_fetch() as 
nua_handle_magic().
[EMAIL PROTECTED] 
[sip: added sip_url_query_as_taglist().
[EMAIL PROTECTED] 
[nta: nta_msg_request_complete() now adds header from request-URI query part to 
request message
[EMAIL PROTECTED]
 
 Headers as well as method parameter are stripped away from request-URI.
] 
[msg: added msg_header_parse_str()
[EMAIL PROTECTED] 
[url: added url_query_as_header_string(), url_unescape_to().
[EMAIL PROTECTED] 
[url: added url_strip_param_string().
[EMAIL PROTECTED] 
[sip_header.h: added sip_headers_as_url_query()
[EMAIL PROTECTED] 
[add nua_handle_fetch to get the magic from nh
[EMAIL PROTECTED] 
[Added doxygen alias @VERSION_1_12_4.
[EMAIL PROTECTED] 
[sip: fixed sip_header_as_string() prototype.
[EMAIL PROTECTED] 
[nua: fixed registration without Contact.
[EMAIL PROTECTED] 
[nua: added nua_handle_make_replaces(), nua_handle_by_replaces().
[EMAIL PROTECTED] 
[test_register.c: added test for nua_i_register and nua_respond() with 
NUTAG_WITH().
[EMAIL PROTECTED] 
[su_taglist.c: fixed tl_find_last(), added tests for it.
[EMAIL PROTECTED] 
[sip_refer.c: fixed sip_referred_by_d(): accept no more syntax errors.
[EMAIL PROTECTED] 
[sip_refer.c: sip_refer_d() now fixes URLs with 

[Sofia-sip-devel] Segfault

[Michael Jerris]

I have the following backtrace from a segfault:
http://pastebin.ca/197211


Caused by the following packets:
http://grumpy.asteriasgi.com/~krice/crash.txt   


Any help would be much appretiated.

Thanks
Mike

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] fix build without glib

[Michael Jerris]

Patch attached




noglib.patch
Description: noglib.patch
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] SIPTAG_HEADER_STR

[Michael Jerris]

When using SIPTAG_HEADER_STR in nua_invite, and possibly elsewhere, it
is inserting the header after the Content-Length header, before the
body.  I think this is causing some serious issues when calling some
phones.

Mike

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] build warning in su_alloch.h

[Michael Jerris]

Patch to not use  __attribute__((__malloc__)) on functions that don't
return pointers from su_alloc.h.

This causes build errors when the consumer program has -Wall -Werror.

http://www.freeswitch.org/eg/attrmalloc.patch

Mike

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] build warning in su_alloch.h

[Michael Jerris]

Additionally, we should probably use something like :

#ifdef __GNUC__

#define SOFIA_GCC_VERSION (__GNUC__ * 1 \
 + __GNUC_MINOR__ * 100 \
 + __GNUC_PATCHLEVEL__)

#if SOFIA_GCC_VERSION = 300200
#define SOFIA_GCC_ATTR_MALLOC  __attribute__ ((__malloc__))
#endif

#else
#define SOFIA_GCC_ATTR_MALLOC
#endif

Or, alternatively a configure check to determine if the attribute is
available (something similar to
http://mail.nl.linux.org/tinc-cvs/2003-07/msg00141.html) as these are
gcc specific and could potentially cause issues for other compilers.

Mike


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Michael Jerris
 Sent: Tuesday, November 14, 2006 5:02 PM
 To: sofia-sip-devel@lists.sourceforge.net
 Cc: Pekka Pessi
 Subject: [Sofia-sip-devel] build warning in su_alloch.h
 
 Patch to not use  __attribute__((__malloc__)) on functions that don't
 return pointers from su_alloc.h.
 
 This causes build errors when the consumer program has -Wall -Werror.
 
 http://www.freeswitch.org/eg/attrmalloc.patch
 
 Mike
 


-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
 opinions on IT  business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Carrier Deployment

[Michael Jerris]

 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 
 On 11/22/06, Donak, John [EMAIL PROTECTED] wrote:
   Has Sofia-Sip been deployed in any large carrier-grade products?
 
   Is there any roadmap to support a High Availability Framework (i.e.
 state
  redundancy), which is required for carrier deployment?
 
 That depends on kind of support you are looking for. We see that the
 state redundancy could be implemented at application level, e.g., a
 proxy application could distribute registration state at application
 level, e.g., using reg event.
 
 If you have something else in mind we would like to hear your input.
 

The freeswitch project is very interested in doing this as well, but we
have not begun to tackle it yet.  If you are interested in working with
us, we would be happy to collaborate.

Mike

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] compiling for Windows

[Michael Jerris]

The problem is you don't have the platform sdk installed right.  You
need to make some changes to the msvc config files after you install the
platform sdk so it knows where to look for the headers, and which libs
to include.  That information is in the instructions on the express site
and must be followed closely, or it will not work.  If you would like, I
have a statically linked gawk.exe that I know works, it's available at:
http://www.freeswitch.org/downloads/win32/gawk.exe

Mike

 -Original Message-
 From: Peter P [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, January 02, 2007 2:34 PM
 To: Michael Jerris
 Subject: Re: [Sofia-sip-devel] compiling for Windows
 
 Hello,
 
 On 02/01/07, Michael Jerris [EMAIL PROTECTED] wrote:
 
 
 
 
  In freeswitch, we build natively with msvc2005 without any issues, I
 know that
  others use vc6 also with no issues.  What happens when you try to
build
 w/ msvc?
 
 I tried with this one:
 http://msdn.microsoft.com/vstudio/express/visualc/download/
 And using gawk from cygwin and also gawk from:
 http://unxutils.sourceforge.net
 
 The errors was concerning to Winsock2.h and other errors, I haven't
 looked further (there was a lot, etc.)
 
 Wait! I also downloaded (but I haven't had time to test) the Platform
SDK:
 http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
 I installed only the core, maybe this will fix the problems. I will
 see it tomorrow.
 
 I am not used to Microsoft environments...
 
 So, you can compile sofia with MSVC 2005 (same that I linked?) using
 PSDK after execute the autogen.cmd script? Are you doing it with last
 version of Sofia?
 
 Thanks, and excuse me my not very accurate mails. I don't have the
 machine here, and I was just searching some generic information to
 know if I was doing something in very incorrect way. And looking for
 other experiences (something like, MSVC express edition, and PSDK, and
 Sofia version X, and fix this problem will work)
 
 Thanks!
 
 P

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sresolv: (win32) using IP Helper to get DNSlist before querying the registry

[Michael Jerris]

From: http://msdn2.microsoft.com/en-us/library/aa366073.aspx

The IP Helper API is supported on Microsoft(r) Windows(r) 98, Microsoft
Windows Millennium Edition, on Microsoft Windows NT(r) version 4.0 with
Service Pack 4, Microsoft Windows 2000, Microsoft Windows XP and
Microsoft Windows Server 2003 family. Not all operating systems support
all functions. If an IP Helper function is called on a platform that
does not support the function, ERROR_NOT_SUPPORTED is returned. For more
specific information about which operating systems support a particular
function, refer to the Requirements sections in the documentation

At least some of the functions have the following requirements:

Client Requires Windows Vista, Windows XP, Windows 2000 Professional,
Windows NT Workstation 4.0 SP4 and later, Windows Me, or Windows 98. 
Server Requires Windows Server Longhorn, Windows Server 2003, Windows
2000 Server, or Windows NT Server 4.0 SP4 and later. 
Header Declared in Iphlpapi.h.
 
Library Use Iphlpapi.lib.
 
DLL Requires Iphlpapi.dll.  


This api has been around at least as far back as IE5 (and I believe in
IE4), do you have at least the dll on your system?

Mike




 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Kai Vehmanen
 Sent: Tuesday, January 23, 2007 12:16 PM
 To: 'ext Roman Filonenko'; [EMAIL PROTECTED]
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] sresolv: (win32) using IP Helper to get
 DNSlist before querying the registry
 
 Hi Roman,
 
 thanks for the patch (and sorry for the late reply)!
 
 On 16 Jan 2007, Roman Filonenko wrote:
 We have seen Windows to unexpectedly drop DNS related keys
 (used by sresolv module) from the registry, while settings are
 still available via IP Helper API. This leads to empty DNS
 server list in the sresolv and non-functional application as a
result.
 [...]
 Seems that you already had some build problems with IP Helper
 (for now I've added respective #include under HAVE_WINSOCK2_H)?
 
 I've been trying out the patch today, and it's otherwise ok, but
 I'm still wondering about the availability of IP Helper API. I
 found...
 
 http://msdn.microsoft.com/library/default.asp?url=/library/en-
 us/iphlp/iphlp
 /about_ip_helper.asp
 
 ... but it doesn't mention which SDK's have it. My ancient
 VC6 environment at least didn't.
 
 Anyways, I guess this could be an optional feature (we already
 have code using IP-Helper in su/su_localinfo.c) -- but I'd need
 feedback on selecting the default for win32/config.h.
 
 And I guess the code also needs to be made conditionally built (so
 that I can compile sofia-sip with my VC6 ;)).
 
 --
 [EMAIL PROTECTED] (Kai Vehmanen), Nokia Research Center
 
 


-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
 opinions on IT  business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] XML parsing readily available?

[Michael Jerris]

In freeswitch (www.freeswitch.org http://www.freeswitch.org/ ) we use
a modified version of ez-xml (ezxml.sf.net).  it is a very lightweight
single C file non validating parser (MIT License).  I do not believe
there is an xml parser in sofia-sip itself.

 

Mike

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jan
Van den bosch
Sent: Monday, January 29, 2007 10:17 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] XML parsing readily available?

 

Hi,

Does Sofia-SIP provide functionality to parse an incoming XML payload
(say, an open/closed presence event) or do I have to use an other
library to accomplish this?

Thanks in advance,
Jan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Enable IP helper API for VC2005 build

[Michael Jerris]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Roman Filonenko
 Sent: Tuesday, February 06, 2007 6:50 AM
 To: Pekka Pessi; sofia-sip-devel@lists.sourceforge.net
 Subject: [Sofia-sip-devel] Enable IP helper API for VC2005 build
 
 Pekka,
 
 The IP Helper API is disabled by default now (iphlpapi.h is missing in
 VC6).
 The below patch enables the API for VC2005 build.
 
 {
 hunk ./win32/config.h.in 155
 -#undef HAVE_IPHLPAPI_H
 +#define HAVE_IPHLPAPI_H 1

If you wrap this in #if _MSC_VER  1200 this should work depending on
the version.  There may be a better way to check this, but I know it
will be present on the later versions, the rest of the patch looks good
to me.

Mike

 hunk ./win32/libsofia-sip-ua/libsofia_sip_ua.vcproj 79
 -   AdditionalDependencies=ws2_32.lib
 advapi32.lib
 +   AdditionalDependencies=ws2_32.lib
 advapi32.lib iphlpapi.lib
 hunk ./win32/libsofia-sip-ua/libsofia_sip_ua.vcproj 179
 -   AdditionalDependencies=ws2_32.lib
 +   AdditionalDependencies=ws2_32.lib
 iphlpapi.lib
 hunk ./win32/libsofia-sip-ua-static/libsofia_sip_ua_static.vcproj 73
 +   AdditionalDependencies=iphlpapi.lib
 hunk ./win32/libsofia-sip-ua-static/libsofia_sip_ua_static.vcproj 151
 +   AdditionalDependencies=iphlpapi.lib
 }
 
 Roman


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] build hang on current darcs

[Michael Jerris]

Attached below is a more complete log of this entire section of the make
that hangs, then fails.  Note where I waited 10-20 minutes during the
linking phase on a dual woodcrest box.

make[3]: Entering directory
`/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua'
/bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2   -o
libsofia-sip-ua.la -rpath /usr/local/lib -version-info 3:0:3
bnf/libbnf.la features/libfeatures.la ipt
/libipt.la iptsec/libiptsec.la msg/libmsg.la nea/libnea.la nta/libnta.la
nua/libnua.la sdp/libsdp.la sip/libsip.la soa/libsoa.la
sresolv/libsresolv.la su/libsu.
la tport/libtport.la url/liburl.la stun/libstun.la  nth/libnth.la
http/libhttp.la -lssl -lcrypto -lrt -lpthread
mkdir .libs
gcc -shared  -Wl,--whole-archive bnf/.libs/libbnf.a
features/.libs/libfeatures.a ipt/.libs/libipt.a iptsec/.libs/libiptsec.a
msg/.libs/libmsg.a nea/.libs/libnea.a nta/.libs/libnta.a
nua/.libs/libnua.a sdp/.libs/libsdp.a sip/.libs/libsip.a
soa/.libs/libsoa.a sresolv/.libs/libsresolv.a su/.libs/libsu.a
tport/.libs/libtport.a url/.libs/liburl.a stun/.libs/libstun.a
nth/.libs/libnth.a http/.libs/libhttp.a -Wl,--no-whole-archive  -lssl
-lcrypto -lrt -lpthread  -Wl,-soname -Wl,libsofia-sip-ua.so.0 -o
.libs/libsofia-sip-ua.so.0.3.0
(cd .libs  rm -f libsofia-sip-ua.so.0  ln -s
libsofia-sip-ua.so.0.3.0 libsofia-sip-ua.so.0)
(cd .libs  rm -f libsofia-sip-ua.so  ln -s libsofia-sip-ua.so.0.3.0
libsofia-sip-ua.so)
rm -fr .libs/libsofia-sip-ua.lax
mkdir .libs/libsofia-sip-ua.lax
rm -fr .libs/libsofia-sip-ua.lax/libbnf.a
mkdir .libs/libsofia-sip-ua.lax/libbnf.a
(cd .libs/libsofia-sip-ua.lax/libbnf.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/bnf/.libs/lib
bnf.a)
rm -fr .libs/libsofia-sip-ua.lax/libfeatures.a
mkdir .libs/libsofia-sip-ua.lax/libfeatures.a
(cd .libs/libsofia-sip-ua.lax/libfeatures.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/features/.lib
s/libfeatures.a)
rm -fr .libs/libsofia-sip-ua.lax/libipt.a
mkdir .libs/libsofia-sip-ua.lax/libipt.a
(cd .libs/libsofia-sip-ua.lax/libipt.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/ipt/.libs/lib
ipt.a)
rm -fr .libs/libsofia-sip-ua.lax/libiptsec.a
mkdir .libs/libsofia-sip-ua.lax/libiptsec.a
(cd .libs/libsofia-sip-ua.lax/libiptsec.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/iptsec/.libs/
libiptsec.a)
rm -fr .libs/libsofia-sip-ua.lax/libmsg.a
mkdir .libs/libsofia-sip-ua.lax/libmsg.a
(cd .libs/libsofia-sip-ua.lax/libmsg.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/msg/.libs/lib
msg.a)
rm -fr .libs/libsofia-sip-ua.lax/libnea.a
mkdir .libs/libsofia-sip-ua.lax/libnea.a
(cd .libs/libsofia-sip-ua.lax/libnea.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/nea/.libs/lib
nea.a)
rm -fr .libs/libsofia-sip-ua.lax/libnta.a
mkdir .libs/libsofia-sip-ua.lax/libnta.a
(cd .libs/libsofia-sip-ua.lax/libnta.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/nta/.libs/lib
nta.a)
rm -fr .libs/libsofia-sip-ua.lax/libnua.a
mkdir .libs/libsofia-sip-ua.lax/libnua.a
(cd .libs/libsofia-sip-ua.lax/libnua.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/nua/.libs/lib
nua.a)
rm -fr .libs/libsofia-sip-ua.lax/libsdp.a
mkdir .libs/libsofia-sip-ua.lax/libsdp.a
(cd .libs/libsofia-sip-ua.lax/libsdp.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/sdp/.libs/lib
sdp.a)
rm -fr .libs/libsofia-sip-ua.lax/libsip.a
mkdir .libs/libsofia-sip-ua.lax/libsip.a
(cd .libs/libsofia-sip-ua.lax/libsip.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/sip/.libs/lib
sip.a)
rm -fr .libs/libsofia-sip-ua.lax/libsoa.a
mkdir .libs/libsofia-sip-ua.lax/libsoa.a
(cd .libs/libsofia-sip-ua.lax/libsoa.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/soa/.libs/lib
soa.a)
rm -fr .libs/libsofia-sip-ua.lax/libsresolv.a
mkdir .libs/libsofia-sip-ua.lax/libsresolv.a
(cd .libs/libsofia-sip-ua.lax/libsresolv.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/sresolv/.libs
/libsresolv.a)
rm -fr .libs/libsofia-sip-ua.lax/libsu.a
mkdir .libs/libsofia-sip-ua.lax/libsu.a
(cd .libs/libsofia-sip-ua.lax/libsu.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/su/.libs/libs
u.a)
rm -fr .libs/libsofia-sip-ua.lax/libtport.a
mkdir .libs/libsofia-sip-ua.lax/libtport.a
(cd .libs/libsofia-sip-ua.lax/libtport.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/tport/.libs/l
ibtport.a)
rm -fr .libs/libsofia-sip-ua.lax/liburl.a
mkdir .libs/libsofia-sip-ua.lax/liburl.a
(cd .libs/libsofia-sip-ua.lax/liburl.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/url/.libs/lib
url.a)
rm -fr .libs/libsofia-sip-ua.lax/libstun.a
mkdir .libs/libsofia-sip-ua.lax/libstun.a
(cd .libs/libsofia-sip-ua.lax/libstun.a  ar x
/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua/stun/.libs/li
bstun.a)
rm -fr .libs/libsofia-sip-ua.lax/libnth.a
mkdir .libs/libsofia-sip-ua.lax/libnth.a
(cd 

Re: [Sofia-sip-devel] Problem with multiple 183s with SDP.

[Michael Jerris]

We recently ran in to something very similar (we were trying to do a
re-invite during early media) but ran in to a bunch of MUST's in rfc
3261 which stopped us in our tracks.  If there is a reasonable way to do
this within the rfc I would love to know a good way.  Is sending another
183 in early media allowed?  Can we do this in the case that we have
made the call?  The application this is for is a b2bua, where we want to
establish media (even early) and immediately switch both sides of the
call to talk directly to each other (typically during early media).

 

Mike

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Colin Whittaker
Sent: Wednesday, February 07, 2007 2:55 PM
To: Colin Whittaker
Cc: Pekka Pessi; Sofia-sip-devel@lists.sourceforge.net
Subject: Re: [Sofia-sip-devel] Problem with multiple 183s with SDP.

 

It appears other proxy's are using this method of redirecting RTP with
multiple 183s.
The Nortel DMS SIP uses this method when configuring call features like
remote access to call forwarding. It appears it wants to change the RTP
port  number between the first dial-tone and the second. And sends a new
183 with a new SDP answer. I reported this as a problem to them, but
don't expect much back.

So I am going to look into how we can make Sofia handle this. I realize
it wont make it into 1.12.5 since features are frozen.

I am wondering if it is as easy as removing the check:
nua_session_client_response() line 730
  else if (cr-cr_answer_recv) {
or adding a tag flag that skips this test would work.
It would then run the:
soa_set_remote_sdp(nh-nh_soa, NULL, sdp, len)
soa_process_answer(nh-nh_soa, NULL)  0)
soa_activate(nh-nh_soa, NULL)
again. 
It would have to reset all the ss flags like ss_answer_recv and
ss_complete.

Or, would it be better to simulate a new offer that is the duplicate of
the previous offer and allow the SOA to process it again.
I'm not sure how to do this, but it may be the better way to go to
follow the O/A model.
Any thoughts ?

Colin..



Colin Whittaker wrote: 

Pekka Pessi wrote: 

On 9/15/06, Colin Whittaker [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]  wrote:
  

I'm not seeing any processing of the SDP when I receive multiple
183
replies to my INVITE.
Also, the 200 OK SDP is not being processes either.


 
Are those 183 100rel responses (iow, are they PRACKed)?
 
  

No, I have 100rel disabled.



This is a problem since my proxy is using this method to
redirect a call
to a voice mail server.


 
  

I see a
nua(0x102db820): INVITE: ignoring duplicate SDP in 183 Session
Progress
which I assume means the stack is not prepared for a new SDP
after the
first one.


 
  

Is the proxy violating the spec ?


 
Yes. The can be only one answer to a single offer.
 
The proxy could fork the request, that is, it could respond from
another logical endpoint, the change would be visible from another tag
in the To header. However, that would bring other complications, like
how to tell UAC that the previous fork should be dropped. I just
yesterday called forking brain-dead. Not to mention that the nua stack
does not dig forking after it has received a 183.
 
If the proxy would like to keep existing dialog, it could send UPDATE
with a new offer in it.
 
  

I will report this as a bug to the proxy vendor. The proxy is a
Metaswitch, and they use the DC-SIP/2.0 stack.
Well, I wish I could say this might get fixed, but I'm not expecting
much.




Would it be difficult to modify the stack to support this ?


 
You could have peek in nua_session.c where the code now logs the
message about duplicate sdp.
 
However, you have to decide how to interpret the SDP. This is the most
difficult part, I'm afraid. Standard is no help because O/A model
tells us to ignore those SDP.  Of course, you could peek in the
User-Agent header in the response and make decision based on that.
 
In the past we have interpreted these extra SDP in subsequent 183 or
200 as new offers, and sent answer in PRACK or ACK.
 
  

Well, I have PRACK disabled since this proxy expects authentication for
PRACK and sofia does not currently support this.

Seems like the SDP should be part of the sip object passed in the event
regardless of the status. If the packet has it why wouldn't the sip
object have it ?





 







 

-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 







 
___
Sofia-sip-devel 

Re: [Sofia-sip-devel] build hang on current darcs

[Michael Jerris]

Problem was due to a broken find command on the machine.  This was not
an issue with the sofia-sip build.

Mike

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Michael Jerris
 Sent: Wednesday, February 07, 2007 9:39 AM
 To: sofia-sip-devel@lists.sourceforge.net
 Cc: Pekka Pessi
 Subject: Re: [Sofia-sip-devel] build hang on current darcs
 
 Attached below is a more complete log of this entire section of the
make
 that hangs, then fails.  Note where I waited 10-20 minutes during the
 linking phase on a dual woodcrest box.
 
 make[3]: Entering directory
 `/usr/src/freeswitch.working/libs/sofia-sip/libsofia-sip-ua'
 /bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2   -o
 libsofia-sip-ua.la -rpath /usr/local/lib -version-info 3:0:3
 bnf/libbnf.la features/libfeatures.la ipt
 /libipt.la iptsec/libiptsec.la msg/libmsg.la nea/libnea.la
nta/libnta.la


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] sres_query_t corrupted

[Michael Jerris]

We have a report of a reproducible seg coming out of sres, from nta,
when trying to destroy a query.  It would appear that the query pointer
is getting trashed somewhere (0x80 value).  The code in nta.c looks
fairly safe as far as not doing that.  Where else would that pointer be
messed with?

Mike

http://pastebin.freeswitch.org/297

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Missing contact from invite

[Michael Jerris]

8.1.1.8 Contact

   The Contact header field provides a SIP or SIPS URI that can be used
   to contact that specific instance of the UA for subsequent requests.
   The Contact header field MUST be present and contain exactly one SIP
   or SIPS URI in any request that can result in the establishment of a
   dialog.  For the methods defined in this specification, that includes
   only the INVITE request.


Nua does not autorespond to the condition of missing contact header in
an invite.  It's fine for us to do in the application, but would be nice
for nua to do for us.  There is no completely clear guideline for what
we should respond, but we are now using 400 Missing Contact Header as
suggested in:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-March/0123
73.html  which seems correct.

Mike


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] FW: [Freeswitch-trunk] [commit] r4213 -freeswitch/trunk/libs/sofia-sip/libsofia-sip-ua/nua

[Michael Jerris]

Attached below is I believe a more complete version of the patch that kv
just committed to darcs.  There is a second piece to this problem.
nua_server_request_is_pending is incorrectly not true after some 1xx
responses.  I believe the correct fix for this may be:

Index: nua_session.c
===
--- nua_session.c   (revision 4213)
+++ nua_session.c   (working copy)
@@ -1962,7 +1962,6 @@
   }
 
   if (reliable  sr-sr_status  200) {
-sr-sr_response.msg = NULL, sr-sr_response.sip = NULL;
 if (nta_reliable_mreply(sr-sr_irq, process_prack, nh, msg) ==
NULL)
   return -1;
 return 0;
@@ -1972,7 +1971,7 @@
 if (session_timer_is_supported(nh))
   use_session_timer(ss, 1, 1, msg, sip);
 
-  return nua_base_server_respond(sr, tags);  
+  return nua_server_respond(sr, tags);  
 }
 
 /** Check if the response should be sent reliably.



Mike


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Freeswitch SVN
Sent: Monday, February 12, 2007 6:15 PM
To: [EMAIL PROTECTED]
Subject: [Freeswitch-trunk] [commit] r4213
-freeswitch/trunk/libs/sofia-sip/libsofia-sip-ua/nua

Author: mikej
Date: Mon Feb 12 18:14:36 2007
New Revision: 4213

Modified:
   freeswitch/trunk/libs/sofia-sip/libsofia-sip-ua/nua/nua_session.c

Log:
ignore CANCEL of incoming requests after we send a final response.
Patch by me and Kai Vehmanen.

Modified:
freeswitch/trunk/libs/sofia-sip/libsofia-sip-ua/nua/nua_session.c

==
--- freeswitch/trunk/libs/sofia-sip/libsofia-sip-ua/nua/nua_session.c
(original)
+++ freeswitch/trunk/libs/sofia-sip/libsofia-sip-ua/nua/nua_session.c
Mon Feb 12 18:14:36 2007
@@ -2210,16 +2210,15 @@
   nua_session_usage_t *ss = nua_dialog_usage_private(sr-sr_usage);
   msg_t *cancel = nta_incoming_getrequest_ackcancel(irq);
 
-  assert(nta_incoming_status(irq)  200);
-  assert(nua_server_request_is_pending(sr));
-  assert(ss); assert(ss == nua_session_usage_get(nh-nh_ds)); (void)ss;
+  if (nta_incoming_status(irq)  200 
nua_server_request_is_pending(sr) 
+ ss  (ss == nua_session_usage_get(nh-nh_ds))) {
+nua_stack_event(nh-nh_nua, nh, cancel, nua_i_cancel, SIP_200_OK,
NULL);
 
-  nua_stack_event(nh-nh_nua, nh, cancel, nua_i_cancel, SIP_200_OK,
NULL);
+SR_STATUS1(sr, SIP_487_REQUEST_TERMINATED);
 
-  SR_STATUS1(sr, SIP_487_REQUEST_TERMINATED);
-
-  nua_server_respond(sr, NULL);
-  nua_server_report(sr);
+nua_server_respond(sr, NULL);
+nua_server_report(sr);
+  }
 
   return 0;
 }

___
Freeswitch-trunk mailing list
[EMAIL PROTECTED]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-trunk
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-trunk
http://www.freeswitch.org

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] New client side nua assert

[Michael Jerris]

This one is when cr-cr_orq != NULL.  I don't have logs that go along
with this one.  Will try to capture them next time it happens.

Mike


#2  0x003490c27ae1 in __assert_fail () from /lib64/tls/libc.so.6
No symbol table info available.
#3  0x002a96f48ad7 in nua_client_request_sendmsg (cr=0x2a98177a50,
msg=0x2a98264b90, sip=0x2a98264c88) at nua_stack.c:2113
nh = (nua_handle_t *) 0x54ef60
ds = (nua_dialog_state_t *) 0x54efc8
method = sip_method_bye
name = 0x2a96fe62d4 BYE
url = (const url_string_t *) 0x0
leg = (nta_leg_t *) 0x0
__PRETTY_FUNCTION__ = nua_client_request_sendmsg
#4  0x002a96f489ea in nua_client_request_try (cr=0x2a98177a50) at
nua_stack.c:2079
error = -1
msg = (msg_t *) 0x2a98264b90
sip = (sip_t *) 0x2a98264c88
__PRETTY_FUNCTION__ = nua_client_request_try
#5  0x002a96f48213 in nua_client_init_request (cr=0x2a98177a50) at
nua_stack.c:1880
nh = (nua_handle_t *) 0x54ef60
nua = (nua_t *) 0x564630
ds = (nua_dialog_state_t *) 0x54efc8
msg = (msg_t *) 0x0
sip = (sip_t *) 0x349190d1c0
url = (const url_string_t *) 0x0
t = (const tagi_t *) 0x349190d1c0
has_contact = 0
error = 0
#6  0x002a96f4a56f in nua_client_init_requests (cr=0x2a98177a50,
cr0=0x2a982bb7b0, invite=0) at nua_stack.c:2664
No locals.
#7  0x002a96f4a194 in nua_base_client_response (cr=0x2a982bb7b0,
status=481, phrase=0x2a9831051c No such response, sip=0x2a981dd388,
tags=0x0)
at nua_stack.c:2601
nh = (nua_handle_t *) 0x54ef60
method = sip_method_prack
#8  0x002a96f5a83c in nua_session_client_response (cr=0x2a982bb7b0,
status=481, phrase=0x2a9831051c No such response, sip=0x2a981dd388)
at nua_session.c:822
nh = (nua_handle_t *) 0x54ef60
du = (nua_dialog_usage_t *) 0x2a98259110
ss = (nua_session_usage_t *) 0x2a98259148
sdp = 0x0
len = 0
received = 0x0
#9  0x002a96f5c196 in nua_prack_client_response (cr=0x2a982bb7b0,
status=481, phrase=0x2a9831051c No such response, sip=0x2a981dd388)
at nua_session.c:1524
No locals.
#10 0x002a96f4968e in nua_client_response (cr=0x2a982bb7b0,
status=481, phrase=0x2a9831051c No such response, sip=0x2a981dd388) at
nua_stack.c:2360
nh = (nua_handle_t *) 0x54ef60
du = (nua_dialog_usage_t *) 0x2a98259110
#11 0x002a96f493bc in nua_client_orq_response (cr=0x2a982bb7b0,
orq=0x2a981e8a20, sip=0x2a981dd388) at nua_stack.c:2261
status = 481
phrase = 0x2a9831051c No such response
#12 0x002a96f30dcf in outgoing_recv (orq=0x2a981e8a20, status=481,
msg=0x2a981dd290, sip=0x2a981dd388) at nta.c:8110
sa = (nta_agent_t *) 0x565fb0
orq_status = 0
__PRETTY_FUNCTION__ = outgoing_recv
#13 0x002a96f1f5ea in agent_recv_response (agent=0x565fb0,
msg=0x2a981dd290, sip=0x2a981dd388, tport_via=0x568d00, tport=0x568460)
at nta.c:2512
status = 481
errors = 0
phrase = 0x2a9831051c No such response
method = 0x2a96fe8417 PRACK
cseq = 79669706
orq = (nta_outgoing_t *) 0x2a981e8a20
#14 0x002a96f1d222 in agent_recv_message (agent=0x565fb0,
tport=0x568460, msg=0x2a981dd290, tport_via=0x568d00, now=
  {tv_sec = 3380564884, tv_usec = 301868}) at nta.c:2059
sip = (sip_t *) 0x2a981dd388
#15 0x002a96fb4dad in tport_base_deliver (self=0x568460,
msg=0x2a981dd290, now={tv_sec = 3380564884, tv_usec = 301868}) at
tport.c:2848
No locals.
#16 0x002a96fb4d35 in tport_deliver (self=0x568460,
msg=0x2a981dd290, next=0x0, sc=0x0, now={tv_sec = 3380564884, tv_usec =
301868}) at tport.c:2837
ref = (tport_t *) 0x568460
error = 0
d = (struct tport_delivery *) 0x568040
__PRETTY_FUNCTION__ = tport_deliver
__func__ = tport_deliver
#17 0x002a96fb47b5 in tport_parse (self=0x568460, complete=1,
now={tv_sec = 3380564884, tv_usec = 301868}) at tport.c:2755
msg = (msg_t *) 0x2a981dd290
next = (msg_t *) 0x0
n = 1
streaming = 0
stall = 0
__func__ = tport_parse
#18 0x002a96fb4440 in tport_recv_event (self=0x568460) at
tport.c:2702
now = {tv_sec = 3380564884, tv_usec = 301868}
again = 0
__func__ = tport_recv_event
#19 0x002a96fb4141 in tport_base_wakeup (self=0x568460, events=1) at
tport.c:2606
error = 0
#20 0x002a96fb3ee3 in tport_wakeup_pri (m=0x564630, w=0x565094,
self=0x568460) at tport.c:2569
pri = (tport_primary_t *) 0x568460
events = 1
__PRETTY_FUNCTION__ = tport_wakeup_pri
#21 0x002a96fa2fc2 in su_epoll_port_wait_events (self=0x564ae0,
tout=26) at su_epoll_port.c:508
ser = (struct su_epoll_register *) 0x565070
magic = (su_root_magic_t *) 0x564630
j = 0
n = 1
events = 0
index = 2
version = 277
M = 4
ev = {{events = 1, data = {ptr = 0x2, 

[Sofia-sip-devel] win32 test failures.

[Michael Jerris]

I have the following test results currently on windows.  Please let me
know what I can do to help troubleshoot these issues.

Mike


C:\src\sofia-sip\win32check

C:\src\sofia-sip\win32tests\torture_su_alloc\Debug\torture_su_alloc.exe
torture_su_alloc: PASS

C:\src\sofia-sip\win32tests\torture_su_root\Debug\torture_su_root.exe
su_socket_port_init: socket: Successful WSAStartup() not yet performed
c:\src\sofia-sip\libsofia-sip-ua\su\torture_su_root.c:582:
torture_su_root FAILED: (rt-rt_root = su_root_create(rt))
torture_su_root: FAIL

C:\src\sofia-sip\win32tests\torture_su_tag\Debug\torture_su_tag.exe
torture_su_tag: PASS

C:\src\sofia-sip\win32tests\test_su\Debug\test_su.exe
test_su: testing poll port implementation
su_test executed 2713 pings in 0.176015, mean rtt=6.48784e-005 sec
test_su: PASS

C:\src\sofia-sip\win32tests\torture_su_time\Debug\torture_su_time.exe
torture_su_time: PASS

C:\src\sofia-sip\win32tests\torture_su_timer\Debug\torture_su_timer.exe
timer interval 60.006000
timer interval 63.006000
timer interval 63.006000
timer interval 63.007000
timer interval 64.006000
timer interval 63.006000
timer interval 63.007000
timer interval 63.006000
timer interval 63.006000
timer interval 63.007000
Processing 500 timers took 2.00 millisec (0.50 expected)
torture_su_timer: PASS

C:\src\sofia-sip\win32tests\torture_su\Debug\torture_su.exe
torture_su: PASS

C:\src\sofia-sip\win32tests\test_memmem\Debug\test_memmem.exe
test_memmem: PASS

C:\src\sofia-sip\win32tests\test_tport\Debug\test_tport.exe
c:\src\sofia-sip\libsofia-sip-ua\tport\test_tport.c:577: tport_test
FAILED: tport_tbind(tt-tt_srv_tports, rname, transports, tptag_server,
tag_bool_v((1)), (ta
g_type_t)0, (tag_value_t)0) != -1 or 0 != 4294967295
test_tport: FAIL

C:\src\sofia-sip\win32tests\test_nta\Debug\test_nta.exe
Adding nameserver: 192.168.0.11
test_nta: starting MESSAGE timeout test, completing in 4 seconds
test_nta: PASS

C:\src\sofia-sip\win32tests\test_nua\Debug\test_nua.exe
TEST NUA-1.0: test API
TEST NUA-1.0: PASSED
TEST NUA-1.1: PARAMETERS
Adding nameserver: 192.168.0.11
TEST NUA-1.1: PASSED
TEST NUA-2.1.1: init proxy P
Adding nameserver: 192.168.0.11
TEST NUA-2.1.1: PASSED
TEST NUA-2.1.2: creating test NAT
TEST NUA-2.1.2: PASSED
TEST NUA-2.2.1: init endpoint A
Adding nameserver: 192.168.0.11
TEST NUA-2.2.1: PASSED
TEST NUA-2.2.2: init endpoint B
Adding nameserver: 192.168.0.11
TEST NUA-2.2.2: PASSED
TEST NUA-2.2.3: init endpoint C
Adding nameserver: 192.168.0.11
TEST NUA-2.2.3: PASSED
TEST NUA-1.2: Stack error handling
TEST NUA-1.2.1: CANCEL without INVITE
TEST NUA-1.2.1: PASSED
TEST NUA-1.2.2: BYE without INVITE
TEST NUA-1.2.2: PASSED
TEST NUA-1.2.3: unregister without register
c:\src\sofia-sip\libsofia-sip-ua\nua\test_nua_api.c:213: test_nua
FAILED: e-data-e_status != 401 or 408 != 401
test_nua: FAIL

C:\src\sofia-sip\win32tests\test_htable\Debug\test_htable.exe
test_htable: PASS

C:\src\sofia-sip\win32tests\torture_rbtree\Debug\torture_rbtree.exe
torture_rbtree: PASS

C:\src\sofia-sip\win32tests\torture_su_bm\Debug\torture_su_bm.exe
torture_su_bm: PASS

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] win32 test failures.

[Michael Jerris]

Updated test results from current darcs below.  Please note, this is on
vista on my laptop.  Perhaps the is a new issue in vista, I will try to
test on an xp or 2000 box later today and see if I get the same.  This
very well could be related to new security stuff in the ip stack in
vista.  I also noticed that I am having dns resolver issues on this box
as well, and need to look a bit more into that as well.


C:\src\sofia-sip\win32check.cmd

C:\src\sofia-sip\win32tests\torture_su_alloc\Debug\torture_su_alloc.exe
torture_su_alloc: PASS

C:\src\sofia-sip\win32tests\torture_su_root\Debug\torture_su_root.exe
torture_su_root: testing default (poll) implementation
torture_su_root: PASS

C:\src\sofia-sip\win32tests\torture_su_tag\Debug\torture_su_tag.exe
torture_su_tag: PASS

C:\src\sofia-sip\win32tests\test_su\Debug\test_su.exe
test_su: testing poll port implementation
su_test executed 1456 pings in 0.188, mean rtt=0.000129121 sec
test_su: PASS

C:\src\sofia-sip\win32tests\torture_su_time\Debug\torture_su_time.exe
torture_su_time: PASS

C:\src\sofia-sip\win32tests\torture_su_timer\Debug\torture_su_timer.exe
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
timer interval 60.00
Processing 500 timers took 3.00 millisec (0.50 expected)
torture_su_timer: PASS

C:\src\sofia-sip\win32tests\torture_su\Debug\torture_su.exe
torture_su: PASS

C:\src\sofia-sip\win32tests\test_memmem\Debug\test_memmem.exe
test_memmem: PASS

C:\src\sofia-sip\win32tests\test_tport\Debug\test_tport.exe
c:\src\sofia-sip\libsofia-sip-ua\tport\test_tport.c:577: tport_test
FAILED: tport_tbind(tt-tt_srv_tports, rname, transports, tptag_server,
tag_bool_v((1)), (ta
g_type_t)0, (tag_value_t)0) != -1 or 0 != 4294967295
test_tport: FAIL

C:\src\sofia-sip\win32tests\test_nta\Debug\test_nta.exe
Adding nameserver: 10.10.16.2
Adding nameserver: 208.67.222.222
Adding nameserver: 64.255.237.240
test_nta: starting MESSAGE timeout test, completing in 4 seconds
test_nta: PASS

C:\src\sofia-sip\win32tests\test_nua\Debug\test_nua.exe
TEST NUA-1.0: test API
TEST NUA-1.0: PASSED
TEST NUA-1.1: PARAMETERS
Adding nameserver: 10.10.16.2
Adding nameserver: 208.67.222.222
Adding nameserver: 64.255.237.240
TEST NUA-1.1: PASSED
TEST NUA-2.1.1: init proxy P
Adding nameserver: 10.10.16.2
Adding nameserver: 208.67.222.222
Adding nameserver: 64.255.237.240
TEST NUA-2.1.1: PASSED
TEST NUA-2.1.2: creating test NAT
TEST NUA-2.1.2: PASSED
TEST NUA-2.2.1: init endpoint A
Adding nameserver: 10.10.16.2
Adding nameserver: 208.67.222.222
Adding nameserver: 64.255.237.240
TEST NUA-2.2.1: PASSED
TEST NUA-2.2.2: init endpoint B
Adding nameserver: 10.10.16.2
Adding nameserver: 208.67.222.222
Adding nameserver: 64.255.237.240
TEST NUA-2.2.2: PASSED
TEST NUA-2.2.3: init endpoint C
Adding nameserver: 10.10.16.2
Adding nameserver: 208.67.222.222
Adding nameserver: 64.255.237.240
TEST NUA-2.2.3: PASSED
TEST NUA-1.2: Stack error handling
TEST NUA-1.2.1: CANCEL without INVITE
TEST NUA-1.2.1: PASSED
TEST NUA-1.2.2: BYE without INVITE
TEST NUA-1.2.2: PASSED
TEST NUA-1.2.3: unregister without register
c:\src\sofia-sip\libsofia-sip-ua\nua\test_nua_api.c:213: test_nua
FAILED: e-data-e_status != 401 or 408 != 401
test_nua: FAIL

C:\src\sofia-sip\win32tests\test_htable\Debug\test_htable.exe
test_htable: PASS

C:\src\sofia-sip\win32tests\torture_rbtree\Debug\torture_rbtree.exe
torture_rbtree: PASS

C:\src\sofia-sip\win32tests\torture_su_bm\Debug\torture_su_bm.exe
torture_su_bm: PASS
C:\src\sofia-sip\win32

 -Original Message-
 From: Pekka Pessi [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 26, 2007 1:00 PM
 To: Michael Jerris
 Cc: Sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] win32 test failures.
 
 2007/2/26, Michael Jerris [EMAIL PROTECTED]:
  I have the following test results currently on windows.  Please let
me
  know what I can do to help troubleshoot these issues.
 
C:\src\sofia-sip\win32tests\torture_su_root\Debug\torture_su_root.exe
  su_socket_port_init: socket: Successful WSAStartup() not yet
performed
  c:\src\sofia-sip\libsofia-sip-ua\su\torture_su_root.c:582:
  torture_su_root FAILED: (rt-rt_root = su_root_create(rt))
  torture_su_root: FAIL
 
 Looks like the call to su_init() was deleted at some point... Pushed a
 fix.
 
  C:\src\sofia-sip\win32tests\test_tport\Debug\test_tport.exe
  c:\src\sofia-sip\libsofia-sip-ua\tport\test_tport.c:577: tport_test
  FAILED: tport_tbind(tt-tt_srv_tports, rname, transports,
tptag_server,
  tag_bool_v((1)), (ta
  g_type_t)0, (tag_value_t)0) != -1 or 0 != 4294967295
  test_tport: FAIL
 
 Hm.  There is probably some problems in getting the IP addresses
 correctly from su_getlocalinfo(). I just pushed a fix that may help.
 
  c:\src\sofia-sip\libsofia-sip-ua\nua\test_nua_api.c:213: test_nua
  FAILED: e-data-e_status != 401 or 408 != 401

Re: [Sofia-sip-devel] sofia-sip-1.12.5 Compile failure on win32, VC 6

[Michael Jerris]

Also, we use http://www.freeswitch.org/downloads/win32/gawk.exe on
freeswitch, and it seems to work fine.

Mike


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Kai Vehmanen
 Sent: Tuesday, March 06, 2007 11:49 AM
 To: [EMAIL PROTECTED]
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] sofia-sip-1.12.5 Compile failure on
 win32,VC 6
 
 Hi,
 
 On 06 March 2007,  [EMAIL PROTECTED] wrote:
 I tried it on 1.12.4 and 1.12.5 and got the same errors.  I
 ran sofia-sip\win32\autogen.cmd before hand.  I did have to
 edit build_sources.cmd because I was using gawk 3.1.3 (as the
 comment in build_sources.cmd directs you to do).  I'll try
 your latest code and report back.
 
 aa, ok -- you could also try with mawk. Your error hints at a problem
 with the autogenerated header files, so it could be an issue with
 the version of gawk you are using. You can get mawk from:
 
 http://gnuwin32.sourceforge.net/packages/mawk.htm
 
 I've tested our current code with both gawk-3.1.5 and mawk-1.3.3,
 and the code compiled fine.
 
 --
  under work: Sofia-SIP at http://sofia-sip.sf.net
 
 


-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Duplicated VIA headers of SIP REQUEST

[Michael Jerris]

If you add ;maddr=1.2.3.4 where 1.2.3.4 is the interface ip to bind to,
to the end of the url that you pass to the NUTAG_URL on nua_create then
it binds to the address specified in maddr but properly uses the first
part of that url for the via and contact.

 

Mike

 

 

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
James Tsai
Sent: Monday, April 23, 2007 7:52 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] Duplicated VIA headers of SIP REQUEST

 

Dear all,

 

Did anyone know how to modify the Via header of outgoing SIP REQUEST by
using nua level apis? Because I want to fill the external IP of NAT that
I obtained (by using some else mechanism outside of sofia-sip).

 

I add SIPTAG_VIA_STR(SIP/2.0/UDP external_ip) when creating the
handle that is used to sent out SIP REQUEST. But it cause the duplicated
Via header of REQUEST i sent, as following :

 

Via: SIP/2.0/UDP 192.168.1.100;rport;branch=z9hG4b..

Via: SIP/2.0/UDP external_ip

(It is not exactly I need)

 

By using nua level api, is that any possible way to replace or remove
the original Via header generated by sofia-sip stack ?

 

 

Thanks for your reading, and looking forward to any possible solution?

--

James.CM.Tsai

--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [Freeswitch-users] sofia privacy

[Michael Jerris]

This is an issue in FreeSWITCH(tm) itself, not in the stack.  Addressing
on the FreeSWITCH(tm) list.

Mike

 -Original Message-
 From: [EMAIL PROTECTED]
[mailto:freeswitch-
 [EMAIL PROTECTED] On Behalf Of Tamas Cseke
 Sent: Thursday, May 03, 2007 6:23 AM
 To: [EMAIL PROTECTED]; sofia-sip-
 [EMAIL PROTECTED]
 Subject: [Freeswitch-users] sofia privacy
 
 Hello,
 
 I have a  strange problem, with sip privacy.
 I relay inbound sip calls to another proxy.
  when privacy is set, freeswitch send a strange From header i guess.
 The proxy receiving the request doesn't reply, because of some format
 error.
 
 When i don't use privacy, it is ok, so this is the only one
difference.
 I think the uri in the from hdr is invalid (not sure) @ is
 unneccessary, maybe (?)
 
 
 Inbound request:
 .From:  sip:217.11 6.32.2xx;tag=E4018B8C-23CD.
  Remote-Party-ID:
 sip:217.116.32.2xx;party=calling;screen=yes;privacy=full
 
 Outbound request:
 From: sip:@195.56.65.3xx;tag=ty4j9BmcBc2Nr
 Remote-Party-ID:
 sip:@195.56.65.3xx;party=calling;screen=yes;privacy=off
 
 Thanks any help,
 Tamas
 
 
 ___
 Freeswitch-users mailing list
 [EMAIL PROTECTED]
 http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
 http://www.freeswitch.org

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 900 Internal NUA Error?

[Michael Jerris]

Doublecheck if this is still the case in the current darcs tree, I think
this has been resolved already post 1.12.6.

Mike


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of Jerry Richards
 Sent: Wednesday, May 30, 2007 11:52 AM
 To: sofia-sip-devel@lists.sourceforge.net
 Subject: [Sofia-sip-devel] 900 Internal NUA Error?
 
 Hello All,
 
 If I attempt to unregister a registered NUA (in preparation for
shutdown),
 I
 encounter a 900 Internal NUA Error nua_r_unregister callback event.  I
am
 currently using version 1.12.4.
 
 Here are the debug logs for the life of the NUA, from creation to
 registration to unregistration:
 
 su_root_threading(self=0x1001fca8, enable=0)
...su_root_threading() returned 0x0
Creating sofia-sip NUA...
appl-root=0x1001fca8, tempID=sip:192.168.72.82:5063
 nua_create(root=0x1001fca8, callback=0x427590, magic=0x10006c08,
 url='sip:192.168.72.82:5063')
 nua: nua_create: entering
 nua: nua_stack_init: entering
 nua: nua_stack_set_params: entering
 soa_create(default, 0x10022c70, 0x10024cb8) called
 soa_set_params(static::0x10025008, ...) called
 nta_agent_create: initialized hash tables
 nta_agent_create: initialized transports
 nta_agent_create: initialized random identifiers
 nta_agent_create: initialized timer
 nta_agent_create: initialized resolver
 tport_create(): 0x10026298
 nta: master transport created
 tport_bind_server(0x10026298) to */192.168.72.82:5063/sip
 tport_bind_server(0x10026298): calling tport_listen for udp
 tport_alloc_primary(0x10026298): new primary tport 0x10026690
 tport_listen(0x10026690): listening at udp/192.168.72.82:5063/sip
 tport_bind_server(0x10026298): calling tport_listen for tcp
 tport_alloc_primary(0x10026298): new primary tport 0x10026928
 tport_listen(0x10026928): listening at tcp/192.168.72.82:5063/sip
 nta: bound to (192.168.72.82:5063;transport=*)
 nta: agent_init_via: SIP/2.0/udp 192.168.72.82:5063 (sip)
 nta: agent_init_via: SIP/2.0/tcp 192.168.72.82:5063 (sip)
 nta: Via fields initialized
 nta: Contact header created
 nua_register: Adding contact URL '192.168.72.82' to list.
...nua_create() returned mkData[la].pLine-hLine=0x100249f0
 
 ...
 
Invoking nua_handle() with 'sip:[EMAIL PROTECTED]:5060'
 nua_handle(nua=0x100249f0, hmagic=0x10006c08,
 url='sip:[EMAIL PROTECTED]:5060')
 nua: nh_create_handle: entering
...nua_handle() returned handle=0x100308f8
 nua_register(nh=0x100308f8)
 nua: nua_register: entering
 
 ...
 
 ce_SipEventCb: Rcvd event for nua=0x100249f0, magic=0x10006c08,
 nh=0x100308f8, hmagic=0x10006c08, sip=0x1002c6b4
event: 200 OK (pMkData-mk=MK3=hLine=0x100249f0)
Rcvd nua_r_register event
 
 ...
 
 nua_handle(nua=0x100249f0, hmagic=0x10006c08)
 nua: nua_event: entering
 nua: nh_create_handle: entering
...nua_handle() returned handle=0x1002da98
 nua_unregister(nh=0x1002da98)
 nua: nua_unregister: entering
 
 ...
 
 ce_SipEventCb: Rcvd event for nua=0x100249f0, magic=0x10006c08,
 nh=0x1002da98, hmagic=0x10006c08, sip=0x0
event: 900 Internal NUA Error (pMkData-mk=MK3=hLine=0x100249f0)
Rcvd nua_r_unregister event
Reporting Event...
 
 
 Best Regards,
 Jerry
 
 


-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] LoadLibrary fails on Sofia library

[Michael Jerris]

Confirm that you are using the same C runtime library for all the dll's
used in the process.  Mixing debug/release and static/dynamic runtimes
can cause this.

Mike


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:sofia-sip-
 [EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
 Sent: Wednesday, May 30, 2007 6:39 PM
 To: sofia-sip-devel@lists.sourceforge.net
 Subject: [Sofia-sip-devel] LoadLibrary fails on Sofia library
 
 When I link my DLL (ABC.DLL) to libsofia_sip_ua.lib/dll, a LoadLibrary
 call on ABC.DLL fails due to an Invalid access to memory location.
The
 actual failure occurs when a DLL (XYZ.DLL), whose load is triggered by
 ABC.DLL, calls into wininet.dll.  Any help on this would be greatly
 appreciated.
 
 Brian
 


-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Incoming Re-INVITE SDP Content

[Michael Jerris]

Shouldn't it be using just the number for 96 and less, and only compare the
name if = 97?

Mike


On 7/9/07 8:08 PM, Pekka Pessi [EMAIL PROTECTED] wrote:

 2007/7/6, Jerry Richards [EMAIL PROTECTED]:
 In response to a re-INVITE from the server, I am seeing sofia-sip (v 1.12.4)
 sending out a 200 OK SDP body that appears to be missing a field.  Here are
 the details:
 
 1) NUA sends outgoing INVITE (via nua_invite() with SOATAG_USER_SDP)
containing the following (as seen in Ethereal):
 ... (m): audio ...
 ... (a): rtpmap:0 G711/8000
 
 
 2) Server replies (via 200 OK) with SDP fields (as seen in Ethereal):
 ... (m): audio ...
 ... (a): rtpmap:0 PCMU/8000
 ... (a): rtpmap:96 telephone-event/8000
 ... (a): fmtp:96 0-16
 ... (a): silenceSupp:off - - - -
 
 3) Server sends re-INVITE with SDP fields (as seen in Ethereal):
 ... (m): audio ...
 ... (a): rtpmap:0 PCMU/8000
 ... (a): rtpmap:96 telephone-event/8000
 ... (a): fmtp:96 0-16
 ... (a): silenceSupp:off - - - -
 
 4) NUA replies (via nua_respond(200 OK) and identical SOATAG_USER_SDP
as original INVITE), but this is what I see in outgoing 200 OK SDP
body in Ethereal:
 ... (m): audio ...
 ... (a): rtpmap:96 telephone-event/8000/1
 
 The outgoing 200 OK should also contain either
 
 ... (a): rtpmap:0 PCMU/8000
 or
 ... (a): rtpmap:0 G711/8000
 
 I have a Polycomm phone that I am comparing this with.  Do you know why this
 field is missing?
 
 I guess the G711 codec name is your problem. If they payload type
 name is there, the soa and sdp uses the name and not the payload type
 number when it matches the codecs. So G711 does not match with
 PCMU.
 
 Polycomm either digs G711 in offer but uses PCMU in answer, or
 rejects all your codecs but includes PCMU in answer in distant hope
 that your UA could send PCMU to it.
 
 SOA doesn't include G711, probably because there is the
 telephony-event codec which it selects as common codec. I guess if you
 included a tag SOATAG_AUDIO_AUX(telephone-event) in
 nua_set_params()/nua_invite() tags, SOA would include both G729 and
 G711 in the answer.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] building sofia sip 1.12.6 on windows

[Michael Jerris]

If your using vs2005 and xp you should not need that.. It looks more like
you are using the express edition of mvsc 2005 and you don't have the
platform sdk installed, or visual studio properly configured to use it.
Also, as a side note, you don't need cygwin to run autogen.cmd, you just
need a gawk.exe binary.

Mike


On 7/12/07 2:34 PM, Kai Vehmanen [EMAIL PROTECTED] wrote:

 Hi,
 
 On Wed, 11 Jul 2007, aviad rozenhek wrote:
 
 I am trying to compile release sofia-sip-1.12.6 on windows.
 [...]
 1d:\samples\sofia-sip-1.12.6\sofia-sip-1.12.6\libsofia-sip-ua\su\sofia-sip\s
 u.h(73)
 : fatal error C1083: Cannot open include file: 'tpipv6.h': No such
 file or directory
 
 you need the IPv6-preview APIs installed, see sofia-sip\win32\README.txt
 for more details.
 
 Alternatively you can disable IPv6 altogether by modifying
 sofia-sip\win32\sofia-sip\su_configure.sh (set SU_HAVE_IN6 to zero).


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] nua_register problem

[Michael Jerris]

Check out the code in src/mod/endpoints/mod_sofia/sip_reg.c in freeswitch (
www.freeswitch.org) for a good example of sofia nua registration that is
known to work with asterisk.  Please note that when doing auth with asterisk
you need to have the right things in the from so asterisk can patch the peer
properly.

Mike

On 8/31/07, Carmelo [EMAIL PROTECTED] wrote:

 Hi,
 I'm a new in Sofia-SIP Library, and I've a problem with nua_register()
 function when I try to register to Asterisk.
 Here is my code

 /* Begin code */
 typedef struct application
 {
su_home_t  home; /* memory home */
su_root_t* root; /* root object */
nua_t* nua;  /* NUA stack object */
 } t_application;

 t_application app;

 nua_handle_t *handle;

 /* Initialize Sofia-SIP library and create event loop */
 app.home.suh_size = sizeof(e_sip_obj);

 /* initialize system utilities */
 su_init();

 /* initialize memory handling */
 su_home_init(app.home);

 /* initialize root object */
 app.root = su_root_create(NULL);

 app.nua = nua_create(app.root, /* Event loop */
 event_callback, /* Callback for processing events */
 app, /* Additional data to pass to callback */
 NUTAG_URL(sip:0.0.0.0:5061), /* 0.0.0.0 stands for Local address
 */
 TAG_END());

 handle = nua_handle(app.nua, e_sip_obj.home,
 SIPTAG_TO_STR(sip:[EMAIL PROTECTED]:5060),  /* 1.1.1.1 stands for
 server
 address */
 TAG_END());

 nua_register(handle, SIPTAG_FROM_STR(sip:[EMAIL PROTECTED]:5061),
 SIPTAG_TO_STR(sip:[EMAIL PROTECTED]:5060),
 NUTAG_M_DISPLAY(test), TAG_END());

 /* End code */

 If I try to connect to Asterisk, after several seconds I receive the
 message
 I have received an event nua_r_register status 408 Request Timeout

 How can I solve this problem?

 Thanks in advance,

 Carmelo
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:
 Cerchi un'auto usata, vuoi vendere il camper o il cellulare? Prova
 Email.it
 Annunci, pochi click per pubblicare e trovare ciò che vuoi!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6893d=20070831



 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now   http://get.splunk.com/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] segfault at nh_call_pending (nh=0xb20bd038, now=3399807596) at nua_stack.c:510

[Michael Jerris]

We received a report of this segfault.  Detailed debug information is at:

http://jira.freeswitch.org/browse/SFSIP-22.

Backtrace:

(gdb) bt full
#0 0xb7136f59 in nh_call_pending (nh=0xb20bd038, now=3399807596) at
nua_stack.c:510
ds = (nua_dialog_state_t *) 0xb20bd070
du = (nua_dialog_usage_t *) 0x1
next = 3399807597
#1 0xb7136f06 in nua_stack_timer (nua=0x808f940, t=0x808f448, a=0x0) at
nua_stack.c:494
nh = (nua_handle_t *) 0xb20bd038
nh_next = (nua_handle_t *) 0xb71f8380
now = 3399807596
root = (su_root_t *) 0x808edc8
#2 0xb719bcbc in su_timer_expire (timers=0x808747c, timeout=0xb6f9432c,
now={tv_sec = 3399807596, tv_usec = 203877}) at su_timer.c:533
t = (su_timer_t *) 0x808f448
f = (su_timer_f) 0xb7136e7f nua_stack_timer
n = 0
__PRETTY_FUNCTION__ = su_timer_expire
#3 0xb719c4ac in su_base_port_run (self=0x8087458) at su_base_port.c:315
tout = 2000
__PRETTY_FUNCTION__ = su_base_port_run
#4 0xb7199cf9 in su_port_run (self=0x8087458) at su_port.h:314
base = (su_virtual_port_t *) 0x8087458
#5 0xb7199cd0 in su_root_run (self=0x808edc8) at su_root.c:683
__PRETTY_FUNCTION__ = su_root_run
#6 0xb7191d55 in su_pthread_port_clone_main (varg=0xb709512c) at
su_pthread_port.c:300
arg = (struct clone_args *) 0x0
task = {{sut_port = 0x8087458, sut_root = 0x808edc8}}
zap = 1


Mike
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/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] bad contact adress.

[Michael Jerris]

We have a problem where we send an invite to a client behind nat, that is
registered to us.  When they respond 100, the contact address is incorrectly
an internal 192.168 adress, and all our responses after that (prack for
example) try to go to the unroutable 192 address.  Are there tags that can
turn on detection of this or change this behavior?

Mike
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Memory leaks in 1.12.7

[Michael Jerris]

we have this issue already narrowed down to the patch that caused it:

 Mon Oct  8 07:54:24 EDT 2007  [EMAIL PROTECTED]
   * nua.c: nua event callback does not use nua_t object after
nua_destroy()
 call. sf.net bug #1803686

and Pekka said he was going to look into it.  I'll let him respond with any
more details from there, we just reverted that patch from our snapshot and
all seems to be working well for now.

Mike

On 10/24/07, Fabio Margarido [EMAIL PROTECTED] wrote:

 Hi there,

 I'm observing serious memory leaks when using Sofia-sip 1.12.7 . I
 have a simple UAS test program with a NUA callback like:

 void event_callback(nua_event_t   event,
 int   status,
 char const   *phrase,
 nua_t*nua,
 nua_magic_t  *magic,
 nua_handle_t *nh,
 nua_hmagic_t *hmagic,
 sip_t const  *sip,
 tagi_ttags[])
 {
   switch (event) {
 case nua_i_invite:
   nua_respond(nh, 180, NULL, TAG_END());
   nua_respond(nh, 200, NULL,
   SIPTAG_CONTENT_TYPE_STR(application/sdp),
   SIPTAG_PAYLOAD_STR(g_sdp),
   TAG_END());
   break;

 case nua_i_bye:
   nua_handle_destroy(nh);
   break;

 default:
   break;
   }
 }

 When I link this program against sofia-sip 1.12.6 I can keep it
 running for ages with 350 caps and the memory usage never goes above
 6% in a 2 GB machine. With 1.12.7, 100% memory is used after about 10
 minutes.
 My test setup uses SIPp to originate the calls. After 26 calls, the
 valgrind report gives me this:

 ==13602== Memcheck, a memory error detector.
 ==13602== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
 ==13602== Using LibVEX rev 1658, a library for dynamic binary translation.
 ==13602== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
 ==13602== Using valgrind-3.2.1-Debian, a dynamic binary
 instrumentation framework.
 ==13602== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
 ==13602== For more details, rerun with: -v
 ==13602==
 ==13602==
 ==13602== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
 ==13602== malloc/free: in use at exit: 226,587 bytes in 1,851 blocks.
 ==13602== malloc/free: 4,567 allocs, 2,716 frees, 643,119 bytes allocated.
 ==13602== For counts of detected errors, rerun with: -v
 ==13602== searching for pointers to 1,851 not-freed blocks.
 ==13602== checked 8,664,364 bytes.
 ==13602==
 ==13602== 136 bytes in 1 blocks are possibly lost in loss record 3 of 17
 ==13602==at 0x402095F: calloc (vg_replace_malloc.c:279)
 ==13602==by 0x400FFA7: (within /lib/ld-2.5.so)
 ==13602==by 0x401006B: _dl_allocate_tls (in /lib/ld-2.5.so)
 ==13602==by 0x444AA4F: pthread_create@@GLIBC_2.1 (in
 /lib/tls/i686/cmov/libpthread-2.5.so)
 ==13602==by 0x411A205: su_pthreaded_port_start (su_pthread_port.c:262)
 ==13602==by 0x411C1F2: su_epoll_clone_start (su_epoll_port.c:564)
 ==13602==by 0x41193A8: su_default_clone_start (su_port.c:78)
 ==13602==by 0x4119277: su_clone_start (su_port.c:304)
 ==13602==by 0x40C4473: nua_create (nua.c:166)
 ==13602==by 0x80488BA: main (teste.c:26)
 ==13602==
 ==13602==
 ==13602== 212,391 (37,752 direct, 174,639 indirect) bytes in 78 blocks
 are definitely lost in loss record 15 of 17
 ==13602==at 0x402095F: calloc (vg_replace_malloc.c:279)
 ==13602==by 0x410E833: su_home_new (su_alloc.c:549)
 ==13602==by 0x40866CC: msg_create (msg.c:61)
 ==13602==by 0x40A3F71: nta_msg_create_for_transport (nta.c:2746)
 ==13602==by 0x4124F2C: tport_msg_alloc (tport.c:2622)
 ==13602==by 0x41257D9: tport_recv_iovec (tport.c:3068)
 ==13602==by 0x41321BB: tport_recv_dgram (tport_type_udp.c:266)
 ==13602==by 0x4130011: tport_recv_event (tport.c:2815)
 ==13602==by 0x4130347: tport_base_wakeup (tport.c:2754)
 ==13602==by 0x411BCAB: su_epoll_port_wait_events (su_epoll_port.c:506)
 ==13602==by 0x4119D01: su_base_port_run (su_base_port.c:336)
 ==13602==by 0x4111E28: su_root_run (su_port.h:309)
 ==13602==
 ==13602== LEAK SUMMARY:
 ==13602==definitely lost: 37,752 bytes in 78 blocks.
 ==13602==indirectly lost: 174,639 bytes in 1,690 blocks.
 ==13602==  possibly lost: 136 bytes in 1 blocks.
 ==13602==still reachable: 14,060 bytes in 82 blocks.
 ==13602== suppressed: 0 bytes in 0 blocks.
 ==13602== Reachable blocks (those to which a pointer was found) are not
 shown.
 ==13602== To see them, rerun with: --show-reachable=yes

 I'm interested in moving to 1.12.7 as soon as possible, but this is a
 major show-stopper.
 I'll be happy to provide further info. Hope this helps.
 Thanks.

 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and 

Re: [Sofia-sip-devel] FW: nua_i_subscribe/nua_notify/nua_r_notify

[Michael Jerris]

we use both of these in the set params call, I think the siptag you use
should be equivalent to the NUTAG_ALLOW_EVENTS, but the NUTAG_ALLOW is
probably whats missing.

 NUTAG_ALLOW(SUBSCRIBE)
  NUTAG_ALLOW_EVENTS(message-summary)

Mike

On 10/26/07, Jerry Richards [EMAIL PROTECTED] wrote:

 By the way, I am calling nua_set_params() with
 SIPTAG_ALLOW_EVENTS_STR(dialog;sla;include-session-description), which
 is
 the same as the Event field of the incoming SUBSCRIBE request.

 Jerry


 -Original Message-
 From:
 Sent: Friday, October 26, 2007 10:47 AM
 To: 'Pekka Pessi'
 Cc: 'sofia-sip-devel@lists.sourceforge.net'
 Subject: nua_i_subscribe/nua_notify/nua_r_notify


 Hello,

 Okay, I replaced my nua_notifier() call to nua_notify(), but when I
 receive
 a SUBSCRIBE request from the server, sofia-sip 1.12.6work4 is sending 489
 Bad Event response and not calling the callback function at all.  Do I
 need
 to do some other initialization to get sofia-sip to inform me of the
 SUBSCRIBE request?

 Best Regards,
 Jerry



 -Original Message-
 From: Pekka Pessi [mailto:[EMAIL PROTECTED]
 Sent: Friday, October 26, 2007 3:03 AM
 To: Jerry Richards
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] 1.12.4 Bug In nua_r_notifier Event?


 2007/10/26, Jerry Richards [EMAIL PROTECTED]:
  So does this mean that nua_notifier() will not be fixed and eventually
  become extinct?  Is the nua_i_subscribe/nua_notify/nua_r_notify scheme
 the
  way of the future?  Will this work in my version 1.12.6work4?

 They serve different purposes. The nua_notifier suits better for more
 traditional event data distribution, handling SUBSCRIBE/NOTIFY more or
 less directly with nua_i_subscribe/nua_notify/nua_r_notify suits
 better cases where there are some other semantics associated with SIP
 events, like in your application.

 Of course, the nua_notifier() thing has its downsides, it uses nea
 module, which has zero unit tests and unclear semantics.

 --
 Pekka.Pessi mail at nokia.com


 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Fwd: Problems on win32 with latest window SDK

[Michael Jerris]

Begin forwarded message:


From: Michael Jerris [EMAIL PROTECTED]
Date: January 11, 2008 9:34:37 AM GMT-05:00
To: Pekka Pessi [EMAIL PROTECTED]
Subject: Re: [Sofia-sip-devel] Problems on win32 with latest window  
SDK


My fix for this one is:

Index: sofia-sip/su.h
===
--- sofia-sip/su.h  (revision 6643)
+++ sofia-sip/su.h  (revision 6644)
@@ -67,7 +67,7 @@
#  include winsock2.h
#  include ws2tcpip.h
#  if SU_HAVE_IN6
-#if defined(IPPROTO_IPV6)
+#if defined(IPPROTO_IPV6) || (_WIN32_WINNT = 0x0600)
/* case 1: IPv6 defined in winsock2.h/ws2tcpip.h */
#else
/* case 2: try to use IPv6 Tech Preview */

it should not require additional includes beyond this.

Mike

On Jan 11, 2008, at 8:48 AM, Pekka Pessi wrote:


2008/1/9, Francesco Lamonica [EMAIL PROTECTED]:

Hi, i found a problem on win32 with the latest windows SDK (the one
with vista support)
in su.h (line 73 - sofia 1.12.7) it does not enter in the then
branch of the #if defined(IPPROTO_IPV6) and tries to use the
nonexistent tpipv6.h


thing is that with previous windows platform sdk (windows server  
2003

R2) the IPPROTO_IPV6 was defined in the winsock2.h header file
(included from su.h) hence the definition was correctly found)


Hm. How this should be fixed? Does  do you have to include an another
include file with Vista SDK?

--
Pekka.Pessi mail at nokia.com

-
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




-
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

Re: [Sofia-sip-devel] how to compile sofsip without glib

[Michael Jerris]

Sofia sip does not require glib, and --without-glib configure flag is  
the way to turn it off.  In freeswitch we do exactly that.  What is   
not working specifically?

Mike

On Jan 15, 2008, at 5:37 AM, jason_jiang in amit wrote:

 Dear all,

  I have had a question for a long time. Why does sofsip have to work
 with glib?Are there  methods to compile softsip without glib,  
 because I
 just wanna it run in the text mode only. I tried to use ./configure
 --without-glib to avoid using of glib but it doesn't work. Can you  
 give
 some  suggestions for this situation. thanks for your helps.

 PS the version of sofsip is 0.13. and sofia-sip is 1.12.7

 Jason.


 -
 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


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] how to compile sofsip without glib

[Michael Jerris]

the cli is a demo program that uses glib as a utility to make some  
things easier.  It is required for that, but not for the sofia-sip  
library.

Mike

On Jan 15, 2008, at 12:25 PM, jason_jiang in amit wrote:


 Hi, Mike.

 The trouble I met is that compiling sofsip_cli failed. sofsip_cli  
 looks like a sip user agent using sofia libary as its core.  It  
 forces me to get glib2.2 for it. Do I have a way to compile it  
 without glib? In order to control the size of sip-ua, I don't wanna  
 merge additional libary. Additionally, I am curious about  what's  
 glib, and what's point is it  used to  do for? How do I compile a  
 sofsip_cli in a cross-platform without glib?


 Michael Jerris wrote:

 Sofia sip does not require glib, and --without-glib configure flag  
 is  the way to turn it off.  In freeswitch we do exactly that.   
 What is   not working specifically?

 Mike

 On Jan 15, 2008, at 5:37 AM, jason_jiang in amit wrote:

 Dear all,

 I have had a question for a long time. Why does sofsip have to work
 with glib?Are there  methods to compile softsip without glib,   
 because I
 just wanna it run in the text mode only. I tried to use ./configure
 --without-glib to avoid using of glib but it doesn't work. Can  
 you  give
 some  suggestions for this situation. thanks for your helps.

 PS the version of sofsip is 0.13. and sofia-sip is 1.12.7

 Jason.


 -
 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









-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SIPTAG_P_PREFERRED_IDENTITY()

[Michael Jerris]

You can access the whole header as:

sip_header_as_string(profile-home, (void *) alert_info);

ai_url should be a url_t, not ascii data... if you are printfing it as  
%d it might show as a negative number.

ai_params is a msg_param_t * , so a double pointer, its essentially a  
list of const char *, so to access the first param, you would do  
**ai_params.

Mike



On Jan 23, 2008, at 11:54 AM, Jerry Richards wrote:

 Hi,

 Okay, I added a call to sip_alert_info(sip) in the callback function  
 when I
 receive the nua_i_invite 100 event.  However, the ai_params and ai_url
 fields of the sip_alert_info_t structured returned from  
 sip_alert_info() is
 not valid ASCII data (i.e. negative numbers).

 Is there any other way to get at that data?  Or anything else I can  
 try?

 Best Regards,
 Jerry


 -Original Message-
 From: Pekka Pessi [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, January 23, 2008 3:43 AM
 To: Jerry Richards
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: SIPTAG_P_PREFERRED_IDENTITY()

 2008/1/22, Jerry Richards [EMAIL PROTECTED]:
 If I call sip_update_default_mclass(sip_extend_mclass(NULL)) during
 initialization as you mention below, then which field of the (INVITE)
 sip message (in the NUA callback function) would I find the Alert- 
 Info
 header?

 Up until now, I have been pulling it out of the
 sip-sip_unknown-un_name field, but it looks like that will no  
 longer
 work?

 There is no field, you have to use accessor function
 sip_alert_info(sip) (which will return pointer to sip_alert_info_t  
 struct).

 --
 Pekka.Pessi mail at nokia.com


 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 1.12.8 compilation error with openssl 0.9.6

[Michael Jerris]

This code was added so the debugging from openssl would hit the sofia  
callbacks.  if you don't need tls support, you could easily build  
without and not have the issue at all, otherwise, commenting that out  
should be fine.  Maybe we need to add  a configure check if that  
function is there and if so use it, otherwise, just print to stdout  
like it has??

Mike

On Jan 30, 2008, at 2:00 PM, Fabio Margarido wrote:

 Hi there,

 I tried to compile sofia-sip-1.12.8 today on a machine with an older
 kernel and older libraries and got this error:

 gcc -Wall -g -O2 -o .libs/sip-options sip-options.o
 ../libsofia-sip-ua/.libs/libsofia-sip-ua.so -lssl -lcrypto -lpthread
 -Wl,--rpath -Wl,/usr/local/lib
 ../libsofia-sip-ua/.libs/libsofia-sip-ua.so: undefined reference to
 `ERR_print_errors_cb'

 I dug around and googled a bit and found out that my machine's openssl
 is version 0.9.6, and apparently ERR_print_errors_cb isn't present in
 0.9.6, only from 0.9.7 on. Is it really a pre-requisite for sofia now
 to have openssl = 0.9.7? If so, shouldn't the configure script check
 for this?
 As I cannot change the library version on this machine, I simply
 commented out the lines in tport_tls.c which called
 ERR_print_errors_cb. This shouldn't give me major headaches, right?
 Thanks.

 Fabio Margarido

 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] question about a modified digest algorithm

[Michael Jerris]

I know that part of their stuff involves a key that I don't believe is  
publicly available.  If you figure this out, please share.


Mike

On Feb 2, 2008, at 8:26 AM, Loell Erecre wrote:

hi, i was just hoping if the devs have the slightest idea, if  
there's any way to discover a modified algorithm of a digest  
authentication used by a proprieatary sip server.


i have been scouring the web on how yahoo sip works then i came  
across this one,


http://blog.motiwala.com/2007/08/18/yahoo-messenger-voip-service-with-sip-phone

the blog entry talks about yahoo sip, the main stumbling block is  
yahoo is using a modified digest authentication algorithm , if all  
parameters  to be included in the hash is known, can one somehow  
know the algorithm used to produce the hash?


Looking for last minute shopping deals? Find them fast with Yahoo!  
Search 
.-

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-SIP - Additional Standard compliance

[Michael Jerris]

If your looking for something that supports the media elements too, we  
support much of this in freeswitch (www.freeswitch.org) including  
2833/4733 and passthrough T.38 (all using sofia for the signaling).

Mike

On Feb 7, 2008, at 8:22 AM, Pekka Pessi wrote:

 2008/1/30, Yann BOURON [EMAIL PROTECTED]:
 I would like to know if I could expect Sofia-SIP Library to be  
 compliant
 soon with the following standards :
 - RFC 2782 ?

 - DNS SRV - already in compliance

 - RFC 2822 ?

 - Email message format - I'm confused, Sofia SIP does not do any e- 
 mail...

 - RFC 2833 ?

 RTP payload format for DTMF and friends - Obsoleted by 4733 and 4734

 Signaling RTP payload format in SDP is supported, rest is left to
 application to handle

 - RFC 3398 ?

 Sofia SIP supports INFO, signaling RFC4733 codec, and sort-a-kind-a
 multipart mime. So I guess we can put a cross (checkmark in America)
 in this box, too.

 - RFC 3966 ?

 RFC3261-like support, in other words, tel uri comparison is done
 character-by-character.

 - draft-ietf-sip-session-timer-04.txt ?

 Sofia SIP supports RFC 4028. I don't know how -04 draft differs from
 the RFC 4028.

 - ITU-T T.38 ?

 Yet another payload format, or so I hope. Again, codec negotiation  
 is supported.

 -- 
 Pekka.Pessi mail at nokia.com

 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Basic doubt about NUA

[Michael Jerris]

NUA is not dependent on glib.  You can build with the configure flag  
--with-glib=no.

Mike

On Mar 21, 2008, at 10:16 PM, Mahesh Govind wrote:

 Hi All,

 I am new to sofia sip . Could you please help me by clearing the
 following doubt .
 Whether NUA is dependent on GLIB  or only the sofia_cli is dependent  
 on GLIB .
 I want to sofia to  an embedded platform where you have limited   
 resources .


 With thanks and regards
 mahesh

 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Basic doubt about NUA

[Michael Jerris]

I can't say that its simple, but you can check out the nua  
implementation we have in freeswitch (www.freeswitch.org)...  Not sure  
exactly what you mean by one user profile  .. but we do act as  
different identities in several different ways.

Mike



On Mar 22, 2008, at 12:47 AM, Mahesh Govind wrote:

 HI Mike ,
 thanks a lot   Also can pls point some simple example programs,
 which uses nua with out GLIB .

 One more help i need . I read that nua  can support only one user
 profile at a time  .
 Is this true .

 With thanks and regards
 mahesh

 On Sat, Mar 22, 2008 at 8:33 AM, Michael Jerris [EMAIL PROTECTED]  
 wrote:
 NUA is not dependent on glib.  You can build with the configure flag
 --with-glib=no.

 Mike



 On Mar 21, 2008, at 10:16 PM, Mahesh Govind wrote:

 Hi All,

 I am new to sofia sip . Could you please help me by clearing the
 following doubt .
 Whether NUA is dependent on GLIB  or only the sofia_cli is dependent
 on GLIB .
 I want to sofia to  an embedded platform where you have limited
 resources .


 With thanks and regards
 mahesh

 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel




-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Basic doubt about NUA

[Michael Jerris]

Yes.


On Mar 22, 2008, at 2:17 AM, Mahesh Govind wrote:

 if we have one instance of nua ,

 Can I configure that instance to accept/make calls for multiple  
 users at the
 same time .

 With thanks and regards
 Mahesh



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Another assertion falied

[Michael Jerris]

What version of sofia-sip is this?  Have you tried w/ current darcs?

Mike

On Apr 7, 2008, at 8:00 AM, Fabio Margarido wrote:

 Hi there,

 I got this while randomly using my application today:

 nta.c:781: agent_timer: Assertion `!agent-sa_out.trying-q_head'  
 failed.

 Any ideas on what might cause it? Thanks.

 -
 This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
 Register now and save $200. Hurry, offer ends at 11:59 p.m.,
 Monday, April 7! Use priority code J8TLD2.
 http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] INVITE source IP address

[Michael Jerris]

If your in a callback, you can use something like:

char network_ip[80];
get_addr(network_ip, sizeof(network_ip), ((struct  
sockaddr_in *) msg_addrinfo(nua_current_request(nua))-ai_addr)- 
sin_addr);


Mike

On Apr 28, 2008, at 9:48 AM, Matt Krokosz wrote:

From what I can gather so far (only been using the stack for a few  
days now), access is needed to the underlying “msg_t” structure.   
However, from the NUA layer, there is no way to go from a “sip_t”  
structure back to the “msg_t” structure.  As a result, the only  
solution I can see is to use the NTA layer which provides access to  
both the msg_t and sip_t structure.


Matt

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
] On Behalf Of [EMAIL PROTECTED]

Sent: Monday, April 28, 2008 5:09 AM
To: sofia-sip-devel@lists.sourceforge.net
Subject: Re: [Sofia-sip-devel] INVITE source IP address

Hi,

I want similar information, the destination IP address for the  
outgoing secondary transport used by a NUA handle.
AFAIK there's no way to retrieve peer's IP address, could a tag be  
made for that?

--
  Mikhail
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
] On Behalf Of ext Matt Krokosz

Sent: Friday, April 25, 2008 6:53 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] INVITE source IP address
Using the nua module, when an INVITE is received, is there anyway to  
determine the source IP address from the transport layer, rather  
then from the SIP msg headers such as Contact or From?


Matt
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save  
$100.

Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] su_pthread_port_clone_main does not finish before unloading the library

[Michael Jerris]

On May 19, 2008, at 11:23 AM, Martin Drasar wrote:

 Hello everyone,
 I have two problems related to shutting down sofia stack.

 In my application I create a separate thread that does the stack
 initialization and runs the event loop. That's how I do it:

 su_init();
 su_root_create(instance-root);
 nua_create(instance-root, ...); - this is where the
 su_pthread_port_clone_main is started
 nua_set_params();
 while (true)
 {
  su_root_step (instance-root, 100);
  if (terminate)
  {
event-reset();
nua_shutdown(instance-nua);
su_root_step(instance-root, 500);
event-wait(500);
nua_destroy(instance-nua);
break;
  }
 }
 su_root_destroy (instance-root);
 su_deinit();

 Problem 1)
 When the stack should end, I run that ugly piece of code, that calls
 nua_sutdown(), does su_root_step() to receive the nua_r_shutdown event
 and then calls nua_destroy(). However, even if I receive the
 nua_r_shutdown event, nua_destroy() reports: FATAL: nua_shutdown not
 completed.
 What is the clean way to handle this? And what else is needed for
 nua_shutdown() to be successfull?

You can/will get several status 101 r_shutdown events, you must wait  
for a status =200.



 Problem 2)
 After calling the su_root_destroy() and su_deinit() the
 su_pthread_port_clone_main is still running and waiting inside  
 su_wait()
 function. This leads to access violations whenever I try to unload  
 sofia
 library before shutting down the program.
 su_root_destroy() documentation states that I should not call it from
 cloned task. Is this the case? And if not, why does it fails to stop  
 the
 thread?

See problem 1, I think this is related.

Mike



 Any help is much appreciated
 Thanks in advance

 Martin

 -- 
  Martin Drasar, Developer / Analyst
  OptimSys, s.r.o.
  [EMAIL PROTECTED]
  Tel: +420 541 143 065
  Fax: +420 541 143 066
  http://www.optimsys.cz


 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Resolving E.164 numbers with ENUM

[Michael Jerris]

I am not sure how much that makes sense in sofia itself, as it seems  
outside the scope, like putting an rtp library in sofia.  That being  
said, we have enum support in freeswitch that uses udns for the async  
resolver.  Take a look at http://www.freeswitch.org.  The code is in  
the source root at src/mod/applications/mod_enum

Mike

On Jun 5, 2008, at 10:03 AM, Jerry Richards wrote:

 Hello All,

 Do you have any plans to add logic that translates an outgoing  
 dialstring
 into an E.164 number and queries ENUM to obtain a SIP URI of the form
 sip:[EMAIL PROTECTED]?

 Best Regards,
 Jerry


 -
 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


-
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

Re: [Sofia-sip-devel] sofia-sip changes (2008-09-03)

[Michael Jerris]

We have seen some similar results from the same patch set:

(gdb) bt
#0  0x2aaab00d6f56 in nta_outgoing_destroy  
(orq=0x) at nta.c:6914
#1  0x2aaab010ca5b in nua_client_request_complete  
(cr=0x2aaab43a87a0) at nua_stack.c:2186
#2  0x2aaab0108d76 in nh_destroy (nua=0x2c009310,  
nh=0x2aaac811ae40) at nua_stack.c:968
#3  0x2aaab0108c01 in nua_stack_destroy_handle  
(nua=0x2c009310, nh=0x2aaac811ae40, tags=0x2c4272d0) at  
nua_stack.c:937
#4  0x2aaab0108232 in nua_stack_signal (nua=0x2c009310,  
msg=0x431eef80, ee=0x2c4272a8) at nua_stack.c:653
#5  0x2aaab015961a in su_base_port_execute_msgs (queue=0x0) at  
su_base_port.c:276
#6  0x2aaab0159392 in su_base_port_getmsgs (self=0x1a871a70) at  
su_base_port.c:198
#7  0x2aaab01596f4 in su_base_port_run (self=0x1a871a70) at  
su_base_port.c:331
#8  0x2aaab01625aa in su_port_run (self=0x1a871a70) at su_port.h:310
#9  0x2aaab0162582 in su_root_run (self=0x1a870140) at su_root.c:689
#10 0x2aaab016107f in su_pthread_port_clone_main (varg=0x427b1bf0)  
at su_pthread_port.c:321
#11 0x2b3fb0032307 in start_thread () from /lib64/libpthread.so.0
#12 0x0031234d1ded in clone () from /lib64/libc.so.6

On Sep 8, 2008, at 5:37 AM, Della Betta Filippo wrote:

 After applying this patches , I get segfault on TEST NUA-5.6:  
 destroy when completed.
 Stack dump following..
 Can you check this ?
 TIA
 Regards,
 Filippo


 #0  su_home_mutex_lock (home=0x) at su_alloc.c:1518
 #1  0xb7ec96c9 in msg_destroy (msg=0x) at msg.c:160
 #2  0xb7f0898b in nua_client_request_unref (cr=0x8203788) at  
 nua_stack.c:2217
 #3  0xb7f08bcd in nua_client_request_remove (cr=0x8203788) at  
 nua_stack.c:2167
 #4  0xb7f1c963 in nua_session_usage_remove (nh=0x81f9a38,  
 ds=0x81f9a70, du=0x827b418, cr0=0x0, sr0=0xb6d30f14) at  
 nua_session.c:279
 #5  0xb7f0fc47 in nua_dialog_usage_remove_at (own=0x81f9a38,  
 ds=0x81f9a70, at=value optimized out, cr0=0x0, sr0=0xb6d30f14) at  
 nua_dialog.c:377
 #6  0xb7f09a96 in nua_base_server_report (sr=0xb6d30f14, tags=0x0)  
 at nua_stack.c:1891
 #7  0xb7f2189b in nua_bye_server_report (sr=0xb6d30f14, tags=0x0) at  
 nua_session.c:3850
 #8  0xb7f08081 in nua_server_report (sr=0x81f9a38) at nua_stack.c:1827
 #9  0xb7f0bd1a in nua_stack_process_request (nh=0x81f9a38,  
 leg=0x8238078, irq=0x826b4a0, sip=0x821fe7c) at nua_stack.c:1464
 #10 0xb7eff3a8 in leg_recv (leg=0x8238078, msg=0x821fde0,  
 sip=0x821fe7c, tport=0x81c6d88) at nta.c:4884
 #11 0xb7f0060b in agent_recv_request (agent=0x81c5930,  
 msg=0x821fde0, sip=0x821fe7c, tport=0x81c6d88) at nta.c:2472
 #12 0xb7f01555 in agent_recv_message (agent=0x81c5930,  
 tport=0x81c6d88, msg=0x821fde0, tport_via=0x81c82e8, now={tv_sec =  
 3429853072, tv_usec = 274963})
at nta.c:2254
 #13 0xb7f69414 in tport_base_deliver (self=0x81c6d88, msg=0x821fde0,  
 now={tv_sec = 2863311530, tv_usec = 274963}) at tport.c:3013
 #14 0xb7f75191 in tport_deliver (self=0x81c6d88, msg=0x821fde0,  
 next=0x0, sc=0x0, now={tv_sec = 3429853072, tv_usec = 274963}) at  
 tport.c:3002
 #15 0xb7f75472 in tport_parse (self=0x81c6d88, complete=1,  
 now={tv_sec = 3429853072, tv_usec = 274963}) at tport.c:2919
 #16 0xb7f755fd in tport_recv_event (self=0x81c6d88) at tport.c:2861
 #17 0xb7f758e8 in tport_base_wakeup (self=0x81c6d88, events=1) at  
 tport.c:2763
 #18 0xb7f61129 in su_epoll_port_wait_events (self=0x81c41f0,  
 tout=498) at su_epoll_port.c:506
 #19 0xb7f5f077 in su_base_port_run (self=0x81c41f0) at  
 su_base_port.c:342
 #20 0xb7f56d49 in su_root_run (self=0x81c43d8) at su_port.h:310
 #21 0xb7f5faba in su_pthread_port_clone_main (varg=0xbfa83014) at  
 su_pthread_port.c:321
 #22 0xb7e6b240 in start_thread () from /lib/tls/i686/cmov/ 
 libpthread.so.0
 #23 0xb7e0049e in clone () from /lib/tls/i686/cmov/libc.so.6



 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 ] On Behalf Of Sofia-SIP Darcs Changes
 Sent: mercoledì 3 settembre 2008 20.56
 To: sofia-sip-devel@lists.sourceforge.net
 Subject: [Sofia-sip-devel] sofia-sip changes (2008-09-03)

 This posting was generated automatically from darcs repo
 http://sofia-sip.org/repos/sofia-sip.

 Wed Sep  3 21:21:06 EEST 2008  Pekka Pessi [EMAIL PROTECTED]
  * nua: using nua_client_set_terminating()

M ./libsofia-sip-ua/nua/nua_dialog.h -2 +2
M ./libsofia-sip-ua/nua/nua_notifier.c -2 +2
M ./libsofia-sip-ua/nua/nua_publish.c -1 +1
M ./libsofia-sip-ua/nua/nua_register.c -3 +3
M ./libsofia-sip-ua/nua/nua_stack.c -3 +3
M ./libsofia-sip-ua/nua/nua_subnotref.c -3 +3

 Wed Sep  3 21:20:29 EEST 2008  Pekka Pessi [EMAIL PROTECTED]
  * nua: added reference counting for client-side transactions

M ./libsofia-sip-ua/nua/nua_dialog.c -17 +10
M ./libsofia-sip-ua/nua/nua_dialog.h -5 +21
M ./libsofia-sip-ua/nua/nua_session.c -11 +20
M ./libsofia-sip-ua/nua/nua_stack.c -62 +172

 Wed Sep  3 20:55:22 EEST 2008  Pekka Pessi [EMAIL 

Re: [Sofia-sip-devel] Memory leak when caller sends BYE

[Michael Jerris]

This issue should already be fixed in current darcs.  In FreeSWITCH  
our copy of sofia is currently sync'd with darcs and it is more stable  
than 1.12.9 for sure and likely 1.12.8 as well.

Mike


Mike

On Nov 25, 2008, at 11:58 AM, Jen Chitty wrote:

 Hi,

 I'm running 1.12.9 and I'm finding that my process leaks memory
 when it is the caller (sends the INVITE) and it terminates the
 call (sends the BYE).  However, if the callee terminates the
 call, there's no leak.

 This is a blocker bug for us, and I don't have a workaround.
 I would really appreciate any assistance that anyone has to offer.

 Here's the SOFIA_DEBUG 9 trace from a call where the caller sends
 the BYE (NOTE: the log was collected on the caller side):

 nua: nh_create_handle: entering
 nua: nua_handle_bind: entering
 nua: nua_invite: entering
 nua: nua_stack_set_params: entering
 soa_clone(static::0x1001a120, 0x100177f8, 0x10024280) called
 soa_set_params(static::0x10025268, ...) called
 soa_set_user_sdp(static::0x10025268, (nil), 0x10018eff, -1) called
 soa_set_capability_sdp(static::0x10025268, (nil), 0x10018eff, -1)  
 called
 su_localinfo: if lo with index 1
 su_localinfo: if bridget with index 4
 soa_set_params(static::0x10025268, ...) called
 nta_leg_tcreate(0x100256d8)
 nua(0x10024280): adding session usage
 soa_init_offer_answer(static::0x10025268) called
 soa_generate_offer(static::0x10025268, 0) called
 soa_static_offer_answer_action(0x10025268, soa_generate_offer): called
 soa_static(0x10025268, soa_generate_offer): generating local  
 description
 su_localinfo: if lo with index 1
 su_localinfo: if bridget with index 4
 soa_static(0x10025268, soa_generate_offer): upgrade with local  
 description
 soa_sdp_mode_set(0x7f5fd868, (nil), ): called
 soa_static(0x10025268, soa_generate_offer): storing local description
 soa_get_local_sdp(static::0x10025268, [(nil)], [0x7f5ff990],  
 [0x7f5ff994])
 called
 nta: selecting scheme sip
 tport_tsend(0x10022318) tpn = */192.168.0.152:5060
 tport_resolve addrinfo = 192.168.0.152:5060
 tport_by_addrinfo(0x10022318): not found by name */192.168.0.152:5060
 tport_vsend returned 685
 nta: sent INVITE (10828982) to */192.168.0.152:5060
 tport_pend(0x10022318): pending 0x100264f0 for udp/192.168.0.151:5060
 (already 0)
 nta: timer set to 32000 ms
 nta: timer shortened to 500 ms
 nua(0x10024280): call state changed: init - calling, sent offer
 soa_get_local_sdp(static::0x10025268, [0x7f5ff9a8], [0x7f5ff9ac],  
 [(nil)])
 called
 nua: nua_application_event: entering
 nua(0x10024280): sent signal r_invite
 tport_wakeup_pri(0x10022318): events IN
 tport_recv_event(0x10022318)
 tport_recv_iovec(0x10022318) msg 0x10027d00 from (udp/ 
 192.168.0.151:5060)
 has 281 bytes, veclen = 1
 tport_deliver(0x10022318): msg 0x10027d00 (281 bytes) from
 udp/192.168.0.152:5060/sip next=(nil)
 nta: received 100 Trying for INVITE (10828982)
 nta: 100 Trying is going to a transaction
 nta_outgoing: RTT is 20 ms
 tport_release(0x10022318): 0x100264f0 by 0x10027328 with 0x10027d00
 (preliminary)
 tport_wakeup_pri(0x10022318): events IN
 tport_recv_event(0x10022318)
 tport_recv_iovec(0x10022318) msg 0x10027d00 from (udp/ 
 192.168.0.151:5060)
 has 486 bytes, veclen = 1
 tport_deliver(0x10022318): msg 0x10027d00 (486 bytes) from
 udp/192.168.0.152:5060/sip next=(nil)
 nta: received 180 Ringing for INVITE (10828982)
 nta: 180 Ringing is going to a transaction
 tport_release(0x10022318): 0x100264f0 by 0x10027328 with 0x10027d00
 (preliminary)
 nua: nua_application_event: entering
 nua(0x10024280): call state changed: calling - proceeding
 nua: nua_application_event: entering
 nta: timer not set
 tport_wakeup_pri(0x10022318): events IN
 tport_recv_event(0x10022318)
 tport_recv_iovec(0x10022318) msg 0x10028510 from (udp/ 
 192.168.0.151:5060)
 has 664 bytes, veclen = 1
 tport_deliver(0x10022318): msg 0x10028510 (664 bytes) from
 udp/192.168.0.152:5060/sip next=(nil)
 nta: received 200 OK for INVITE (10828982)
 nta: 200 OK is going to a transaction
 tport_release(0x10022318): 0x100264f0 by 0x10027328 with 0x10028510
 nta: timer set to 32000 ms
 soa_set_remote_sdp(static::0x10025268, (nil), 0x10028a3c, 132) called
 soa_process_answer(static::0x10025268) called
 soa_static_offer_answer_action(0x10025268, soa_process_answer): called
 soa_sdp_mode_set(0x10026cf8, 0x10028148, ): called
 soa_static(0x10025268, soa_process_answer): upgrade codecs with remote
 description
 soa_activate(static::0x10025268, (nil)) called
 nua(0x10024280): INVITE: processed SDP answer in 200 OK
 nua: nua_application_event: entering
 soa_activate(static::0x10025268, (nil)) called
 nta: selecting scheme sip
 tport_tsend(0x10022318) tpn = */192.168.0.152:5060
 tport_resolve addrinfo = 192.168.0.152:5060
 tport_by_addrinfo(0x10022318): not found by name */192.168.0.152:5060
 tport_vsend returned 306
 nta: sent ACK (10828982) to */192.168.0.152:5060
 nua(0x10024280): call state changed: proceeding - ready, received  
 answer
 

Re: [Sofia-sip-devel] Compiling sofia-sip with TLS on windows

[Michael Jerris]

To simplify this patch and make it more consistent with the rest of  
the code, add the following at the top of tport_type_tls, this should  
solve all the issues in that file without your patch, can you confirm?


#if HAVE_FUNC
#elif HAVE_FUNCTION
#define __func__ __FUNCTION__
#else
static char const __func__[] = tport_type_tls;
#endif

#if HAVE_WIN32
#include io.h
#define access(_filename, _mode) _access(_filename, _mode)
#endif


On Nov 27, 2008, at 8:13 AM, Tiago Katcipis wrote:

with Paulo Pizarro's help i was able to compile sofia-sip with TLS  
support. Im sendig the patch with the diffs. The changes where the  
following:


The hint that pekka gave was right, but that was sufficient to  
compile only tport_tls.c, it was also needed to change  
tport_type_tls.c, the problem was the __funct__ function that is not  
defined on windows and the acess function that is not defined on  
windows either. So when this functions are used a ifdef is used to  
compile with functions that are defined on windows ( _acess for  
example ). There is also an ifdef to include io.h from windows.


Besides this there is the config.h file that must be edited, the  
following macros must be defined to 1.


HAVE_TLS
HAVE_OPENSSL
HAVE_OPENSSL_TLS1_H

after applying the patch, defining the macros and linking the msvs  
project with openssl it should compile just fine, at least here is  
compiling. Im using here openssl-0.9.8i.


i would like to thank pekka again, your help was fundamental, i  
would waste a lot of time to realize that the include order was  
generating the error. I hope the patch helps.


Best regards

Tiago César Katcipis

On Wed, Nov 26, 2008 at 5:17 PM, Pekka Pessi [EMAIL PROTECTED] wrote:
2008/11/26 Tiago Katcipis [EMAIL PROTECTED]:
 Im trying to compile sofia-sip on windows with TLS support and im  
having a

 little trouble on doing that. When i include the tport_tls.c and the
 tport_tls.h on the project i got the following error:

 C:\ARQUIVOS DE PROGRAMAS\MICROSOFT SDK\INCLUDE\winsock2.h(109) :  
error

 C2011: 'fd_set' : 'struct' type redefinition
 C:\ARQUIVOS DE PROGRAMAS\MICROSOFT SDK\INCLUDE\winsock2.h(144) :  
warning

 C4005: 'FD_SET' : macro redefinition
 C:\ARQUIVOS DE PROGRAMAS\MICROSOFT SDK\INCLUDE 
\winsock.h(88) : see

 previous definition of 'FD_SET'

Looks like openssl includes winsock.h and sofia-sip/su_wait.h then
includes winsock2.h. You can try to move
sofia-sip includes before openssl, perhaps openssl then does not try
to use winsock.h.

 the error keeps going on saying that a lot of things are being  
redefined, i
 dont changed anything...just added the files. I already tried to  
define
 HAVE_TLS and HAVE_OPENSSL on the win32/config.h, but the error is  
the same.


 Can anyone tell me what im doing wrong, or at least give a hint,  
im kinda

 lost? i did not find any doc on how to compile on win32 with TLS.

Sorry, I don't think we have ever done win32 and tls compilation  
with sofia-sip.


If you succeed, please keep us posted.

--
Pekka.Pessi mail at nokia.com



--
it might be a profitable thing to learn Java, but it has no  
intellectual value whatsoever Alexander Stepanov
 
winTLS 
.patch 
 
-
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=100url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
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=100url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Windows error

[Michael Jerris]

MSVC is picky about some c99 stuff it doesn't like, in this case it is  
likely code before declaration which msvc only supports for cpp code,  
not c.  I would have to see the gateway.c code to be sure.

Mike

On Dec 4, 2008, at 7:04 AM, Emanuele Vespa wrote:

 Hi all, after I've successfully build sofia sip under Windows with  
 the Win32 solution, when I try to build my application I get this:

 c:\documents and settings\administrator\desktop\manu stage 
 \gateway.c(198) : error C2275: 'nua_handle_t' : illegal use of this  
 type as an expression

  c:\sofia-sip-1.11-debug\include\sofia-sip\nua_tag.h(66) : see  
 declaration of 'nua_handle_t'


 note that this application run perfectly on linux!

 Thanks for your attention, regards

 Emanuele
 -
 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=100url=/___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


-
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=100url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] DNS issue with Sres

[Michael Jerris]

Have you tried with the latest release (1.12.10) ?

Mike

On Dec 22, 2008, at 7:06 AM, Mohammed Sulaiman wrote:

Hi , we are using Sofia 1.12.8 on the Windows Mobile 6 platform in a  
voip client app.

We have come across the following issue, when making a call over 3G.

Sofia is using the IpHelper api on a our platform to get a list of  
nameservers. We have a situation where it obtains 2 nameservers


192.168.0.1 and 10.205.65.68

the 3G access pointIp address is 10.47.127.102 so the first one  
obviously is no use. So there is some code in Sofia to traverse the  
nameservers if the query times out.
However we fail to connect on the socket when trying to query the  
10.205.65.68, the connect() call in sres_server_socket returns  
Windows error 10048


Only one usage of each socket address (protocol/network address/ 
port) is normally permitted.


sres_send_dns_query(003CD300, 0041B3D0) id=9637 A xxx.xxx.com  (to  
[192.168.0.1]:53)

sres_resolver_timer() called at 1229661607
sres_resend_dns_query(003CD300, 0041B3D0, timeout) called  
sres_send_dns_query(003CD300, 0041B3D0) called
sres_server_socket: connect: Address already in use: 10.206.65.68:53  
sres_send_dns_query(003CD300, 0041B3D0) id=9637 A xxx.xxx.com (to  
[192.168.0.1]:53)


The problem is after this error sofia marks this nameserver as 'bad'
dns-dns_error = SRES_TIME_MAX;
and never uses it again. So always keeps trying to query the  
unreachable server 192.168.0.1
I've noticed running in the debugger we can query the 10.205.65.68  
nameserver as the

connect(s, (void *)dns-dns_addr, dns-dns_addrlen) succeeds
 Without the debugger connected it always fails.
ie slowing things down makes it work. But what I am trying to work  
out is why the initial connect on the socket fails. It seems to be  
because we made an initial query to an unreachable server and the  
socket is maybe still in use or something.


Has anyone seen this issue before, any ideas how to resolve.
I did try setsockopt with SO_REUSEADDR, this time connect() succeeds  
but the query doesn't get a response although this nameserver is a  
reachable one. So i'm thinking the first query to 192.168.0.1  
nameserver still causing a problem.


One final thing i would have thought using the sres library would  
result in NAPTR query

rather than A but i am seeing only A type queries going out.

Thanks

--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Segmentation fault

[Michael Jerris]

This looks exactly like a seg that we were getting that was fixed a  
couple days ago in darcs head.  Please note there is one evil bug in  
the current darcs head that can be corrected with the following patch:

hunk ./libsofia-sip-ua/su/su_uniqueid.c 141
-  uint32_t *seed = calloc(32, sizeof *seed);
+  uint32_t *seed = calloc(32, sizeof(uint32_t));
hunk ./libsofia-sip-ua/su/su_uniqueid.c 174
-  initstate(seed[0] ^ seed[1], (char *)seed, sizeof(seed));
+  initstate(seed[0] ^ seed[1], (char *)seed, 32 * sizeof(uint32_t));


Mike

On Feb 18, 2009, at 11:35 AM, Bernhard Suttner wrote:

 Hi @ all,

 I have an segmentation fault. The version which I use is from 10.  
 November
 2008 (so between 1.12.9 and 1.12.10). It crashes while sending a SIP  
 Notify.

 The segfault occured during a load test with more than 200 parallel  
 calls.  Do
 you have an idea how I can better debug it? Or do you think it would  
 be better
 to use 1.12.10. The problem with updateing is always, that I have to  
 be sure
 that there is no other memory leak or code change which does break  
 our system.
 Please find attached a screenshot of the backtrace (of gdb).


 Best regards,
 Bernhard Suttner
  
 sofia_sip_segfault 
 .png 
  
 --
 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


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

Re: [Sofia-sip-devel] Why is Stun keepalive mechanism disabled?

[Michael Jerris]

The stun code is incomplete and other nat traversal and keepalive  
mechanisms went rfc so those were used instead.

Mike

On Jun 15, 2009, at 3:31 PM, Sharevon wrote:

 Hi,
 I'm trying to enable STUN. I found a piece of code, shown as below

 if (!ob-ob_validated  ob-ob_keepalive.sipstun
 0 /* Stun is disabled for now */)

 in function outbound_start_keepalive, file outbound.c.

 By using  0, Stun keep-alive mechanism is disabled. Why?

 Sean


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] performance question

[Michael Jerris]

Are you using nta or nua?

On Jun 22, 2009, at 12:43 AM, jonathan augenstine  
jaugenst...@gmail.com wrote:

 I am developing a simple redirect server on Windows 2008 Server.   
 When an invite arrives, the handler performs a database lookup, and  
 then returns a 302 response with the database response in the  
 Contact field.  The database access is about 15-30 milliseconds even  
 under high load.  What I am seeing are performance issues I would  
 not expect.  Performance is OK up to about 30 invite messages per  
 second.  Then I start to see significant lag occurring.  What  
 happens is that I see log messages indicating the response has be  
 sent, however, wireshark is indicating that the 302 may not go out  
 until after a significant delay.  At 30 messages per second I see  
 delays of 1-2 seconds.  Not extreme but it is a concern.  When I  
 start running loads up to 50-100 invites per second I start to see  
 large delays (15-30 seconds) from arrival of the invite to return of  
 the 302.  I am confident the delay is not in the database lookup.

 I have two questions.  What kind of considerations should I make to  
 optimize performance of the Sofia-SIP stack?  The other question is,  
 can someone provide me with some guidance in how to go about  
 troubleshooting this issue?  I have run out of ideas on isolating  
 the problem.

 Jonathan

 --- 
 --- 
 --- 
 -
 Are you an open source citizen? Join us for the Open Source Bridge  
 conference!
 Portland, OR, June 17-19. Two days of sessions, one day of  
 unconference: $250.
 Need another reason to go? 24-hour hacker lounge. Register today!
 http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Changing IP address.

[Michael Jerris]

On Jul 31, 2009, at 2:23 PM, Jen Chitty wrote:



Hi,

I'm wondering if there's a way to change the IPv4 address that the  
Sofia stack binds to without having to shutdown and restart the  
stack.  We're using the NUA.


Nope, but would be nice.



Right now, if our device's IPv4 address changes we shutdown the  
Sofia stack and start it up again.  This seems to mostly work, but  
we are experiencing some race conditions with callbacks from the  
Sofia event loop thread (running su_root_run) and our application  
thread, especially with respect to handle destruction.  We were  
hoping that we could just leave the Sofia stack running and tell it  
to change its IPv4 address.


Another question that I'd like an answer to is this:  When shutting  
down the Sofia stack, are we guaranteed to receive a  
nua_i_terminated event for every session that hasn't yet been  
terminated?


That is the intention, if your not, its a bug.



Thanks very much.

--JT

J. T. Chitty, Chief Software Engineer
VTech Technologies Canada, Ltd.


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

Re: [Sofia-sip-devel] Alert-Info: Auto Answer is rejected with 400-Bad Alert-Info header

[Michael Jerris]

The most common way we have seen this done in devices is:

in invite request params: intercom=true

in a Call-Info header for the form:  sip:%s;answer-after=0

I know both of these work fine with sofia-sip.  Can the client support  
either of these methods?

Also, I have not seen this error before, can you check current darcs  
head to confirm if its still there?

Mike

On Aug 19, 2009, at 4:26 AM, EiSl 1972 wrote:

 Hello all,

 Our SIP-client is connected to a certain PBX (Sphericall) and is  
 being manipulated via 3PCC (via PBX).
 We've enabled to retrieve 'alert-info' at our application via  
 sip_update_default_mclass(sip_extend_mclass(NULL)).

 Now next is happening:
 When a call is made from client 1 to client 2 (makeCall-command),  
 client 1 receives an INVITE containing Alert-Info: Auto Answer  
 field in order to answer this call. Sofia immediately rejects this  
 INVITE with a 400-Bad Alert-info Header response. At application  
 level no callback is fired, so we're completely unaware of this call.
 On another PBX (which uses talk in the alert-info for auto-answer)  
 our SIP-client works fine as expected.

 I've asked the PBX-guys if it is possible to change the Auto  
 Answer string into something else, but I doubt this is possible.  
 Therefore my question here:

 What do I have to adapt to make Auto Answer a valid value for  
 Alert-Info? Seems that the parser rejects this because of the space  
 in between. I've tried to follow it with a debugger, but at this  
 level it is hard to follow.


 With regards,

 Eize

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


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

Re: [Sofia-sip-devel] Wrong answer from sofia-sip

[Michael Jerris]

Can you paste the actual sip trace here.

Mike

On Aug 26, 2009, at 6:45 AM, Bernhard Suttner wrote:

 Hi,

 I have the following problem (using sofia sip 1.12.9):

 A (non sofia-sip) sends INVITE to B (user agent with sofia-sip)
 B send back a Trying
 B send Ringing and then a 200 OK

 Most important data for the INVITE from A:
 Src IP: 10.251.0.1
 Dest IP: 10.251.0.101
 Contact: 10.27.0.60

 The Trying generated from sofia-sip has the data:
 Src IP: 10.251.0.101
 Dest IP: 10.251.0.1
 VIA: SIP/2.0/UDP 10.27.0.60;branch=ydfasfasfsf;received=10.251.0.1

 The problem is, that B use the IP 10.251.0.1 as destination and not  
 the
 contact of the INVITE (that would be 10.27.0.60). Also in the RINGING
 and 200 OK sofia-sip will use the Src-IP and not the Contact addr.

 Can I somehow configure sofia-sip in that way, that it will use the
 CONTACT addr instead of the Src IP?

 Thanks in advance!

 Best regards,
 Bernhard Suttner

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


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

Re: [Sofia-sip-devel] Header created using SIPTAG_HEADER_STR appears after Content-Length header

[Michael Jerris]

Why is this a problem? 

Mike

On May 19, 2010, at 6:11 PM, Jim Thomas wrote:

 Hello,
 
 I am experimenting with adding support for SIP 302 to redirect an inbound 
 call when the PBX is configured to forward the call.
 
 The ITSP requires that the Contact header include the number where the call 
 should be redirected, and a Diversion header must be added that identifies 
 the valid SIP trunk DID associated with the call.
 
 I tried sending this response to the incoming INVITE:
 
   nua_respond(handle, 302, Moved Temporarily,
   SIPTAG_CONTACT_STR(sip:9725551...@itsp.com:5060),
   SIPTAG_HEADER_STR(Diversion: sip:9725559...@itsp.com),
   TAG_END());
 
 Sofia-SIP generates this outgoing response:
 
   SIP/2.0 302 Moved Temporarily
   Via: SIP/2.0/UDP nnn.nnn.nnn.nnn:5060;branch=z9hG4bK39lurp00dgvh0e0fg2s0.1
   From: Out of Area 
 sip:9725553...@itsp.com;user=phone;tag=437990541-1274304841447-
   To: parentAccountFN parentAccountLN 
 sip:9725559...@itsp.com;tag=ay1e7NH4a9pDH
   Call-ID: bw1734014471905101951145...@itsp.com
   CSeq: 423519092 INVITE
   Contact: sip:9725551...@itsp.com:5060
   Accept: application/sdp
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, 
 NOTIFY, REFER, UPDATE, REGISTER
   Supported: timer, 100rel
   Content-Length: 0
   Diversion: sip:9725559...@itsp.com
 
 The problem is that the Diversion header created using SIPTAG_HEADER_STR() 
 appears *after* the Content-Length header.
 
 I see this post from Oct 2006:
 
   
 http://www.mail-archive.com/sofia-sip-devel@lists.sourceforge.net/msg00928.html
 
 I would think Sofia-SIP would process SIPTAG_HEADER_STR() by locating the 
 custom header *before* the Content-Length header.
 
 I am using Sofia-SIP 1.12.10 (thank you for the open source contribution).
 
 How can I parameterize or otherwise code a custom header such that it appears 
 before the Content-Length header?


--

___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Problem compiling sofia-sip 1.12.10 for MinGW

[Michael Jerris]

I am not sure about mingw builds, but the visual studio build in the freeswitch 
tree tends to build everywhere.  We have a few patches that have not made it 
upstream yet, but should in the near future. in the mean time, feel free to 
pull whaterver you need from our repo.  The build is modified a bit to 
integrate into our tree but it should be easy enough to change the paths for 
that.

Mike

On Jun 10, 2010, at 9:20 AM, Stefano Sabatini wrote:

 Hi,
 
 see the related thread:
 [1] http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/3344
 
 I have still the problem with the 64-bit integers, it tells it cannot
 handle them, I simply disabled the check in the auto-generated
 configure file.
 
 Then I get the error:
 
 su_addrinfo.c:825: error: redefinition of 'gai_strerrorA'
 c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/ws2tcpip.h:308: 
 note:
 previous definition of 'gai_strerrorA' was here
 make[4]: *** [su_addrinfo.lo] Error 1
 make[4]: Leaving directory 
 `/home/ssabatini/src/reilabs/flash2sip/contrib/sofia-
 sip_1_12_10/libsofia-sip-ua/su'
 make[3]: *** [all] Error 2
 
 I applied the same workaround suggested in [1], I set
 HAVE_GAI_STRERROR to 1 in config.h, but now I get this error:
 
 gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip -Wall
 -g -O2 -I../../win32/pthread -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 
 -DIN_LIBSOFIA
 _SIP_UA -DIN_LIBSOFIA_SRES -mms-bitfields -pipe -mno-cygwin -mwindows 
 -mconsole
 -Wall -g -O0 -MT su_taglist.lo -MD -MP -MF .deps/su_taglist.Tpo -c 
 su_taglist.c
 -DDLL_EXPORT -DPIC -o .libs/su_taglist.o
 su_taglist.c: In function 't_snprintf':
 su_taglist.c:153: warning: unknown conversion type character 'l' in format
 su_taglist.c:153: warning: too many arguments for format
 su_taglist.c: In function 't_size_snprintf':
 su_taglist.c:1273: warning: format '%lu' expects type 'long unsigned int', 
 but a
 rgument 4 has type 'unsigned int'
 su_taglist.c: In function 't_socket_snprintf':
 su_taglist.c:1484: error: 'LLI' undeclared (first use in this function)
 su_taglist.c:1484: error: (Each undeclared identifier is reported only once
 su_taglist.c:1484: error: for each function it appears in.)
 make[4]: *** [su_taglist.lo] Error 1
 
 I'd like to know if these problems have been worked out in the current
 darcs version, and in general I'd like to know which is the state of
 activity / maintainance of the project.
 
 Regards.
 
 --
 ThinkGeek and WIRED's GeekDad team up for the Ultimate 
 GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
 lucky parental unit.  See the prize list and enter to win: 
 http://p.sf.net/sfu/thinkgeek-promo
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Is sofia-sip dead?

[Michael Jerris]

sofia-sip is not dead.  The repository is in the process of moving to a new 
repo.  I expect a chunk of patches to be merged in soon, I was discussing this 
with the maintainer last week.

Mike

On Jun 16, 2010, at 9:27 PM, Daniel Jabbour wrote:

 Hi,
 
 I am just getting started with a SIP application that I'm writing for a 
 personal project. I am getting ready to use Sofia-SIP as my app's library. 
 However, I noticed:
 
 * Sofia-Sip's CVS on SF is 18+ months old, and the latest release in CVS was 
 1.12.9
 * Links on the download page for snapshots, release notes archive, etc are 
 broken
 * The latest packaged source release is 1.12.10
 
 So, if the latest release is greater than the version tagged in CVS, where is 
 development taking place? Has the repository moved? Is Nokia working entirely 
 in-house? Or is Sofia-SIP dead?
 
 Any thoughts would be greatly appreciated.


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] su_types.h+config.h+windows compilation issues

[Michael Jerris]

I maintain multiple libs that do this approach, there is no good way to handle 
this without microsoft or the toolchain making a standard header for this that 
we can test for.  In lieu of that, you really need to do it yourself, and you 
still then have the issue of ifdef protecting them against re-definition.  A 
sane way to handle this with mingw would be to have an inittypes.h and stdint.h 
file in a subdir in the tree somewhere, and a configure check to test for that, 
and if it fails, add that dir to the includes so it uses ours instead.  
Requiring users to install extra stuff is just making it harder for people to 
build and use, and I think is a bad approach.  Also, we could check these in, 
and just put them in the include chain for the windows build, they do have 
ifdef checks to avoid multiple inclusion, but we might want to add ifndefs to 
avoid redefinition from other code due to the history of hack fixes for this 
issue.

Mike


On Jun 18, 2010, at 8:39 AM, Stefano Sabatini wrote:

 Hi all,
 
 I'm trying to use sofia-sip, compiling a project in Windows using
 MinGW (which would allow an Eclipse-based development environment).
 
 I'm using MS VS2005 for compiling libsofia-sip, as compilation with
 MinGW fails (see thread:
 Problem compiling sofia-sip 1.12.10 for MinGW
 http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/3853
 ).
 
 I fail to see if the config.h, when compiling with VS, has to be set
 by hand or if it is generated automatically as per the linux
 configuration.
 
 Furthermore, I'm failing to compile against sofia-sip headers, as
 MinGW already defines its inttypes and su_types.h is re-defining them.
 
 Even compiling with VS I believe those re-definitions should be
 avoided and I remember having had problems with them in the past.
 
 I suggest to require the user to install this instead:
 http://code.google.com/p/msinttypes/downloads/list
 
 The re-definition trick looks to me basically flawed, for example if a
 program uses more than one lib, and each one re-defines the int types,
 there will always be multiple definition problems whenever the headers
 of both the libs are included.
 
 Regards.
 
 --
 ThinkGeek and WIRED's GeekDad team up for the Ultimate 
 GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
 lucky parental unit.  See the prize list and enter to win: 
 http://p.sf.net/sfu/thinkgeek-promo
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Is sofia-sip dead?

[Michael Jerris]

On Jul 2, 2010, at 10:35 AM, Stefano Sabatini wrote:
 
 Hi Pekka,
 
 I tried:
 http://gitorious.org/sofia-sip
 
 but I see it contains exactly the same commits as the darcs repo, same
 for the mjerris branch.
 
 I'm trying in these days to compile sofia-sip in MinGW, which
 currently fails during configuration with the message:
 configure: error: printf cannot handle 64-bit integers
 
 It seems that Mike already fixed that:
 http://jira.freeswitch.org/browse/SFSIP-131
 
 so I'd like to see how he fixed the problem (and possibly get it
 integrated into the main sofia-sip repo) rather than re-invent the
 same solution from scratch.

I had thought that change got pushed quite some time ago:

http://fisheye.freeswitch.org/changelog/freeswitch-git/libs/sofia-sip?cs=ca02dec1c791301b3990deed90ec3bd0f362cb12

This is it from our tree iirc.
--
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

Re: [Sofia-sip-devel] [PATCH] Fix configuration under MinGW

[Michael Jerris]

Do these CFLAGS get into the build as well?  a bit worried that we need to do 
both this for the tests, and using top_ for the build.

Mike

On Jul 6, 2010, at 6:53 AM, Stefano Sabatini wrote:

 Hi all,
 
 this patch fixes the configuration problem as reported here:
 http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/3853
 
 $LIBS and $CFLAGS need to be expanded at the configuration level,
 otherwise when using them during configuration they will be wrong,
 resulting in many failing tests and in a fatal error which happens
 in the code from configure.ac:
 
 if test $ac_cv_c_ll_format = yes; then
  AC_DEFINE([LLU], [%llu], [Format (%llu) for unsigned long long])dnl
  AC_DEFINE([LLI], [%lli], [Format (%lli) for long long])dnl
  AC_DEFINE([LLX], [%llx], [Format (%llx) for long long hex])dnl
 else
  AC_MSG_ERROR(printf cannot handle 64-bit integers)
 fi
 
 This is what you can find in config.log:
 
 configure:24311: gcc -o conftest.exe -g -O2 -I./win32/pthread -DWINVER=0x0501
 -D_WIN32_WINNT=0x0501 -DIN_LIBSOFIA_SIP_UA -DIN_LIBSOFIA_SRES   -mms-bitfields
 -pipe -mno-cygwin -mwindows -mconsole -Wall -g -O0   
 -Wl,--enable-auto-image-bas
 e conftest.c -L$(top_srcdir)/win32/pthread -lpthreadVC2 -lws2_32
 -lwsock3
 2 5
 c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: cannot 
 fin
 d -lpthreadVC2
 collect2: ld returned 1 exit status
 configure:24311: $? = 1
 configure: program exited with status 1
 configure: failed program was:
 
 Patch attached, regards.
 0001-Fix-configuration-in-MinGW.patch--
 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


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

Re: [Sofia-sip-devel] [PATCH] Fix configuration under MinGW

[Michael Jerris]

I'll take a look at this issue.

Mike

On Jul 6, 2010, at 12:20 PM, Stefano Sabatini wrote:

 On date Tuesday 2010-07-06 11:55:57 -0400, Michael Jerris phoned:
 Do these CFLAGS get into the build as well?  a bit worried that we
 need to do both this for the tests, and using top_ for the build.
 
 Indeed I'm not sure this fix is right at all, at least it is working
 for me but it may badly fails in other scenarios. I have no special
 expertise with auto* tools, and I still can't grasp how it solves the
 problem of defining the same flags for both the configure file and the
 Makefile.
 
 Hope someone with expertise in that area (Pekka?) can shed some light.
 
 [...]
 
 Regards.


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

Re: [Sofia-sip-devel] Internal error at nua_stack.c:2388 on SUBSCRIBE

[Michael Jerris]

I think this was already fixed.  are you using latest release or git head?

Mike

On Aug 12, 2010, at 9:34 AM, Philippe Maymat wrote:

 Hi everybody,
 
 When I try to send SUSCRIBE with nua_subscribe with a REQUEST URI like :
 sip:name;attri...@societe.com, I get an internal error:
 
 Internal error at nua_stack.c:2388
 
 It seems to be due to the ;. With any other char, it works perfectly.
 
 Do you have an idea ?
 Thenak you very much
 
 --
 This SF.net email is sponsored by 
 
 Make an app they can't live without
 Enter the BlackBerry Developer Challenge
 http://p.sf.net/sfu/RIM-dev2dev 
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Internal error at nua_stack.c:2388 on SUBSCRIBE

[Michael Jerris]

Try the latest git repo.

Mike

On Aug 12, 2010, at 11:51 AM, Philippe Maymat wrote:

 I use the version 1.12.10. Is it the last one ? Or maybe there is a new 
 version somewhere ?
 
 Thank you for your help.
 
 Michael Jerris a écrit :
 
 I think this was already fixed.  are you using latest release or git head?
 
 Mike
 
 On Aug 12, 2010, at 9:34 AM, Philippe Maymat wrote:
 
   
 Hi everybody,
 
 When I try to send SUSCRIBE with nua_subscribe with a REQUEST URI like :
 sip:name;attri...@societe.com, I get an internal error:
 
 Internal error at nua_stack.c:2388
 
 It seems to be due to the ;. With any other char, it works perfectly.
 
 Do you have an idea ?
 Thenak you very much
 
 --
 This SF.net email is sponsored by 
 
 Make an app they can't live without
 Enter the BlackBerry Developer Challenge
 http://p.sf.net/sfu/RIM-dev2dev 
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
 
 
 
 
   
 

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia sip RFC2543

[Michael Jerris]

Looks like this is due to missing quotes around the display name.

Mike

On Aug 16, 2010, at 12:45 PM, Tech Micron wrote:

 Hi everyone,
 
 I have a SIP device that is working with RFC 2543. I am trying to send call 
 using Sofia-SIP (via FreeSwitch), but none of my calls are going through.
 I have traced the debug on SOFIA and it returned an error as below. Can 
 anyone help me to solve the problem? any hints?
 
 
 recv 660 bytes from udp/[66.220.15.230]:5060 at 18:45:21.239029:

INVITE sip:1...@66.220.15.234 SIP/2.0
v: SIP/2.0/UDP 66.220.15.230
To: sip:1...@66.220.15.234 sip:1...@66.220.15.234
From: john odu 
 sip:26679...@66.220.15.230;tag=4c5c58410003ac2076f6302c11fc3b7b
i: 41585c4c2ba3030035e697f0a586d...@66.220.15.230
CSeq: 1 INVITE
m: john odu sip:26679...@66.220.15.230
Supported: com.lilo.conferencing, com.lilo.mux
User-Agent: liloSipMCU/3.1.6.200801281402
c: application/sdp
l: 212

v=0
o=mcu 0 0 IN IP4 66.220.15.230
s=sip:26679...@66.220.15.230
c=IN IP4 66.220.15.230
t=0 0
m=audio 2006 RTP/AVP 0 111
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:111 telephone-event/8000
a=xlilossrc:8

 tport_deliver(0x97a1fb0): msg 0xb762bef8 (660 bytes) from 
 udp/66.220.15.230:5060/sip next=(nil)
 nta: received INVITE sip:1...@66.220.15.234 SIP/2.0 (CSeq 1)
 nta: INVITE has bad To header
 nta: INVITE (1) is Bad To Header
 tport_tsend(0x97a1fb0) tpn = UDP/66.220.15.230:5060
 tport_resolve addrinfo = 66.220.15.230:5060
 tport_by_addrinfo(0x97a1fb0): not found by name UDP/66.220.15.230:5060
 tport_vsend(0x97a1fb0): 239 bytes of 239 to udp/66.220.15.230:5060
 tport_vsend returned 239
 send 239 bytes to udp/[66.220.15.230]:5060 at 18:45:21.239369:

SIP/2.0 400 Bad To Header
Via: SIP/2.0/UDP 66.220.15.230
From: john odu 
 sip:26679...@66.220.15.230;tag=4c5c58410003ac2076f6302c11fc3b7b
Call-ID: 41585c4c2ba3030035e697f0a586d...@66.220.15.230
CSeq: 1 INVITE
Content-Length: 0
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Removing optimized from compile

[Michael Jerris]

make SOFIA_SILENT=


On Nov 10, 2010, at 10:05 AM, kai.vehma...@nokia.com kai.vehma...@nokia.com 
wrote:

 Hi,
 
 On 09 Nov 2010, Chris Robson wrote:
 Anyone know how to remove the -O2 optimize flag from the compile, aka
 ./configure --disable-???
 
 one quick way to compile without optimization is to do:
 
 make clean
 make CFLAGS=-O0 -g
 
 This should work with all projects using automake (including
 sofia-sip).
 
 PS On slightly different topic, is there any easy way to
   turn off the silent compilation mode for current
   sofia-sip master...? :P
 
 br,
 -- 
 Kai Vehmanen
 
 
 --
 The Next 800 Companies to Lead America's Growth: New Video Whitepaper
 David G. Thomson, author of the best-selling book Blueprint to a 
 Billion shares his insights and actions to help propel your 
 business during the next growth cycle. Listen Now!
 http://p.sf.net/sfu/SAP-dev2dev
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [SOFIA NTA MODULE]- - ACK is not forwarded from STACK to APPLICATION

[Michael Jerris]

Turn on NTA_DEBUG=9 and see if it provides any insight.  What response code are 
you getting?

Mike

On Dec 24, 2010, at 2:14 AM, manju nath wrote:

 
 HI
  
Am using sofia nta module in my applicaton, for the case shown below ACK 
 is coming to stack but these ACK is not getting forwarded from stack to my 
 application plz help in finding the reasons for that.
  
  
  uacstack  application
 uas
  
   INVITE   INVITE 
 INVITE
 -   --  
 
  
   400  400
400
 --  
 
  
   ACKACK  
  ACK
     
 XX
  
  
 ---message not reached


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

Re: [Sofia-sip-devel] Any Known Memory Leak in Version 1.12.11?

[Michael Jerris]

We have people doing millions of calls without memory leaks.  This sounds like 
there is something in the implementation that is not doing a destroy when it 
should.  Can you run in a memory debugger like valgrind and see what is being 
left behind?

Mike


On Apr 8, 2011, at 11:39 AM, Jerry Richards wrote:

 We pulled version 1.12.11 and did some load testing.  I have an automated 
 test that makes 2 phones complete calls to 1 phone iteratively.  We noticed 
 that the callers are losing a lot of memory over time.
  
 Using the previous sofia-sip version (1.12.9) each caller could make about 
 35,000 calls before it crashed (due to memory loss).  The newer version 
 (1.12.11) can only make about 5,500 calls before crashing due to memory loss.
  
 Thanks,
 Jerry
  
 --
 Xperia(TM) PLAY
 It's a major breakthrough. An authentic gaming
 smartphone on the nation's most reliable network.
 And it wants your games.
 http://p.sf.net/sfu/verizon-sfdev___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip SBC reference

[Michael Jerris]

Check out www.freeswitch.org.  It should already implement most of what your 
talking about.

Mike

On May 25, 2011, at 10:21 PM, Владимир Лучко wrote:

 Hello, everybody!
 I want to code SBC, using sofia-sip. Does has the project reference SBC (as, 
 for example opensipstack has OpenSBC)?
 Or may be there is some guide? My first try is not successeful. I create two 
 nua_t objects, set them NUTAG_URL with ip`s from the different networks. When 
 i got message on the first nua, i try to use SIPTAG_SIP (sip_t* obj) to 
 send it through the other nua. 
 
 Something like that:
 
 -
 /*NUA 1*/
 snprintf (bind_url, sizeof(bind_url), 
 sip:%s:5060;maddr=%s;transport=udp,tcp, IP1, IP1);
 trace_info (Bind SIP to %s\n, bind_url);
 g_nua1 = nua_create (g_root, sip_callback, NULL, NUTAG_URL (bind_url), 
 TAG_NULL ());
 ...
 nua_set_params (g_nua1, NUTAG_AUTOANSWER (0),  NUTAG_AUTOACK (0), 
 NUTAG_AUTO302 (0),
  NTATAG_PASS_100 (1), TAG_NULL ());
 
  snprintf (bind_url, sizeof(bind_url), 
 sip:%s:5060;maddr=%s;transport=udp,tcp, IP2, IP2);
  trace_info (Bind SIP to %s\n, bind_url);
  g_nua2 = nua_create (g_root, sip_callback, NULL, NUTAG_URL (bind_url), 
 NUTAG_AUTOANSWER (0),
   NUTAG_AUTOACK (0), NUTAG_AUTO302 (0), NTATAG_PASS_100 (1), TAG_NULL ());
  
 nua_set_params (g_nua2, NUTAG_AUTOANSWER (0), NUTAG_AUTOACK (0), 
 NUTAG_AUTO302 (0),
  NTATAG_PASS_100 (1), TAG_NULL ());
 
 
  static void
  sip_callback (nua_event_t event, int status, char const *phrase, nua_t * 
 nua, void * ctx_root,
  nua_handle_t * nh, void * ctx_handle, sip_t const *sip, tagi_t tags[])
  {
 ...
  nua_handle_t * nhn = nua_handle (g_nua2, NULL, TAG_NULL());
 ...
  nua_invite (nhn, SIPTAG_SIP(sip),TAG_NULL());
 }
 -
 
 Send invite to the nua1 ip and try to resend it into nua2. Got the error on 
 nua_invite:
 
 nua_stack.c:527: nua_signal: Assertion `b == bend' failed.
 
 Look into the stack code - does msgopbjtag_dup for duplicate sip tag work 
 wrong or is there other reason for that assertion?
 
 Thank you for answer.
 
 -- 
 Best regards, 
 Vladimir O. Luchko 
 Novosibirsk, Eltex
 E-mail: vlad.l...@mail.ru
 
 --
 vRanger cuts backup time in half-while increasing security.
 With the market-leading solution for virtual backup and recovery, 
 you get blazing-fast, flexible, and affordable data protection.
 Download your free trial now. 
 http://p.sf.net/sfu/quest-d2dcopy1___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] local sip port

[Michael Jerris]

NUTAG_URL()

pass it a string of the form

sip:user@ip:port

in nat scenarios you can add ;maddr=
with another ip:port

Mike

On Jul 7, 2011, at 12:37 PM, Nick Knight wrote:

 Hi,
 
 I have used sofia sip to create a TAPI bridge which works really
 nicely. But I have a niggle I can't find how to resolve.
 
 I am sure it is really simple, but for the life of me I cannot find
 out how to use a different local sip port (other than 5060).


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

Re: [Sofia-sip-devel] Sofia-Sip for FreeBSD

[Michael Jerris]

It compiles and to my knowledge works fine on fbsd.

Mike

On Nov 13, 2011, at 3:16 PM, ogogon wrote:
 Why in the operating system FreeBSD is not present ported distributive 
 of Sofia-SIP?
 I formed the opinion that the Sofia-SIP - the most advanced and 
 supported by SIP stack.
 Sofia-SIP is not portable to FreeBSD?


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Binding on 0.0.0.0 and sending to 127.0.0.1

[Michael Jerris]

Don't bind to 0.0.0.0.  Bind to the interface address of the network device 
that you want to show up in your sip packets.

Mike

On Sep 12, 2012, at 10:47 PM, Huang, Kun-Yao kxh...@dolby.com wrote:

 Hello:
 
 If I use call nua_create() with sip:0.0.0.0:* and then call nua_invite() to 
 another process listening at port 5060, I always get 503 service unavailable. 
 Am I doing something wrong?
 
 su_log_set_level(su_log_default, SU_LOG_MAX);
 su_log_set_level(su_log_global, SU_LOG_MAX);
 su_log_redirect(su_log_global, logger_callback, NULL);
 su_log_redirect(su_log_default, logger_callback, NULL);
 su_init();
 root = su_root_create(NULL);
 nua = nua_create(root, callback, NULL, NUTAG_URL(sip:0.0.0.0:*), 
 TAG_NULL());
 handle = nua_handle(nua, NULL, TAG_END());
 nua_invite(handle, SIPTAG_TO_STR(sip:127.0.0.1:5060), 
 SOATAG_USER_SDP_STR(sdp), NUTAG_AUTOACK(1),TAG_END());
 su_root_run(root);
 


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

Re: [Sofia-sip-devel] [patch] Fix crash in function nua_session_client_response of the file libsofia-sip-ua/nua/nua_session.c

[Michael Jerris]

https://www.gitorious.org/sofia-sip/sofia-sip/commit/8cb7baaab77fc3af351262933f0ae113d591fba1

My eyes didn't see the declaration for some reason.  Merged in the patch 
cleaned up a bit removing the commented out line.  Thanks.

On Mar 1, 2013, at 12:21 PM, Alexsander Petry alexsanderpe...@gmail.com wrote:

 Michael, ds has declared at line 937:
 nua_dialog_state_t *ds = NULL;
 
 Its compile and run fine.
 
 2013/3/1 Michael Jerris m...@jerris.com
 Looks like you commented out the declaration of ds.  Does this compile?
 
 On Mar 1, 2013, at 9:38 AM, Alexsander Petry alexsanderpe...@gmail.com 
 wrote:
 
 With this commit, sofia gets out when status = 300 and the call status is 
 changed from init to terminated (nua(0x82d4590): call state changed: init - 
 terminated) without crash.
 
 https://www.gitorious.org/~alexsanderpetry/sofia-sip/alexsanderpetry-sofia-sip/commit/750edd4ad4f810a4bb5e1472ceecb31b92a0d554
 
 -- 
 Alexsander Petry 
 
 
 
 -- 
 Alexsander Petry

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Does Sofia Have Option To Reject SIP Messages Not Coming From Proxy It Is Registered To?

[Michael Jerris]

Not explicitly, but its just a few lines of code in i_invite to make it do that.

Mike

On Mar 26, 2013, at 6:03 PM, Jerry Richards jerry.richa...@teotech.com wrote:

 Hello,
  
 As a phone endpoint (i.e. user agent), does sofia-sip have an option tag to 
 reject any SIP requests/messages not coming from the SIP proxy to which it is 
 registered?
  
 Best Regards,
 Jerry
  
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] REFER with REPLACES

[Michael Jerris]

Do you have replaces in your supported string?  try  SIPTAG_SUPPORTED_STR 
passing a string that includes replaces in nua_set_params or nua_create.  I 
assume the othe sides your talking to support replaces too?

On Apr 9, 2013, at 7:06 AM, John Graham johngavingra...@googlemail.com wrote:

 Hi there,
 
 I'm trying to use the Sofia-SIP library to perform an unattended call
 transfer. E.g. If I'm A and in a call with B and C, I thought I could
 transfer so that B and C are talking with something like:
 
sip_replaces_t *replaces = nua_handle_make_replace(nua_
 handle_B, NULL, 0);
nua_refer(nua_handle_B,
SIPTAG_REFER_TO_STR(addr_C),
SIPTAG_REPLACES(replaces),
TAG_END());
 
 However, when I do this I immediately get a nua_r_refer/400/Replaces
 header not allowed, and no further action is taken.
 
 I'd appreciate it if someone could point out my error, or what I can
 do to get around this.


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Upstream Submission of Patches

[Michael Jerris]

Hey Arsen- Long time no chat.  I can take a look at these.

Mike

On Apr 23, 2013, at 4:06 PM, Arsen Chaloyan achalo...@yahoo.com wrote:

 Hi,
 
 I would like to submit a number of patches applied over the latest git 
 version of the Sofia-SIP library.
 
 
 1. A local variable could be referenced out of its declaration scope which 
 caused a crash.
 
 http://www.unimrcp.org/dependencies/sofia-sip-1.12.11-196-g8cb7baa_crash1.patch
 
 2. A crash caused by possible deletion of a pthread data key which was not 
 created.
 
 http://www.unimrcp.org/dependencies/sofia-sip-1.12.11-196-g8cb7baa_crash2.patch
 
 3. A memory leak left when creation of the SIP stack failed due to an error.
 
 http://www.unimrcp.org/dependencies/sofia-sip-1.12.11-196-g8cb7baa_memory-leak.patch
 
 4. Fixed a compilation warning.
 
 http://www.unimrcp.org/dependencies/sofia-sip-1.12.11-196-g8cb7baa_compilation-warning1.patch
 
 5. Fixed a compilation warning.
 
 http://www.unimrcp.org/dependencies/sofia-sip-1.12.11-196-g8cb7baa_compilation-warning2.patch
 
 
 If you need additional details on the provided patches, I'd be glad to 
 further elaborate.
 
 Thanks for your attention.
 
 -- 
 Arsen Chaloyan
 Author of UniMRCP
 http://www.unimrcp.org
 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service 
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! 
 http://p.sf.net/sfu/newrelic_d2d_apr___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Plans for new release?

[Michael Jerris]

We are still very active on it inside of FreeSWITCH but we have not done a good 
job getting patches back in to the sofia-sip tree.  I do plan on fixing that 
soon as other patches have been coming in lately.

Mike

On May 3, 2013, at 6:24 AM, a.wehrm...@centersystems.com wrote:

 Hello!
 
 I wanted to inquire whether there are any plans for
 a new release of Sofia-SIP.
 I'm just asking because it's been quite some time since the last release now
 and from what I've seen on gitorious there have been some important changes
 mainly regarding the stability of the library (crashes).
 
 But I have also got other things on my mind:
 
 How active is this project?
 
 I like this library (as many other people seem to do as well)
 and would hate to see it fall back behind other popular SIP stacks
 because maintenance is poor to non-existent.
 At least judging from the activity (or inactivity) on the mailing list it 
 seems
 there is not much going on.
 Or is it because the library has matured enough?
 
 The web page should mention gitorious (or does it?).
 A while back it mentioned access to a Darcs repository
 which I can't find anymore.
 It would be nice to get access to the latest code without
 having to use Google to find the repository (that was before I knew about 
 gitorious).
 
 Nonetheless, great library and thanks for the work!
 
 
 Mit freundlichen Grüßen / Best regards 
 
 Andreas Wehrmann
 
 
 CENTER COMMUNICATION SYSTEMS GMBH
 
 Ein Unternehmen der STRABAG AG
 
 
 Software Development 
 
 Ignaz-Köck-Str. 19
 A-1210 Wien, Österreich
 
 Tel.: +43 (0) 190 199 - 3616
 Fax: +43 (0) 190 199 - 2110
 Mobil: +43 (0) 664 884 75916
 
 a.wehrm...@centersystems.com
 
 
 FN 796 88p, Sitz in Wien
 Firmenbuchgericht Wien
 
 http://www.centersystems.com/ www.centersystems.com
 
 Geschäftsführung: Ing. Gerhard Jelinek, Josef-Eduard Burger
 
 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Method Of Sending REGISTER To Different Proxy?

[Michael Jerris]

check out NUTAG_PROXY

On May 14, 2013, at 11:14 AM, Jerry Richards jerry.richa...@teotech.com wrote:

 Hello,
  
 I have sofia-sip setup with one NUA agent (i.e. one call to nua_create()).  
 Is there a way to send a REGISTER message to a proxy different than the 
 binding established via nua_create()?  The reason is, in a failover 
 condition, I want to find an easy way to periodically check if it can switch 
 back to the primary proxy server.
  
 Best Regards,
 Jerry

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 100 TRYING

[Michael Jerris]

Pretty sure there is no callback you get for the automatic 100's

Mike

On May 16, 2013, at 5:50 PM, jonathan augenstine jaugenst...@gmail.com wrote:

 I am working on an application and I would like to log the response of the 
 100 message.  What I notice is that when I compare the logging from the 
 sofia-sip callback handler to the tcpdump trace, I see that the tcpdump file 
 shows the 100 TRYING message, but I do not see it logged in the sofia 
 callback.  Is there something that I need to do to have the callback 
 triggered for the 100 message?
 
 Jonathan
 

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP for Windows - DLL

[Michael Jerris]

Yes

On Nov 4, 2013, at 8:51 AM, Thomas Volkert si...@gmx.net wrote:

 Hello,
 
 Have you also compiled it for Win64? Did it work?
 
 Best regards,
 Thomas.
 
 On 04.11.2013 14:11, Michael Jerris wrote:
 It builds find using msvc.
 
 Mike
 
 On Nov 3, 2013, at 6:44 AM, natalia Zakowka natzako...@gmail.com wrote:
 
 Hello,
 
 I would like to use Sofia Sip on Windows XP.
 
 I compile using GCC and I would like to have a DLL for using it.
 
 Would you know if a port (dll file) maybe be found?
 
 Thank you in advance and best regards,
 Nat.
 
 


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofsip-cli-0.16 bad response to incoming INVITE

[Michael Jerris]

This is some sort of optimizer issue in newer gcc.  The following patch from 
the freeswitch tree fixes it, also compiling -O0 will keep it from happening:

:git diff 016550f218fb0ea54aa6163d6a6eb7e02539da5e..HEAD 
libsofia-sip-ua/msg/msg_parser.c
diff --git a/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c 
b/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
index d75b975..c312445 100644
--- a/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
+++ b/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
@@ -2470,8 +2470,6 @@ int msg_header_prepend(msg_t *msg,
 msg_header_t **
 msg_hclass_offset(msg_mclass_t const *mc, msg_pub_t const *mo, msg_hclass_t 
*hc)
 {
-  int i;
-
   assert(mc  hc);
 
   if (mc == NULL || hc == NULL)
@@ -2483,12 +2481,16 @@ msg_hclass_offset(msg_mclass_t const *mc, msg_pub_t 
const *mo, msg_hclass_t *hc)
   if (mc-mc_hash[j].hr_class == hc) {
return (msg_header_t **)((char *)mo + mc-mc_hash[j].hr_offset);
   }
-  }
-  else
+  } else {
 /* Header has no name. */
-for (i = 0; i = 6; i++)
-  if (hc-hc_hash == mc-mc_request[i].hr_class-hc_hash)
-   return (msg_header_t **)((char *)mo + mc-mc_request[i].hr_offset);
+if (hc-hc_hash == mc-mc_request[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_request[0].hr_offset);
+if (hc-hc_hash == mc-mc_status[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_status[0].hr_offset);
+if (hc-hc_hash == mc-mc_separator[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_separator[0].hr_offset);
+if (hc-hc_hash == mc-mc_payload[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_payload[0].hr_offset);
+if (hc-hc_hash == mc-mc_unknown[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_unknown[0].hr_offset);
+if (hc-hc_hash == mc-mc_error[0].hr_class-hc_hash) return (msg_header_t 
**)((char *)mo + mc-mc_error[0].hr_offset);
+if (hc-hc_hash == mc-mc_multipart[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_multipart[0].hr_offset);
+  }
 
   return NULL;
 }


On Nov 13, 2013, at 4:14 AM, Jabran Bhatti jabran@gmail.com wrote:

 Hello,
 
 I am running the example program sofsip-cli-0.16 with dummy media
 implementaition. I can successfully register with freeswitch. After
 sending a 180 Ringing, the program tries to respond to an incoming
 INVITE with the following message
 
   
 send 657 bytes to udp/[10.0.10.110]:5060 at 08:38:50.939046:
   
   v=0
   o=- 7379759665580148502 4675863509426113643 IN IP4 10.0.56.22
   s=-
   c=IN IP4 10.0.56.22
   t=0 0
   m=audio 16384 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   Via: SIP/2.0/UDP 10.0.10.110;rport=5060;branch=z9hG4bK3pFQt22y2Q01K
   From: Extension 1007 sip:1007@10.0.10.110;tag=BH2jBj102ZQvm
   To: sip:(null)@10.0.56.22;tag=HFeSteF09p7Fr
   Call-ID: 97ef089d-c6e1-1231-27bb-09086510
   CSeq: 51829843 INVITE
   Contact: sip:10.0.56.22
   User-Agent: sofia-sip/1.12.11
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE,
 SUBSCRIBE, NOTIFY, REFER, UPDATE
   Supported: timer, 100rel
   Content-Type: application/sdp
   Content-Disposition: session
   Content-Length: 0
 
 
 I get this message in the console output by setting TPORT_LOG=1.
 
 As far as I know, the SDP content should be in the message body
 (resulting in a non-zero content-length). Has anyone else encountered
 this issue?
 This message never shows up in wireshark though, indicating that sofia
 sip does send the weirdly constructed response.
 Anywho, could someone tell me how I could easily get the sdp into the
 message body with nua?
 
 I also noted that no 100 Trying is sent before the 180 Ringing...
 
 Many thanks in advance!
 
 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Sofia-sip-devel mailing list

Re: [Sofia-sip-devel] status of sofia sip

[Michael Jerris]

Pekka is no longer at Nokia.  I think I am the only one with commit access to 
the gitorious tree still around and responding at all.  I don't have the 
ability to roll releases.  There are still plenty of people working on 
sofia-sip from what I can see, but yeah, no official maintainer who is around 
and actively working on anything.

Mike

On Nov 18, 2013, at 7:18 AM, Dave Horton d...@dchorton.com wrote:

 Personally, I would prefer to see it moved to github, where I find the tools 
 are a bit better for this kind of collaboration (e.g. forking).   But this 
 project mostly seems to need a lead maintainer (and I, also, am not blaming 
 Pekka - I imagine there has been an avalanche of changes and new directions 
 at nokia in the past year or so).  That someone is probably not me -- I'd be 
 happy to submit fixes, and have some degree of knowledge of nta, but I don't 
 think my knowledge is good enough at the moment to review bug fixes across 
 the scope of the product.
 
 
 On Nov 18, 2013, at 11:37 AM, Andreas Wehrmann andreas_wehrm...@yahoo.at 
 wrote:
 
 
 On 11/18/2013 10:04 AM, Dave Horton wrote:
 Hi Andreas -
 
 Yes, I went back and read your question.  Looks like it never really got 
 answered, and then sidetracked into a specific bug fix discussion.  And 
 while it would be great to get fixes from Freeswitch back in, that clearly 
 isn't happening yet.  If I am reading the commit history in gitorious 
 correctly (as you'd mentioned, just finding out that is where it was hosted 
 was a fairly random occurrence), things ground to a halt a couple of years 
 ago with Pekka's last commit.  Also, Freeswitch uses nua but I prefer to use 
 nta in most of my projects.  I see a handful of merge requests being opened 
 but not being addressed.
 
 For now I've created my own clone on gitorious, like a few others have done. 
  I suppose like others that have done this I will can cherry-pick commits 
 that look useful from other people's clones, but this is slapdash and does 
 kind of both concern me and sadden me to see a useful product that seems to 
 be dying slowly from lack of support.  I'd be interested in feedback that 
 either (a) tells me I'm wrong, and why or (b) provides suggestion on other 
 (modern, supported, open, C/C++) sip stacks that I ought to be looking at.
 
 Dave
 
 
 I would need to agree with you there.
 I was often wondering who is responsible for Sofia.
 That would seem to be Pekka but he seems to be concerned with other things 
 (I'm not blaming him, just pointing it out)
 and there's apparently nobody else?
 
 What I find a little bit odd is that the official branch of Sofia seems to 
 have come to a halt although there seem to be lots of people
 using it. The question that bothers me is: Why didn't changes from these 
 people flow back to the official version?
 (guess that's because Pekka is (the only?) maintainer and just didn't have 
 the time).
 
 The FreeSwitch guys seem to do a good job but the I think the sofia-sip 
 version in the FreeSwitch repo is to be considered a fork,
 not just a branch of the official repo?
 
 I think this library needs more maintainers.
 
 Thoughts, anyone?
 
 
 
 
 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] strange bug surfaces on Fedora 20 and Mint using SIPTAG_PAYLOAD_STR

[Michael Jerris]

Looks about right.. i had something very similar from the FreeSWITCH tree:

diff --git a/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c 
b/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
index d75b975..c312445 100644
--- a/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
+++ b/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
@@ -2470,8 +2470,6 @@ int msg_header_prepend(msg_t *msg,
 msg_header_t **
 msg_hclass_offset(msg_mclass_t const *mc, msg_pub_t const *mo, msg_hclass_t 
*hc)
 {
-  int i;
-
   assert(mc  hc);
 
   if (mc == NULL || hc == NULL)
@@ -2483,12 +2481,16 @@ msg_hclass_offset(msg_mclass_t const *mc, msg_pub_t 
const *mo, msg_hclass_t *hc)
   if (mc-mc_hash[j].hr_class == hc) {
return (msg_header_t **)((char *)mo + mc-mc_hash[j].hr_offset);
   }
-  }
-  else
+  } else {
 /* Header has no name. */
-for (i = 0; i = 6; i++)
-  if (hc-hc_hash == mc-mc_request[i].hr_class-hc_hash)
-   return (msg_header_t **)((char *)mo + mc-mc_request[i].hr_offset);
+if (hc-hc_hash == mc-mc_request[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_request[0].hr_offset);
+if (hc-hc_hash == mc-mc_status[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_status[0].hr_offset);
+if (hc-hc_hash == mc-mc_separator[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_separator[0].hr_offset);
+if (hc-hc_hash == mc-mc_payload[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_payload[0].hr_offset);
+if (hc-hc_hash == mc-mc_unknown[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_unknown[0].hr_offset);
+if (hc-hc_hash == mc-mc_error[0].hr_class-hc_hash) return (msg_header_t 
**)((char *)mo + mc-mc_error[0].hr_offset);
+if (hc-hc_hash == mc-mc_multipart[0].hr_class-hc_hash) return 
(msg_header_t **)((char *)mo + mc-mc_multipart[0].hr_offset);
+  }
 
   return NULL;
 }


On Apr 24, 2014, at 10:26 AM, Dave Horton d...@dchorton.com wrote:

 I recently came across a problem that manifested only on Fedora 20 and Mint 
 (not on Ubunto or Centos 6.x).  When using SIPTAG_PAYLOAD_STR to add a body 
 to an outgoing SIP message, the message goes out without any body; i.e., it's 
 as if that tag was silently ignored.  My program would also subsquently 
 crash.  Again, this problem was only experienced on certain Linux distros
 
 I eventually tracked it to this code in the msg_hclass_offset function in 
 msg_parser.c.
 
   else
 /* Header has no name. */
 for (i = 0; i = 6; i++)
   if (hc-hc_hash == mc-mc_request[i].hr_class-hc_hash)
   return (msg_header_t **)((char *)mo + mc-mc_request[i].hr_offset);
 
 
 Something in that non-standard way of iterating through the msg_href_t 
 elements in the msg_mclass_s structure was causing weird results.  When I 
 stepped through the code, which is supposed to iterate across the bolded 
 elements in the struct below (you can see that I call it non-standard 
 because it is incrementing across an array that has only one member, but 
 using that as a device to check each of the 6 members) what I saw was that an 
 incorrect match was returned, and thus the offset to the sip_payload_t member 
 which this function returns was incorrect.  Hence the bad things happened.  
 
 struct msg_mclass_s
 {
   struct msg_hclass_s
 mc_hclass[1]; /** Recursive header class */
   char const   *mc_name; /** Protocol name, e.g., SIP/2.0 */
   void *mc_tag;  /** Protocol-specific tag */
   unsigned  mc_flags; /** Default flags */
   unsigned  mc_msize; /** Size of public message structure */
   /** Function extracting the message contents. */
   issize_t(*mc_extract_body)(msg_t *msg, msg_pub_t *pub,
  char b[], isize_t bsiz, int eos);
 
   msg_href_tmc_request[1]; /** Request line reference */
   msg_href_tmc_status[1]; /** Status line reference */
   msg_href_tmc_separator[1];/** Separator line reference */
   msg_href_tmc_payload[1]; /** Message body reference */
   msg_href_tmc_unknown[1]; /** Reference for unknown headers */
   msg_href_tmc_error[1]; /** Reference for erroneous header */
   msg_href_tmc_multipart[1];/** Multipart body reference */
   msg_href_t const *
 mc_short; /** Short forms (or NULL) */
   short mc_hash_size; /** Size of parsing table  */
   short mc_hash_used; /** Number of headers in parsing table */
   /** Hash table for parsing containing reference for each header. */
   msg_href_tmc_hash[MC_HASH_SIZE];
 };
 
 Here is my commit that fixed things in my public repo: 
 https://github.com/davehorton/sofia-sip/commit/51bb86448d952a5997a8d7e38c545c164fa112a2
 
 Dave
 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open 

Re: [Sofia-sip-devel] strange bug surfaces on Fedora 20 and Mint using SIPTAG_PAYLOAD_STR

[Michael Jerris]

Our full history is:

http://fisheye.freeswitch.org/changelog/FreeSWITCH/libs/sofia-sip?max=30view=fe

or just pull directly from freeswitch git tree... the issue is, some of our 
fixes change behavior statically instead of having a tag to change behavior, so 
all the patches may not be appropriate.. Its on my list to start moving the 
good patches back into the sofia-sip tree, but i never seem to find the time.  
That being said, if you want to put some time in to that, I'd be happy to do 
the actual pushes to gitorious tree, just let me know.

Mike


On Apr 24, 2014, at 10:56 AM, Dave Horton d...@dchorton.com wrote:

 Thanks, that looks exactly like the same bug (and fix). Just out of interest, 
 what kind of problem and what platform did you see problems manifest that led 
 you to make this fix ?  
 
 I haven't looked closely at the freeswitch fixes that haven't been ported 
 back anywhere, but now I think I should.  Can you send me a link to a commit 
 history?
 
 Dave
 On Apr 24, 2014, at 10:52 AM, Michael Jerris m...@jerris.com wrote:
 
 Looks about right.. i had something very similar from the FreeSWITCH tree:
 
 diff --git a/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c 
 b/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
 index d75b975..c312445 100644
 --- a/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
 +++ b/libs/sofia-sip/libsofia-sip-ua/msg/msg_parser.c
 @@ -2470,8 +2470,6 @@ int msg_header_prepend(msg_t *msg,
  msg_header_t **
  msg_hclass_offset(msg_mclass_t const *mc, msg_pub_t const *mo, msg_hclass_t 
 *hc)
  {
 -  int i;
 -
assert(mc  hc);
  
if (mc == NULL || hc == NULL)
 @@ -2483,12 +2481,16 @@ msg_hclass_offset(msg_mclass_t const *mc, msg_pub_t 
 const *mo, msg_hclass_t *hc)
if (mc-mc_hash[j].hr_class == hc) {
 return (msg_header_t **)((char *)mo + mc-mc_hash[j].hr_offset);
}
 -  }
 -  else
 +  } else {
  /* Header has no name. */
 -for (i = 0; i = 6; i++)
 -  if (hc-hc_hash == mc-mc_request[i].hr_class-hc_hash)
 -   return (msg_header_t **)((char *)mo + mc-mc_request[i].hr_offset);
 +if (hc-hc_hash == mc-mc_request[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_request[0].hr_offset);
 +if (hc-hc_hash == mc-mc_status[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_status[0].hr_offset);
 +if (hc-hc_hash == mc-mc_separator[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_separator[0].hr_offset);
 +if (hc-hc_hash == mc-mc_payload[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_payload[0].hr_offset);
 +if (hc-hc_hash == mc-mc_unknown[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_unknown[0].hr_offset);
 +if (hc-hc_hash == mc-mc_error[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_error[0].hr_offset);
 +if (hc-hc_hash == mc-mc_multipart[0].hr_class-hc_hash) return 
 (msg_header_t **)((char *)mo + mc-mc_multipart[0].hr_offset);
 +  }
  
return NULL;
  }
 
 
 On Apr 24, 2014, at 10:26 AM, Dave Horton d...@dchorton.com wrote:
 
 I recently came across a problem that manifested only on Fedora 20 and Mint 
 (not on Ubunto or Centos 6.x).  When using SIPTAG_PAYLOAD_STR to add a body 
 to an outgoing SIP message, the message goes out without any body; i.e., 
 it's as if that tag was silently ignored.  My program would also subsquently 
 crash.  Again, this problem was only experienced on certain Linux distros
 
 I eventually tracked it to this code in the msg_hclass_offset function in 
 msg_parser.c.
 
   else
 /* Header has no name. */
 for (i = 0; i = 6; i++)
   if (hc-hc_hash == mc-mc_request[i].hr_class-hc_hash)
  return (msg_header_t **)((char *)mo + mc-mc_request[i].hr_offset);
 
 
 Something in that non-standard way of iterating through the msg_href_t 
 elements in the msg_mclass_s structure was causing weird results.  When I 
 stepped through the code, which is supposed to iterate across the bolded 
 elements in the struct below (you can see that I call it non-standard 
 because it is incrementing across an array that has only one member, but 
 using that as a device to check each of the 6 members) what I saw was that 
 an incorrect match was returned, and thus the offset to the sip_payload_t 
 member which this function returns was incorrect.  Hence the bad things 
 happened.  
 
 struct msg_mclass_s
 {
   struct msg_hclass_s
 mc_hclass[1]; /** Recursive header class */
   char const   *mc_name; /** Protocol name, e.g., SIP/2.0 */
   void *mc_tag;  /** Protocol-specific tag */
   unsigned  mc_flags; /** Default flags */
   unsigned  mc_msize; /** Size of public message structure */
   /** Function extracting the message contents. */
   issize_t(*mc_extract_body)(msg_t *msg, msg_pub_t *pub,
  char b[], isize_t bsiz, int eos);
 
   msg_href_tmc_request[1]; /** Request line reference

Re: [Sofia-sip-devel] How To Respond To In-Dialog NOTIFY?

[Michael Jerris]

use NUTAG_WITH_THIS_MSG(msg) where msg is the msg passed to the original 
callback.

On May 8, 2014, at 12:21 PM, Jerry Richards jerry.richa...@teotech.com wrote:

 Hello,
  
 I’m trying to handle an in-dialog NOTIFY Event hold/talk message (i.e. to put 
 a call on-hold and take off-hold) from a SIP server.  The NOTIFY has no 
 subscription and sofia-sip reports the nua_i_notify event with the same 
 nua_handle as the INVITE.
  
 The problem is when I invoke nua_respond(nh, status, phrase) from the 
 callback function in response to the NOTIFY message, sofia-sip comes back 
 with 500 Responding to a Non-Existing Request.
  
 What would be the proper way to respond to this?
  
 Thanks,
 Jerry

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] How To Respond To In-Dialog NOTIFY?

[Michael Jerris]

sorry, we actually only need to do all that because we handle those in a 
different thread than the callback, if your handling in the callback, you can 
NUTAG_WITH_THIS(nua)

On May 8, 2014, at 3:36 PM, Jerry Richards jerry.richa...@teotech.com wrote:

 Thanks, Michael.  By the way, do you know how to convert a sip_t pointer into 
 a msg_t pointer?  My callback function gets a sip_t pointer.
  
 Regards,
 Jerry
  
 From: Michael Jerris [mailto:m...@jerris.com] 
 Sent: Thursday, May 08, 2014 11:07 AM
 To: Jerry Richards
 Cc: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] How To Respond To In-Dialog NOTIFY?
  
 use NUTAG_WITH_THIS_MSG(msg) where msg is the msg passed to the original 
 callback.
  
 On May 8, 2014, at 12:21 PM, Jerry Richards jerry.richa...@teotech.com 
 wrote:
 
 
 Hello,
  
 I’m trying to handle an in-dialog NOTIFY Event hold/talk message (i.e. to put 
 a call on-hold and take off-hold) from a SIP server.  The NOTIFY has no 
 subscription and sofia-sip reports the nua_i_notify event with the same 
 nua_handle as the INVITE.
  
 The problem is when I invoke nua_respond(nh, status, phrase) from the 
 callback function in response to the NOTIFY message, sofia-sip comes back 
 with 500 Responding to a Non-Existing Request.
  
 What would be the proper way to respond to this?
  
 Thanks,
 Jerry

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel