Re: [Sofia-sip-devel] nua: initializing SIP stack failed
In data Wednesday 2010-07-07 17:51:00 +0300, Pekka Pessi ha scritto: 2010/6/30 Stefano Sabatini ssabat...@reilabs.com: Hi all, I'm running this simple code in Windows Vista: nta: master transport created tport(00F27958) to */*:*/sip tport(00F27958): calling tport_listen for udp tport(00F27958): new primary tport 00F28128 tport(00F27958): bind(pf=2 udp/[192.168.0.1]): No such file or directory nta: bind(*:*;transport=*): No such file or directory nua: initializing SIP stack failed Can you suggest what the problem may be? For some reason binding a socket to IP address 192.168.0.1 fails. Where the address comes from? Does you Vista box try to share internet connection? If you can compile and run localinfo command, see what it prints? You can also modify NUTAG_URL(sip:stef...@*:*) so it explicitly mentions the IP address, e.g., NUTAG_URL(sip:stef...@*:*;maddr=10.2.3.4) Hi Pekka, yes that looked like a configuration issue, we fixed the problem by hardcoding the address of the interface to be used, using something like this: NUTAG_URL(sip:X.Y.Z.W:*); and *disabling* all the other interfaces. Sorry that I have no time to investigate more on this... Thanks, 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] [PATCH] Fix gai_strerror re-declaration in MinGW
On date Wednesday 2010-07-07 17:30:57 +0300, Pekka Pessi phoned this: 2010/7/6 Stefano Sabatini ssabat...@reilabs.com: Hi, as in subject. The patch requires to run autoheader to re-generate the config.h.in file. Thanks for patch. I wonder if it is enough just to #undef gai_strerror? No need to check its declaration? Exactly, this way the patch is much simpler. Regards. From 3ed1bea1f042248645e25d4b26f4f57dcf12f6ce Mon Sep 17 00:00:00 2001 From: Stefano Sabatini ssabat...@reilabs.com Date: Tue, 6 Jul 2010 15:43:13 +0200 Subject: [PATCH 2/2] Undefine gai_strerror symbol if the function is not defined. Avoid a re-definition issue and fix compilation in MinGW, where gai_strerror is declared but not defined. --- libsofia-sip-ua/su/su_addrinfo.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libsofia-sip-ua/su/su_addrinfo.c b/libsofia-sip-ua/su/su_addrinfo.c index c8005c0..6637da3 100644 --- a/libsofia-sip-ua/su/su_addrinfo.c +++ b/libsofia-sip-ua/su/su_addrinfo.c @@ -820,6 +820,8 @@ freeaddrinfo(ai) #endif #if !HAVE_GAI_STRERROR +#undef gai_strerror + static char * gai_strerror(ecode) -- 1.7.1 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] su/su_win32_port.c compilation in MinGW
Hi all, I cannot find a way of getting su_win32_port.c compiled and added to libsofia_sip in MinGW. This is causing the following failure: gcc -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 -Wl,--enable-auto-image-base -o stunc.exe stunc.o ./.libs/libstun.a -L/c/x/y/sofia-sip_1_12_10/win32/pthread ../sresolv/.libs/libsresolv.a ../su/.libs/libsu.a -L./win32/pthread -lpthread -l pthreadVC2 -lws2_32 -lwsock32 ../su/.libs/libsu.a(su_port.o): In function `su_default_port_create': c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:63: undefined reference to `su_wsaevent_port_create' ../su/.libs/libsu.a(su_port.o): In function `su_default_clone_start': c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:86: undefined reference to `su_wsaevent_clone_start' ../su/.libs/libsu.a(su_port.o): In function `su_port_set_system_preferences': c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:142: undefined reference to `su_wsaevent_port_create' c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:143: undefined reference to `su_wsaevent_clone_start' collect2: ld returned 1 exit status make[4]: *** [stunc.exe] Error 1 make[4]: Leaving directory `/c/x/y/sofia-sip_1_12_10/libsofia-sip-ua/stun' make[3]: *** [all] Error 2 make[3]: Leaving directory `/c/x/y/sofia-sip_1_12_10/libso fia-sip-ua/stun' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/x/y/sofia-sip_1_12_10/libsofia-sip-ua' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/x/y/sofia-sip_1_12_10' make: *** [all] Error 2 Can you suggest how to fix this? 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] su/su_win32_port.c compilation in MinGW
On date Thursday 2010-07-08 10:43:28 +0200, Stefano Sabatini phoned this: Hi all, I cannot find a way of getting su_win32_port.c compiled and added to libsofia_sip in MinGW. This is causing the following failure: gcc -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 -Wl,--enable-auto-image-base -o stunc.exe stunc.o ./.libs/libstun.a -L/c/x/y/sofia-sip_1_12_10/win32/pthread ../sresolv/.libs/libsresolv.a ../su/.libs/libsu.a -L./win32/pthread -lpthread -l pthreadVC2 -lws2_32 -lwsock32 ../su/.libs/libsu.a(su_port.o): In function `su_default_port_create': c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:63: undefined reference to `su_wsaevent_port_create' ../su/.libs/libsu.a(su_port.o): In function `su_default_clone_start': c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:86: undefined reference to `su_wsaevent_clone_start' ../su/.libs/libsu.a(su_port.o): In function `su_port_set_system_preferences': c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:142: undefined reference to `su_wsaevent_port_create' c:\x\y\sofia-sip_1_12_10\libsofia-sip-ua\su/su_port.c:143: undefined reference to `su_wsaevent_clone_start' collect2: ld returned 1 exit status make[4]: *** [stunc.exe] Error 1 make[4]: Leaving directory `/c/x/y/sofia-sip_1_12_10/libsofia-sip-ua/stun' make[3]: *** [all] Error 2 make[3]: Leaving directory `/c/x/y/sofia-sip_1_12_10/libso fia-sip-ua/stun' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/x/y/sofia-sip_1_12_10/libsofia-sip-ua' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/x/y/sofia-sip_1_12_10' make: *** [all] Error 2 Can you suggest how to fix this? Found a way which works for me, it feels a bit unelegant and I'm not sure this is the best solution (no auto* expertise). You need to run autoreconf to update libsofia-sip-ua/su/Makefile.in. Regards. From 1c7dfdb69706c224f7eea82fb06562d927b04550 Mon Sep 17 00:00:00 2001 From: Stefano Sabatini ssabat...@reilabs.com Date: Thu, 8 Jul 2010 15:49:25 +0200 Subject: [PATCH 2/2] Compile and link su_win32_port.c when the target OS is MinGW. Fix linking in MinGW. --- configure.ac |2 ++ libsofia-sip-ua/su/Makefile.am |3 +++ 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 4f48650..f81fde4 100644 --- a/configure.ac +++ b/configure.ac @@ -26,6 +26,8 @@ AC_SUBST(LIBVER_SOFIA_SIP_UA_GLIB_REV, [0]) AC_SUBST(LIBVER_SOFIA_SIP_UA_GLIB_AGE, [0]) AC_SUBST(LIBVER_SOFIA_SIP_UA_GLIB_SOVER, [3]) # CUR-AGE +AM_CONDITIONAL(TARGET_OS_MINGW32, test x$target_os = xmingw32) + ## calls AC_CANONICAL_ macros that are required by AM_INIT_AUTOMAKE SAC_CANONICAL_SYSTEM_CACHE_CHECK diff --git a/libsofia-sip-ua/su/Makefile.am b/libsofia-sip-ua/su/Makefile.am index db3a331..8775699 100644 --- a/libsofia-sip-ua/su/Makefile.am +++ b/libsofia-sip-ua/su/Makefile.am @@ -76,6 +76,9 @@ libsu_la_SOURCES = \ su_md5.c su_uniqueid.c su_bm.c smoothsort.c su_string.c string0.c \ $(OSXSOURCES) +if TARGET_OS_MINGW32 +libsu_la_SOURCES += su_win32_port.c +endif EXTRA_libsu_la_SOURCES = \ memmem.c strtoull.c \ -- 1.7.1 -- 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
On date Tuesday 2010-07-06 19:35:38 +0300, Pekka Pessi phoned this:
2010/7/6 Stefano Sabatini ssabat...@reilabs.com:
this patch fixes the configuration problem as reported here:
http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/3853
Thanks for the patch.
-CFLAGS=$CFLAGS -I\$(top_srcdir)/win32/pthread -DWINVER=0x0501 \
+CFLAGS=$CFLAGS -I${srcdir}/win32/pthread -DWINVER=0x0501 \
Can you actually compile sofia-sip with this? It seems to me that the
relative srcdir does dot work when make descends deeper into source
tree.
Mmh no, indeed compilation was failing with a libtool error (I had to
hack the generated libtool script to fix it, as reported in another
thread).
So it seems that the patch defined in sac-general.m4 needs to be
*absolute*. I tried to use $abs_srcdir but that is expanded to the
empty string, then I hacked this:
abs_srcdir=`(cd $srcdir pwd)`
CFLAGS=$CFLAGS -I${abs_srcdir}/win32/pthread -DWINVER=0x0501 \ ...
and now it is working (configure and libtool and all).
Now I need to understand why it isn't expanding $abs_srcdir...
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
[Sofia-sip-devel] [PATCH] Fix configuration under MinGW
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.
From 7d74c8b50b33469667006c50e902e690620ce5dd Mon Sep 17 00:00:00 2001
Message-Id: 7d74c8b50b33469667006c50e902e690620ce5dd.1278413394.git.stefano.sabatini-l...@poste.it
From: Stefano Sabatini stefano.sabatini-l...@poste.it
Date: Tue, 6 Jul 2010 12:28:11 +0200
Subject: [fix-mingw-compilation PATCH] Fix configuration in MinGW.
CFLAGS and LIBS need to be expanded at configuration time, otherwise
many configure test will fail and the configure will abort with the
message:
configure: error: printf cannot handle 64-bit integers
---
m4/sac-general.m4 |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/m4/sac-general.m4 b/m4/sac-general.m4
index b494de1..de0ba9a 100644
--- a/m4/sac-general.m4
+++ b/m4/sac-general.m4
@@ -359,12 +359,12 @@ fi
])
if test $ac_cc_environment = mingw32 ; then
-CFLAGS=$CFLAGS -I\$(top_srcdir)/win32/pthread -DWINVER=0x0501 \
+CFLAGS=$CFLAGS -I${srcdir}/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
LDFLAGS=$LDFLAGS -Wl,--enable-auto-image-base
-LIBS=-L\$(top_srcdir)/win32/pthread -lpthreadVC2 -lws2_32 \
+LIBS=-L${srcdir}/win32/pthread -lpthreadVC2 -lws2_32 \
-lwsock32
MINGW_ENVIRONMENT=1
AC_SUBST(MINGW_ENVIRONMENT)
--
1.7.1
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [PATCH] Fix gai_strerror re-declaration in MinGW
Hi, as in subject.
The patch requires to run autoheader to re-generate the config.h.in
file.
Regards.
From c75913c29b31450936a366f4b918bb29cde461e7 Mon Sep 17 00:00:00 2001
Message-Id: c75913c29b31450936a366f4b918bb29cde461e7.1278424181.git.ssabat...@reilabs.com
In-Reply-To: df35791318679319f17f1ad01b104a6dca265786.1278424181.git.ssabat...@reilabs.com
References: df35791318679319f17f1ad01b104a6dca265786.1278424181.git.ssabat...@reilabs.com
From: Stefano Sabatini ssabat...@reilabs.com
Date: Tue, 6 Jul 2010 15:43:13 +0200
Subject: [fix-mingw-compilation PATCH 2/2] Avoid gai_strerror redefinition if it has been already declared.
Fix compilation on MinGW (where it is declared but not defined).
---
libsofia-sip-ua/su/su_addrinfo.c |4
m4/sac-general.m4|6 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/libsofia-sip-ua/su/su_addrinfo.c b/libsofia-sip-ua/su/su_addrinfo.c
index c8005c0..4663fee 100644
--- a/libsofia-sip-ua/su/su_addrinfo.c
+++ b/libsofia-sip-ua/su/su_addrinfo.c
@@ -820,6 +820,10 @@ freeaddrinfo(ai)
#endif
#if !HAVE_GAI_STRERROR
+#if HAVE_DECL_GAI_STRERROR
+#undef gai_strerror
+#endif
+
static
char *
gai_strerror(ecode)
diff --git a/m4/sac-general.m4 b/m4/sac-general.m4
index de0ba9a..ec42733 100644
--- a/m4/sac-general.m4
+++ b/m4/sac-general.m4
@@ -359,6 +359,9 @@ fi
])
if test $ac_cc_environment = mingw32 ; then
+
+AC_CHECK_DECLS([gai_strerror], [], [], [[#include ws2tcpip.h]])
+
CFLAGS=$CFLAGS -I${srcdir}/win32/pthread -DWINVER=0x0501 \
-D_WIN32_WINNT=0x0501 -DIN_LIBSOFIA_SIP_UA -DIN_LIBSOFIA_SRES \
-mms-bitfields \
@@ -370,7 +373,10 @@ MINGW_ENVIRONMENT=1
AC_SUBST(MINGW_ENVIRONMENT)
AC_DEFINE([HAVE_MINGW], [1], [Define to 1 if you are compiling in MinGW environment])
AC_DEFINE([HAVE_WIN32], [1], [Define to 1 if you have WIN32])
+else
+AC_CHECK_DECLS([gai_strerror])
fi
+
AM_CONDITIONAL([HAVE_MINGW32], [test x$ac_cc_environment != x])
])dnl
--
1.7.1
--
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] Is sofia-sip dead?
On date Monday 2010-06-28 22:24:24 +0300, Pekka Pessi phoned this: 2010/6/18 Stefano Sabatini ssabat...@reilabs.com: On date Thursday 2010-06-17 01:26:51 -0400, Michael Jerris phoned this: 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. The last darcs commit: Tue Sep 29 14:24:17 CEST 2009 Pekka Pessi first.l...@nokia.com Bug report and original patch by Timo Bruhn. and there hasn't been much activity from the maintainers in the last months and the project somehow didn't managed to get a significant community of developers/contributors. That said, there are many projects depending on sofia-sip, so I hope that there will be enough interest to keep the project alive and possibly make it better, switching to a less obscure SCCS may help. Well, yes, we are currently trying to switch over to git. The git repository is available at http://gitorious.org/sofia-sip The master branch currently contains the more or less the same commits as the darcs repository at sofia-sip.org. It would be useful to mention also that on the sf.net. The next features (and bug fixes) mostly involve DNS resolving and transport handling. There seems to be some nasty bugs in transport handling that might be hard to fix unless some backwards-incompatible changes are made. At the same time it would me nice to get multiprocessing support and perhaps complete the hooks for a SigComp library. 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. 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
[Sofia-sip-devel] nua: initializing SIP stack failed
Hi all, I'm running this simple code in Windows Vista:
--8--
root = su_root_create(NULL);
su_root_release(root);
if (!root) {
fprintf(stderr, Impossible to create a root thread, aborting.);
exit(1);
}
nua = nua_create(root,
event_callback, /* Callback for processing
events */
NULL, /* Additional data to pass
to callback */
NUTAG_URL(sip:stef...@*:*), /* try to bind to all the
host interfaces */
TAG_END());
--8--
And I'm getting this trace:
su_socket_port_init(00F23320, 101E62F8) called
su_pthread_port_init(00F23320, 101E62F8) called
su_socket_port_init(00F25428, 101E62F8) called
su_pthread_port_init(00F25428, 101E62F8) called
soa_create(default, 00F25D70, 00F25E80) called
soa_set_params(static::00F26400, ...) called
soa_set_params(static::00F26400, ...) called
nta_agent_create: initialized hash tables
nta_agent_create: initialized transports
nta_agent_create: initialized random identifiers
nta_agent_create: initialized timer
Adding nameserver: 10.xx.x.254
nta_agent_create: initialized resolver
tport_create(): 00F27958
nta: master transport created
tport(00F27958) to */*:*/sip
tport(00F27958): calling tport_listen for udp
tport(00F27958): new primary tport 00F28128
tport(00F27958): bind(pf=2 udp/[192.168.0.1]): No such file or directory
nta: bind(*:*;transport=*): No such file or directory
nua: initializing SIP stack failed
sres_sofia_update(00F27648, -1, -1)
sres_sofia_update(, -1, -1)
tport(00F27958)
su_wsevent_port_deinit(00F25428) called
Can you suggest what the problem may be?
The same code runs fine on Linux and on other Windows Machine (namely
Windows XP, but it may be unrelated to the OS used).
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] Is sofia-sip dead?
On date Thursday 2010-06-17 01:26:51 -0400, Michael Jerris phoned this: 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. The last darcs commit: Tue Sep 29 14:24:17 CEST 2009 Pekka Pessi first.l...@nokia.com Bug report and original patch by Timo Bruhn. and there hasn't been much activity from the maintainers in the last months and the project somehow didn't managed to get a significant community of developers/contributors. That said, there are many projects depending on sofia-sip, so I hope that there will be enough interest to keep the project alive and possibly make it better, switching to a less obscure SCCS may help. 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
[Sofia-sip-devel] su_types.h+config.h+windows compilation issues
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
[Sofia-sip-devel] Problem compiling sofia-sip 1.12.10 for MinGW
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
Re: [Sofia-sip-devel] Safe free of nua_magic_t in a multithreaded application
On date Tuesday 2010-04-27 12:38:53 +0200, Stefano Sabatini phoned this: On date Tuesday 2010-04-27 10:21:27 +0100, Dan O'Donovan phoned this: Hi Stefano Would it be possible for you to implement a reference counter in the object that your nua handle magic is pointing to? You would need to be sure to increment/decrement it in a thread-safe way of course. Then, only free the nua handle magic when your reference counter has reached 0. This would be similar to what Sofia does for the memory associated with the nua handles themselves. That was another attempt, I was using nua_magic_t to store an index containing a reference to an object from a thread-safe collection, and it seemed to work fine but for the fact that I was doing the unsafe cast void * - unsigned int. In other words I was putting an unique integer identifier in the magic of the nua_handle: nua_handle_t *handle = nua_handle(nua, (void *)an_unsigned_int, ta_tags(ta)); and extracting that index from the nua_magic when dealing with the nua handle in the sofia nua event callback. Note that the unsafe conversion problem maybe would be addressable by allowing to define NUA_HANDLE_MAGIC_T like the type of the object effectively stored in the nua handle magic, e.g.: #define NUA_HANDLE_MAGIC_T (struct hairy_weird_stuff *) or: #define NUA_HANDLE_MAGIC_T (unsigned int) rather than the type of the object *pointed to* by the magic: #define NUA_HANDLE_MAGIC_T struct hairy_weird_stuff Follow up: I fixed the problem in the application I wrote by making the sofia-sip thread destroy the handle, rather than delegating another thread to do it. 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
[Sofia-sip-devel] Safe free of nua_magic_t in a multithreaded application
Hi all, I'm facing this problem in a multithreaded application, with a thread running the sofia sip event callback (thread A), and another thread (thread B) managing the deallocation of the nua handles. The problem is that when a nua handle is destroyed by thread B, thread A may still be processing a message associated to the nua handle and the corresponding nua handle magic which is being destroyed by thread B. Currently I'm simply skipping the destruction of the nua handle magic, which results in a leak. If I destroy the nua handle magic in thread B this may result in an occasional crash when thread A tries to access the nua handle magic which is being destroyed. A possible solution would be to delay the destruction of the nua handle magic after the corresponding nua handle has been destroyed, this way I would be pretty sure that the thread A is not anymore processing messages associated to the destroyed nua handle, but as you may guess this may not work in case of slowdowns. So the problem seems that when I'm processing nua handle+magic in thread A I'm not sure if nua handle+magic still exist. I wonder if it would be possible to make nua send a final message to the nua thread *after* nua_handle has been destroyed with nua_handle_destroy() or a corresponding command. If this would be possible, then I could safely destroy the handle in thread B, and let thread A destroy the nua handle magic in thread A when this final message is received. Can you say if this would be feasible, or suggest a valid solution to the problem? TAI, regards. -- ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Safe free of nua_magic_t in a multithreaded application
On date Tuesday 2010-04-27 10:21:27 +0100, Dan O'Donovan phoned this: Hi Stefano Would it be possible for you to implement a reference counter in the object that your nua handle magic is pointing to? You would need to be sure to increment/decrement it in a thread-safe way of course. Then, only free the nua handle magic when your reference counter has reached 0. This would be similar to what Sofia does for the memory associated with the nua handles themselves. That was another attempt, I was using nua_magic_t to store an index containing a reference to an object from a thread-safe collection, and it seemed to work fine but for the fact that I was doing the unsafe cast void * - unsigned int. In other words I was putting an unique integer identifier in the magic of the nua_handle: nua_handle_t *handle = nua_handle(nua, (void *)an_unsigned_int, ta_tags(ta)); and extracting that index from the nua_magic when dealing with the nua handle in the sofia nua event callback. Note that the unsafe conversion problem maybe would be addressable by allowing to define NUA_HANDLE_MAGIC_T like the type of the object effectively stored in the nua handle magic, e.g.: #define NUA_HANDLE_MAGIC_T (struct hairy_weird_stuff *) or: #define NUA_HANDLE_MAGIC_T (unsigned int) rather than the type of the object *pointed to* by the magic: #define NUA_HANDLE_MAGIC_T struct hairy_weird_stuff Thanks for the help, regards. -- ___ 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 implement a non standard header parsing
On date Friday 2009-05-22 17:02:13 +0200, Stefano Sabatini phoned this: Hi all, I'd like to add to an application the management of a non standard header, say for example X-Fruit-Of-The-Week. In sofia-sip/libsofia-sip-ua/sip/ADD-A-HEADER there is a terse description of the procedure to follow. Problem is that it implies the creation of a separate library, and the execution of the msg_parser.awk script on it, which looks a little... overkill. Are you aware of a simpler solution? Running the awk script on a source .c.in file may be fine, but possibly I would like to avoid the need to create an autoconf/mess project just for adding an X-Fruit-Of-The-Week header management to sofia. Have anyone never tried it and/or have a working example? No need to extend the parser for just that. I discovered the SIPTAG_HEADER_STR() which is just perfect for this task: nua_invite(h, SIPTAG_HEADER_STR(X-Fruit-Of-The-Week: apple), NUTAG_MEDIA_ENABLE(1), TAG_END()); Regards. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.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] Audio streaming!!!
On date Tuesday 2009-05-12 18:52:57 +, gilles Djomo Sawa phoned this: Hello, i want to extend my Sip-phone with a audio commmunication. Can someone help me? Have look at the sofsip-cli package, it's a simple implementation using libgstreamer for the audio media (libsofia-sip only deals with *signalation*, you need a media library for dealing with the media, check for example libgstreamer or FFmpeg). Regards. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to implement a non standard header parsing
Hi all, I'd like to add to an application the management of a non standard header, say for example X-Fruit-Of-The-Week. In sofia-sip/libsofia-sip-ua/sip/ADD-A-HEADER there is a terse description of the procedure to follow. Problem is that it implies the creation of a separate library, and the execution of the msg_parser.awk script on it, which looks a little... overkill. Are you aware of a simpler solution? Running the awk script on a source .c.in file may be fine, but possibly I would like to avoid the need to create an autoconf/mess project just for adding an X-Fruit-Of-The-Week header management to sofia. Have anyone never tried it and/or have a working example? Many thanks in advance. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.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] How to get the state of a nua_handle
Hi Pekka, and thanks for replying. On date Tuesday 2009-03-03 20:35:50 +0200, Pekka Pessi phoned this: 2009/3/3 Stefano Sabatini ssabat...@reilabs.com: I was investigating about how to get the state of a nua_handle, couldn't find nothing about it. The current state is not very well defined, nor it is kept in handle. I'm having this problem in a disconnection scenario, I need to know the state of the SIP dialog when the user provides a disconnection request, this may be done both when the ACK is already arrived or when the ACK hasn't still been sent. For this reason I need to know in which state the handle is, and send a BYE or a CANCEL consistently with the current state. sofsip_cli bookeeps this information in the ssc_oper_s struct (ssc_oper.h), I also tried the i_state event management approach but it is not correct, since the i_state event (setting the state in the operation context/magic) is processed by the sofia event handler *after* the actual event which causes the state transition. So I wonder if it would make sense to set this information in the handle itself, when the various nua_invite/nua_ack/... operations are performed, rather than re-implement that logic in every app. Or maybe I'm just confused. I also wonder if it is possible for example to extract other informations related to it, for example the Call-ID of a dialog. nua_handle_make_replaces() returns a Replaces header, you can get Call-ID from it. I'll gladly accept patch for something like char *nua_handle_make_call_id(nua_handle_t *nh) Do you mean a function to *set* the call_id for example in a just created handle? But do you think would be also possible to define a function to *get* the call_id of an already created handle? nua_handle_make_replaces looks overkill for just that. [...] Kind regards. -- 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] Help!!!
On date Thursday 2009-03-05 12:34:57 +, gilles Djomo Sawa phoned this:
Hello,
i've tried to write a small code for a server registration and an
authentication. I have 2 files(*.h and *.cpp) and in these files i
have initialized my callback function. My questions are: Can be the
callback in an another file that the main function?
You can using the extern keyword for that. Example:
main.c:
// declaration
extern void callback(...);
callback.c:
// definition
void callback(...) { ... };
After that i implemented header and source files, how can i use nua
or nta to test my programm? i get also some conversion problem with
the callback function. (conversion in callback_f is not possible)!
best regards
Have a look at the sofsip_cli implementation, that's a relatively
simple application meant to show how to use libsofia-sip.
Regards.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to get the state of a nua_handle
Hi all, I was investigating about how to get the state of a nua_handle, couldn't find nothing about it. I also wonder if it is possible for example to extract other informations related to it, for example the Call-ID of a dialog. Then looking in the code (nua/nua_stack.h) I found the macro: #define NH_STATUS(nh) \ (nh)-nh_status, \ (nh)-nh_phrase, \ SIPTAG_WARNING_STR(nh-nh_warning) The nh_status is not defined in nua_handle_s, and the macro NH_STATUS looks like it is never used in the code, so maybe this is just a fossil. Regards. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Move documentation from *.c to *.h
Is it OK what in subject? I think the rationale is quite obvious, docs should be documented in the interface rather than in the implementation, also this avoids duplication. If that's OK I'll post here some patches for doing that, one header at a time. Regards. -- Stefano Sabatini http://www.reilabs.com -- 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] How to debug sofia-sip
On date Thursday 2009-01-15 19:35:44 +0200, Pekka Pessi phoned this: 2009/1/14 Stefano Sabatini ssabat...@reilabs.com: I'm trying to debug sofia-sip. I'm configuring with this command: CFLAGS=$CFLAGS -ggdb -O0 ./configure --prefix=$HOME and I can see the symbols in the output libs and the same for the lines of code (using nm -sol), yet it seems I cannot enter the sofia functions with gdb. What am I missing? Do I need some special trick when configuring in order to be able to debug sofia? Nope, I do that all the time. ;-) Are you sure that you are loading with the library you have compiled with debug options, or does your application pull in a system library, for instance? Doh, I'm stupid, I forgot to reset my LD_LIBRARY_PATH to some meaningful value, now gdb and sofia are working as good pals and I can debug sofia. Much thanks! Regards -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] How to catch a REGISTER timeout condition?
On date Monday 2009-01-12 16:19:06 +0200, Pekka Pessi phoned this: 2009/1/12 Stefano Sabatini ssabat...@reilabs.com: the attached sample catches the timeout event, which is sent non-unexpectedly as a nua_r_register event with status 408 (the application crashes with an assert when it is called nua_shutdown(), I don't know exactly when it should be called). If you really want, you can make difference between network-sent 408 and internally-generated 408 with nta_sip_is_internal(). Grepping the log I got this sequence of values for the retransmissions timer: nta: timer set next to 1000 ms nta: timer set next to 2000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 489 ms nta: timer set next to 500 ms nta: timer set next to 1000 ms nta: timer set next to 2000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 488 ms nta: timer set next to 500 ms nta: timer set next to 1000 ms nta: timer set next to 2000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms nta: timer set next to 4000 ms using sofia sip 1.12.9, while I expect the sequence: 500 1000 2000 4000 8000 16000 32000 Am I missing something or there is some bug in the stack? The timer E and maximum retransmission time should cap at SIP T2, which is 4 seconds. RFC 4321 contains everything that you really did not want to know about SIP retransmissions and why they are like they are. Also, it looks like the stack retries multiple times, which is probably because there is multiple DNS records available for your server (and it can not reach any of them). Thanks again Pekka, yes I was sending the REGISTER request to google to test it. Just another question, is there some mechanism in sofia to automatically store the expires time sent back by the REGISTER response, and re-do the registration when it is almost expiring, or do I have to do it in the application? Regards. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to debug sofia-sip
Hi again, I'm trying to debug sofia-sip. I'm configuring with this command: CFLAGS=$CFLAGS -ggdb -O0 ./configure --prefix=$HOME and I can see the symbols in the output libs and the same for the lines of code (using nm -sol), yet it seems I cannot enter the sofia functions with gdb. What am I missing? Do I need some special trick when configuring in order to be able to debug sofia? Thanks in advance, regards. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] How to catch a REGISTER timeout condition?
On date Wednesday 2009-01-14 14:16:28 +0200, Pekka Pessi phoned this: 2009/1/14 Stefano Sabatini ssabat...@reilabs.com: Just another question, is there some mechanism in sofia to automatically store the expires time sent back by the REGISTER response, and re-do the registration when it is almost expiring, or do I have to do it in the application? That is job for nua... Do you mean that this is *already* implemented or that it *should* be implemented in nua? Regards. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] How to catch a REGISTER timeout condition?
On date Thursday 2009-01-08 17:37:21 +0200, Pekka Pessi phoned this:
2009/1/8 Stefano Sabatini ssabat...@reilabs.com:
I mean that when the REGISTER recipient doesn't reply, sofia-sip sends
again and again the REGISTER. I would like to catch this condition say
after N tries and when a certain timeout expires, and notify the
sofia-sip stack of this.
Currently I see no way to say to the stack to stop to send the
REGISTER requests.
The retransmissions are done as specified in RFC 3261. NTATAG_SIP_T1()
defines the initial retransmission timer (500 ms), NTATAG_SIP_T1X64()
defines the timeout (as the name implies it is 64 times T1 or 32
seconds).
Hi Pekka and friends,
the attached sample catches the timeout event, which is sent
non-unexpectedly as a nua_r_register event with status 408 (the
application crashes with an assert when it is called nua_shutdown(), I
don't know exactly when it should be called).
As Inca Rose noted, the timeout defined by NTATAG_SIP_T1 and
NTATAG_SIP_T1X64 is defined *per user* rather than *per transaction*,
so in this case will be used that defined in the nua object.
Also as the RFC states it is duty of the agent to *retransmit* the
REGISTER request when it expires (the expiration time may be specified
in the request, otherwise it is set per registrar policy).
Maybe I'm missin something in the RFC, but the timeout specifics is
defined in the section 17.1.1., page 125, where it states:
If an unreliable transport is being
used, the client transaction MUST start timer A with a value of T1.
If a reliable transport is being used, the client transaction SHOULD
NOT start timer A (Timer A controls request retransmissions). For
any transport, the client transaction MUST start timer B with a value
of 64*T1 seconds (Timer B controls transaction timeouts).
When timer A fires, the client transaction MUST retransmit the
request by passing it to the transport layer, and MUST reset the
timer with a value of 2*T1.
[...]
If the client transaction is still in the Calling state when timer
B fires, the client transaction SHOULD inform the TU that a timeout
has occurred. The client transaction MUST NOT generate an ACK. The
value of 64*T1 is equal to the amount of time required to send seven
requests in the case of an unreliable transport.
Grepping the log I got this sequence of values for the retransmissions
timer:
nta: timer set next to 1000 ms
nta: timer set next to 2000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 489 ms
nta: timer set next to 500 ms
nta: timer set next to 1000 ms
nta: timer set next to 2000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 488 ms
nta: timer set next to 500 ms
nta: timer set next to 1000 ms
nta: timer set next to 2000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 495 ms
nta: timer set next to 500 ms
nta: timer set next to 1000 ms
nta: timer set next to 2000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 4000 ms
nta: timer set next to 496 ms
nta: timer set next to 5000 ms
using sofia sip 1.12.9, while I expect the sequence:
500
1000
2000
4000
8000
16000
32000
Am I missing something or there is some bug in the stack?
Again many thanks in advance, regards.
#include stdlib.h
#include stdio.h
#include sofia-sip/nua.h
#include sofia-sip/su_log.h
#include sofia-sip/soa.h
#include sofia-sip/nua_tag.h
#include sofia-sip/sip_header.h
/**
* Processes incoming events. This callback will be called by the SIP
* stack.
*/
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[])
{
static unsigned int count = 1;
msg_t* msg = NULL;
/* msg = nua_current_request(nua); */
printf(Event: number(%d) name(%s) status(%d) phrase(%s)\n,
count++, nua_event_name(event), status, phrase);
switch (event) {
case nua_r_register:
if (status == 408) {
printf(Timeout detected\n);
su_root_break((su_root_t *)magic
Re: [Sofia-sip-devel] How to catch a REGISTER timeout condition?
On date Wednesday 2009-01-07 19:49:38 +0200, Pekka Pessi phoned this: 2009/1/7 Stefano Sabatini ssabat...@reilabs.com: I wonder if it is actually possible to catch somehow a REGISTER timeout condition. Currently the behaviour of the sofia-sip stack seems to try the REGISTER again and again when it fails. Is it possible to set a timeout (either setting it in the nua handle either in some operation handle) or do I need to set a timeout in the application? There are plenty. What kind of error condition you have, like, you get no response, or does the response trigger a new request to be sent? Sorry, I didn't explain myself. I mean that when the REGISTER recipient doesn't reply, sofia-sip sends again and again the REGISTER. I would like to catch this condition say after N tries and when a certain timeout expires, and notify the sofia-sip stack of this. Currently I see no way to say to the stack to stop to send the REGISTER requests. Thanks, regards. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to catch a REGISTER timeout condition?
Hi all, I wonder if it is actually possible to catch somehow a REGISTER timeout condition. Currently the behaviour of the sofia-sip stack seems to try the REGISTER again and again when it fails. Is it possible to set a timeout (either setting it in the nua handle either in some operation handle) or do I need to set a timeout in the application? Also if this feature is not implemented, as I think, would be such feature acceptable in sofia? Thanks in advance, regards. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ 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 and GUI question
On date Thursday 2008-12-11 11:22:16 +0800, mingcheng hu phoned this: Hi, all I want to write a soft phone .The idea is to modify sofsip_cli(reusing the functionality in C),writing a GUI bindings for these C functions. The problem is how do I send a event from GUI to sofia event callback? In your application you may need two threads, the application thread which manages user/GUI events, and eventually executes sofia-sip/NUA operations, and the sofia-sip/NUA thread which manages SIP events and eventually executes application specific operations (e.g., ring a tone, refresh a view). Every thread manages its own events, so you don't need to send events to the other thread, you just need to perform some action (e.g. nua_invite, nua_message) and this will create some corresponding event which will be managed by the other thread (e.g. a state change, an incoming nua_r_invite 180/200 event). HTH, regards. -- Stefano Sabatini http://www.reilabs.com -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Redirecting the log of tport module
Hi all, I've been able to redirect the log of sofia-sip su module using the public symbol su_log_global and su_redirect_log(). I would like to do the same with the tport module, this in order to have the SIP messages on a unique log file, thus simplifying debugging. Unfortunately the tport module hasn't a public tport_log symbol, but a private one defined in tport/tport_logging.c so I can't redirect its log to my logging system, and I have to use instead the env variables TPORT_LOG (which enables it), TPORT_DEBUG (level of debugging), TPORT_DUMP (the name of the file). I wonder if there is some way to redirect the tport log, if that's not possible I'd like to know from the devs which way they suggest to accomplish that modifying the source, maybe simply making tport_log public should do the trick. Regards and thanks again for the cool bits. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [BUG] SIP uri params specified in the TO_TAG_STR wrongly detected as the To header params
Hi all, according to RFC 3261, 8.1.1.1 Request-URI: | The initial request URI of the message SHOULD be set to the value of | the URI in the To field. On the other hand sofia sip seems to get confused when parsing the TO_TAG, and it consider the uri params like header params. Making this clear with an example: nua_invite(op-handle, SIPTAG_FROM_STR(Alice sip:[EMAIL PROTECTED]), SIPTAG_TO_STR(sip:[EMAIL PROTECTED];foo=bar), NUTAG_MEDIA_ENABLE(0), TAG_END()); will issue the following INVITE message: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 10.88.3.67;rport;branch=z9hG4bKmKgXBK495Byyp Max-Forwards: 70 From: Alice sip:[EMAIL PROTECTED];tag=m4KHeHvHZeU8Q To: sip:[EMAIL PROTECTED];foo=bar Call-ID: 8f686cee-3254-122c-6ebf-001a4b5c8ed5 CSeq: 107512154 INVITE Contact: sip:10.88.3.67 User-Agent: sofia-sip/1.12.9 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Min-SE: 120 Content-Length: 0 foo=bar is consiedered as an *header* param, while it was specified as an *uri* param. In order to get the correct behaviour (uri params in the request line) I have to specify the sip uri in the To tag like this: SIPTAG_TO_STR(sip:[EMAIL PROTECTED];foo=bar), in which case I got: INVITE sip:[EMAIL PROTECTED];foo=bar SIP/2.0 Via: SIP/2.0/UDP 10.88.3.67;rport;branch=z9hG4bK4S4Be5m0UB9HS Max-Forwards: 70 From: Alice sip:[EMAIL PROTECTED];tag=4tjrS2F4397pp To: sip:[EMAIL PROTECTED];foo=bar Call-ID: f27c4f9b-3254-122c-0e84-001a4b5c8ed5 CSeq: 107512237 INVITE Contact: sip:10.88.3.67 User-Agent: sofia-sip/1.12.9 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Min-SE: 120 Content-Length: 0 I think this is a bug in sofia-sip. Regards. - 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] [BUG] SIP uri params specified in the TO_TAG_STR wrongly detected as the To header params
On date Friday 2008-11-21 13:55:39 +0200, [EMAIL PROTECTED] phoned this: Hi, -Original Message- From: ext Stefano Sabatini [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 12:00 PM To: sofia-sip-devel Mailing List Subject: [Sofia-sip-devel] [BUG] SIP uri params specified in the TO_TAG_STRwrongly detected as the To header params On the other hand sofia sip seems to get confused when parsing the TO_TAG, and it consider the uri params like header params. Making this clear with an example: nua_invite(op-handle, SIPTAG_FROM_STR(Alice sip:[EMAIL PROTECTED]), SIPTAG_TO_STR(sip:[EMAIL PROTECTED];foo=bar), NUTAG_MEDIA_ENABLE(0), TAG_END()); will issue the following INVITE message: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 10.88.3.67;rport;branch=z9hG4bKmKgXBK495Byyp Max-Forwards: 70 From: Alice sip:[EMAIL PROTECTED];tag=m4KHeHvHZeU8Q To: sip:[EMAIL PROTECTED];foo=bar Call-ID: 8f686cee-3254-122c-6ebf-001a4b5c8ed5 CSeq: 107512154 INVITE Contact: sip:10.88.3.67 User-Agent: sofia-sip/1.12.9 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Min-SE: 120 Content-Length: 0 foo=bar is consiedered as an *header* param, while it was specified as an *uri* param. In order to get the correct behaviour (uri params in the request line) I have to specify the sip uri in the To tag like this: SIPTAG_TO_STR(sip:[EMAIL PROTECTED];foo=bar), in which case I got: INVITE sip:[EMAIL PROTECTED];foo=bar SIP/2.0 Via: SIP/2.0/UDP 10.88.3.67;rport;branch=z9hG4bK4S4Be5m0UB9HS Max-Forwards: 70 From: Alice sip:[EMAIL PROTECTED];tag=4tjrS2F4397pp To: sip:[EMAIL PROTECTED];foo=bar Call-ID: f27c4f9b-3254-122c-0e84-001a4b5c8ed5 CSeq: 107512237 INVITE Contact: sip:10.88.3.67 User-Agent: sofia-sip/1.12.9 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Min-SE: 120 Content-Length: 0 I think this is a bug in sofia-sip. I disagree. SIPTAG_TO_STR accepts the value for the entire To: header, not just the URI. If you want more discretion, form a sip_to_t structure and pass it to SIPTAG_TO. Yes, that was the reason, as also explained by Pekka, it makes perfect sense now. Many thanks, regards. - 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] [NEWBIE] How to print a SIP message
On date Tuesday 2008-08-05 11:40:44 +0200, Stefano Sabatini phoned this:
On Mon, Aug 4, 2008 at 8:07 PM, Pekka Pessi [EMAIL PROTECTED] wrote:
2008/7/30 Stefano Sabatini [EMAIL PROTECTED]:
On 7/30/08, Stefano Sabatini [EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 10:31 AM, Stefano Sabatini
[EMAIL PROTECTED] wrote:
Hi all,
can you say if there is a simple way to convert a sip_t object to a char*
and viceversa?
For example I would like to print all the incoming SIP messages from
the the event callback function.
[...]
From a textual representation to a msg_t and to a sip_t:
msg_data = ...;
msg_t* msg = msg_make (sip_default_mclass(), 0, msg_data, sizeof
(msg_data));
if (!msg) {
fprintf(stderr, Impossible to parse message\n);
exit(1);
}
sip_t* sip = sip_object(msg);
Still I don't know if there exists a function which returns a textual
representation of a message,
there is a sip_header_as_string(home, sip) function but not one which
prints the whole message.
Try msg_as_string()..
Yes, I don't know how I missed it (mmh maybe because I was looking for
something like sip_msg_as_string in sip...).
How can I get a msg_t from a sip_t?
I can convert a msg_t - sip_t using sip_object, but how can I perform
the inverse conversion?
All I want to do is to simply print out the sip_t message received by
the event callback, so the solution looks either convert sip_t -
msg_t and use msg_as_string() either to print sip_t using some to text
conversion function, which I can't find.
Also how can I get the headers from a sip_t struct, and how can I
iterate thrugh them?
sip_t has pointers to each header fields, e.g., sip_via is pointer to
a list of Via header fields. You can iterate through Via header fields
with a loop like this:
sip_t *sip = sip_object(sip);
sip_via_t *via;
for (via = sip-sip_via; via; via = via-v_next) {
...
}
There is a supposed way to convert such header field structure to a
string?
Suppose that I want for example to convert sip-sip_from to a
corresponding string, which is the supposed way to do it (apart to
manually concat the various pieces found in that struct, which doesn't
look like the way to go)?
If you want to iterate through each header field in the message, you
should start from msg_chain_head(msg) and then proceed in order, e.g.,
for (next = msg_chain_head(msg); *next; next = (*next)-sh_next) {
sip_header_t *sh = (*next);
msg_hclass_t const *hc = sh-sh_class;
if (sip_is_via(sh) {
sip_via_t const*via = (sip_via_t *)sh;
}
...
}
The list of all the message components (chain) also includes some
non-header elements, like request-line, status-line and message body.
There is also some complications with so called list headers like
Require, their values are combined with their first occurrence, so
headers like
Require: 100rel
Supported: timer
Require: xyzzy
will have one sip_require_t structure with tokens 100rel and
xyzzy, one sip_supported_t structure with timer and a dummy
sip_require_t structure in the chain.
Thanks so much for the detailed answer!
Thanks again, regards.
-
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] [NEWBIE] How to print a SIP message
On date Thursday 2008-11-20 10:49:21 +0100, Stefano Sabatini phoned this:
On date Tuesday 2008-08-05 11:40:44 +0200, Stefano Sabatini phoned this:
On Mon, Aug 4, 2008 at 8:07 PM, Pekka Pessi [EMAIL PROTECTED] wrote:
[...]
How can I get a msg_t from a sip_t?
I can convert a msg_t - sip_t using sip_object, but how can I perform
the inverse conversion?
All I want to do is to simply print out the sip_t message received by
the event callback, so the solution looks either convert sip_t -
msg_t and use msg_as_string() either to print sip_t using some to text
conversion function, which I can't find.
Also how can I get the headers from a sip_t struct, and how can I
iterate thrugh them?
sip_t has pointers to each header fields, e.g., sip_via is pointer to
a list of Via header fields. You can iterate through Via header fields
with a loop like this:
sip_t *sip = sip_object(sip);
sip_via_t *via;
for (via = sip-sip_via; via; via = via-v_next) {
...
}
There is a supposed way to convert such header field structure to a
string?
Auto replying to myself: the sip_header_as_string() is the supposed
way to perform such conversion.
Suppose that I want for example to convert sip-sip_from to a
corresponding string, which is the supposed way to do it (apart to
manually concat the various pieces found in that struct, which doesn't
look like the way to go)?
char* sip_from_str = sip_header_as_string(home, (const
sip_header_t*)sip-sip_from);
[...]
Still missing the answer to the first question.
Regards.
-
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] [NEWBIE] How to print a SIP message
On date Thursday 2008-11-20 10:49:21 +0100, Stefano Sabatini phoned this:
[...]
How can I get a msg_t from a sip_t?
I can convert a msg_t - sip_t using sip_object, but how can I perform
the inverse conversion?
Again auto-replying to myself...
Contemplating the sip module doc picture I finally got for the first
time a complete understanding of the msg_t struct.
I don't know if there is function for such a conversion, anyway it
shouldn't too hard to define a function to create a msg_t struct and
fill the fields in order to create (maybe even refactorizing some code
from msg_as_string()).
As suggested by Pessa in a previous mail, for example it should be
possible to iterate through the headers contained in sip_t, print a
representation of them (e.g. using sip_header_as_string()) and fill a
buffer which will be equivalent to the original buffer.
All I want to do is to simply print out the sip_t message received by
the event callback, so the solution looks either convert sip_t -
msg_t and use msg_as_string() either to print sip_t using some to text
conversion function, which I can't find.
Even without to access the sip_t struct there is a solution using the
nua_current_request() function. Sofia-sip somehow stores the current
message processed (the name is misleading, since it also stores
response messages), the following snippet may be executed for example
at the beginning of the event callback:
/* print the incoming message */
int msg_size = 0;
msg_t* msg = nua_current_request(nua);
if (msg) {
char * msg_str = msg_as_string(home, msg, NULL, 0, msg_size);
printf (SIP message:\n
%s\n, msg_str);
}
Regards.
-
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] Problem compiling a little application with visual studio 2005
On date Monday 2008-09-22 14:53:16 +0530, Subbu Rajendran phoned this: I also faced a similar issue. I tried to compile the sofia sip code to create the library and then link the generated lib to my application. I got these errors when trying to compile the sofia sip code. I am not able to completely re-collect how I fixed this, but give this a try. Hope this helps you. 1. In order to compile the code with Windows 2000 SDK you have to install so called IPv6 Technology Preview for Windows 2000. The preview contains updated IPv6 API in tpipv6.h and wspiapi.h header files. http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp I used visual studio .net 2003. 2. Open the .\sofia-sip\win32\SofiaSIP.dsw to open the complete list of projects. This includes sofia sip library project (DLLs static libraries) and few test programs. 3. The following paths to be added to the list of include directories .\libsofia-sip-ua\bnf .\libsofia-sip-ua\http .\libsofia-sip-ua\ipt .\libsofia-sip-ua\iptsec .\libsofia-sip-ua\msg .\libsofia-sip-ua\nea .\libsofia-sip-ua\nta .\libsofia-sip-ua\nth .\libsofia-sip-ua\nua .\libsofia-sip-ua\sdp .\libsofia-sip-ua\sip .\libsofia-sip-ua\soa .\libsofia-sip-ua\sresolv .\libsofia-sip-ua\stun .\libsofia-sip-ua\su .\libsofia-sip-ua\tport .\libsofia-sip-ua\url .\win32\pthread 4. Add libraries ws2_32.lib Iphlpapi.lib to the dependency list [...] From: Francesco Lamonica [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 2:05 PM To: sofia-sip-devel Mailing List Subject: Re: [Sofia-sip-devel] Problem compiling a little application with visual studio 2005 Hi Stefano, I am no VS2005 expert either but i had a few problems on lib dependencies as well, what windows lib are you linking against right now? (you can check it in the project properties under the LINKER section) [...] Hi guys, the problem was in the compilation of sip_options_static, we had had to add the dependency on ws232_32.lib and Ipphlpapi.lib and Advapi32.lib (settable through the linker options), the library were already installed on the system. After setting those dependencies, the project finally compiled!! Hurra! Thanks so much for your time and help Subbu, Francesco and Mike. Regards. -- Stefano Sabatini http://www.reilabs.com - 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] Using SOFIA-SIP just as a parser
On date Wednesday 2008-09-24 15:46:21 +0200, elisa_murgia phoned this: -- Initial Header --- From : elisa_murgia [EMAIL PROTECTED] To : sofia-sip-devel sofia-sip-devel@lists.sourceforge.net Cc : Date : Wed, 24 Sep 2008 12:31:47 +0200 Subject : Re: [Sofia-sip-devel] Using SOFIA-SIP just as a parser Another thing I noticed: I've made a test putting an incomplete sip-message inside a string and then msg_t* msg=msg_make(...) int i=msg_extract(msg); Now msg_extract returns always 1, as it was complete. I'd expected a 0. More: making sip_t sip=sip_object(msg); with some full fields and others empty. How is it possible?? From sofia-sip documentation: |msg_t* msg_make(msg_mclass_t const *mc, | intflags, | void const *data, | ssize_tlen) | |Parse a text message with parser mc. The data is copied and it is not modified or referenced by the parsed message. [...] |Return values: | A pointer to a freshly allocated and parsed message. | |Upon parsing error, the header structure may be left incomplete. The |MSG_FLG_ERROR is set in msg_object(msg)-msg_flags. So you have to check that flag to understand if the parsing went fine. Behaviour of msg_extract() with an incomplete msg_t is undefined, at least I think so. [...] Regards. -- Stefano Sabatini http://www.reilabs.com - 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] Initialize sofia in the main context thread and run it in another thread
On date Friday 2008-09-12 18:50:45 +0300, Pekka Pessi phoned this: 2008/9/9 Stefano Sabatini [EMAIL PROTECTED]: So it seems that the only solution is to initialize and run the stack in the same thread context. Is this correct or am I missing something? Call su_root_release() on the thread creating the root and stack and then su_root_obtain() in the thread running it. Thank you Pekka, yes it works fine (but I still feel the need for a tutorial on sofia-sip threading/tasks/clones management...:-(). Regards. - 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
[Sofia-sip-devel] Problem compiling a little application with visual studio 2005
Hi all, I'm getting this building problems when compiling a little application with Visual Studio 2005 on Windows Vista which links against libsofia-sip (last checkout, 1.12.9). I got so far to compile libsofia-ua for win32 without hassles. These are the errors I get when compiling: 1Linking... 1 Creating library .\Debug/sip_options_static.lib and object .\Debug/sip_options_static.exp 1libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_ip 1libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_reg 1libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_reg 1libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_reg_parse_dnsserver 1libsofia_sip_ua_static.lib(su_localinfo.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _win_localinfo 1.\Debug/sip_options_static.exe : fatal error LNK1120: 5 unresolved externals 1Build log was saved at file://c:\Users\fooobar\Documents\programmi\sofia-sip-1.12.9\win32\utils\sip_options_static\Debug\BuildLog.htm 1sip_options_static - 6 error(s), 0 warning(s) I think the problem derives from some missing libs/DLLs, can you suggest how to fix the problem (for example which are the libs/DLLs I'm missing if that's the case)? (Sorry I'm definitively not a Visual Studio expert). Many thanks in advance, best regards. - 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] Initialize sofia in the main context thread and run it in another thread
On date Friday 2008-09-12 10:57:00 +0300, [EMAIL PROTECTED] phoned this: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Rémi BUISSON Sent: Friday, September 12, 2008 9:32 AM To: sofia-sip-devel@lists.sourceforge.net Subject: Re: [Sofia-sip-devel] Initialize sofia in the main context thread and run it in another thread DBus works on windows and you can attach both DBus loop and sofia-sip loop to a GMainLoop (glib works on windows to). An example is Telepathy-SofiaSIP: http://telepathy.freedesktop.org/wiki/Components We disable threading in Sofia-SIP, and it works wonderfully in the common main loop alongside DBus-Glib. Yes but consider for example a gateway, when you don't want the sofia sip loop running in the main process thread, but in a new thread as the threads which manage the other protocols but SIP. Ideally the main thread should only init the various protocol handlers and make their event loops start, each one in a separate thread. Regards. - 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] Running the sofia-sip event loop in a thread context
On date Monday 2008-09-08 11:36:29 +0200, Stefano Sabatini phoned this: On date Monday 2008-09-08 10:31:43 +0200, Stefano Sabatini wrote: On date Monday 2008-09-08 10:08:39 +0200, Stefano Sabatini wrote: On date Friday 2008-09-05 12:10:10 +0200, Stefano Sabatini wrote: On 9/5/08, Stefano Sabatini [EMAIL PROTECTED] wrote: Hi all, I have a multithreaded application, and I need to run the sofia-sip event loop not in the main process context, but in the context of a thread. [...] Well this time I checked the Gmane archive and I found this: http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/2534/focus=2536 Quoting Pekka from it: |You can use threads w/ Sofia in two alternative ways: | |1/ You create thread by your self, and call su_root_create() by |yourself. Then call su_root_run()/su_root_step() to process su_root_t |stuff. When you want to exit from thread, you should call |su_root_break() (if su_root_run()ing) and then su_root_destroy(). | |2/ You call su_clone_start() and get su_clone_t reference. A new |thread is created. When you'd want to get rid of that thread, you call |su_clone_wait() from the main thread. I can't opt for solution 1, since I need to create the root in the main thread, then run it with a Run() command. For the solution 2: when su_clone_start() is invoked, the init function defined is executed and the main thread waits for its termination, then how can I specify which function should execute the new thread? Regards. -- Stefano Sabatini http://www.reilabs.com - 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
[Sofia-sip-devel] Running the sofia-sip event loop in a thread context
Hi all, I have a multithreaded application, and I need to run the sofia-sip event loop not in the main process context, but in the context of a thread. I implemented it this way. I implemented a method Run() which instantiates the thread instance and makes it execute su_root_run(), and a Stop() method which executes su_root_break() and wait for the thread termination. Unfortunately this apporach seems not to work, as I get this message from the sofia stack: nua(0x8729740): signal r_invite SIPEngineTest: su_base_port.c:322: su_base_port_run: Assertion `su_port_own_thread(self)' failed. and the process gets terminated by the SIGABRT signal. I'm currently stuck with it, can someone help/provide some hint? Many thanks in advance. - 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] How to free a sdp_session_t struct
On Tue, Sep 2, 2008 at 11:21 AM, [EMAIL PROTECTED] wrote: Hi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Stefano Sabatini Sent: Monday, September 01, 2008 6:56 PM To: sofia-sip-devel@lists.sourceforge.net Subject: Re: [Sofia-sip-devel] How to free a sdp_session_t struct So if I understood it correctly I need to keep an home just for every sdp_session_t. Well, you can use one home for multiple objects. Well, indeed I have an home defined in the main application context. When the application home is cleaned at the deinitialization of the application, then the home is freed, the problem is that when the execution is running I'd continue to keep allocating sdp sessions in it without to be able to free them. For a server application meant to stay alive this could end up in a memory exhaustion problem. Regards. - 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] How to free a sdp_session_t struct
On Fri, Aug 29, 2008 at 5:27 PM, [EMAIL PROTECTED] wrote: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Stefano Sabatini Sent: Friday, August 29, 2008 6:24 PM To: sofia-sip-devel@lists.sourceforge.net Subject: [Sofia-sip-devel] How to free a sdp_session_t struct Hi all sofia-sippers, I'm looking for the best method to free an sdp_session_t struct. I see there is an sdp_session_dup() function, and there are sdp_printer_free() and sdp_parser_free(), so I was expecting some method such as sdp_session_free(). Missing that, then I wonder if its absence means something, for example that there is some convenient method to free an sdp_session_t. Can you give some hint? Free the home used for allocating the session. Hi, and thanks for the reply. Yes that's a solution, nonetheless it looks still weird to me, to have to use an home just for that seems overkill. Also, I wonder which is the supposed way to fill an SDP from scratch. I can't see any specific function for doing that (e.g. add a connection, add a media etc.) and doing it manually is tedious. So I suppose that the supposed way to create an SDP from scratch is to write it down in its textual form *then* convert it using an sdp_parser_t, otherwise maybe I have to use some higher level function not provided in the sdp module (soa?). Am I right? Regards. - 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] How to free a sdp_session_t struct
On Mon, Sep 1, 2008 at 9:24 AM, Stefano Sabatini [EMAIL PROTECTED] wrote: On Fri, Aug 29, 2008 at 5:27 PM, [EMAIL PROTECTED] wrote: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Stefano Sabatini Sent: Friday, August 29, 2008 6:24 PM To: sofia-sip-devel@lists.sourceforge.net Subject: [Sofia-sip-devel] How to free a sdp_session_t struct Hi all sofia-sippers, I'm looking for the best method to free an sdp_session_t struct. I see there is an sdp_session_dup() function, and there are sdp_printer_free() and sdp_parser_free(), so I was expecting some method such as sdp_session_free(). Missing that, then I wonder if its absence means something, for example that there is some convenient method to free an sdp_session_t. Can you give some hint? Free the home used for allocating the session. Hi, and thanks for the reply. Yes that's a solution, nonetheless it looks still weird to me, to have to use an home just for that seems overkill. There is also this problem. Assuming that I have to pass around the allocated home, I can't use a stack allocated home, so I have to use su_home_new() (here choosing an arbitrary size value...). Then I think there is no way to know the home used by an sdp_session_t object, so I would have to pass around the home object to which the sdp_session_t is bound, which is pretty awkward, *either* to have a memleak. [...] Regards. - 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] How to free a sdp_session_t struct
On 9/1/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Stefano Sabatini Sent: Monday, September 01, 2008 3:44 PM To: sofia-sip-devel@lists.sourceforge.net Subject: Re: [Sofia-sip-devel] How to free a sdp_session_t struct Free the home used for allocating the session. Hi, and thanks for the reply. Yes that's a solution, nonetheless it looks still weird to me, to have to use an home just for that seems overkill. There is also this problem. Assuming that I have to pass around the allocated home, I can't use a stack allocated home, so I have to use su_home_new() (here choosing an arbitrary size value...). Then I think there is no way to know the home used by an sdp_session_t object, so I would have to pass around the home object to which the sdp_session_t is bound, which is pretty awkward, *either* to have a memleak. Another solution could be to pass around sdp_parser_t rather than sdp_session_t, then use sdp_session() to get the sdp_session_t from the parser and free both parser and session with sdp_parser_free(), do you think this is an acceptable solution? But still this looks like a strange solution and not particularly convenient (why to pass around the whole parser if what I need is just the session?), and is the reason for which I was looking for an sdp_session_free() function. I guess you don't really want to keep the parser state. A home is a pool for allocated memory in the Sofia stack, so yes, you need to pass it around to wherever you free the sdp_session_t. Thanks for the reply Mikhail. So if I understood it correctly I need to keep an home just for every sdp_session_t. So my next obvious question is: it would be possible to change the API and implement an sdp_session_free() function? The sdp_session_t could inherit the home of the sdp_parser which creates it, or if created from scratch (sdp_session_create(home)?) it would require an home as argument. Not sure if this is possible to do without to break backward compatibility. And still I have the sensation I'm doing something very strange with my code, if no one ever had felt the necessity for a such facility (I'm using the sdp_session_t to store an SDP in a C-language-friendly manner)... Kind regards. - 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
[Sofia-sip-devel] How to free a sdp_session_t struct
Hi all sofia-sippers, I'm looking for the best method to free an sdp_session_t struct. I see there is an sdp_session_dup() function, and there are sdp_printer_free() and sdp_parser_free(), so I was expecting some method such as sdp_session_free(). Missing that, then I wonder if its absence means something, for example that there is some convenient method to free an sdp_session_t. Can you give some hint? Thanks in advance, regards. - 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
[Sofia-sip-devel] Missing the nua_callstate_proceeding - nua_callstate_completing state transition
Hi all, now I'm facing this other problem. I'm thinking about the better place where to activate the media. I thought that a good idea could be to activate the media just after I receive the answer to the SDP offer, at this point I have all the information required to activate the receiving and transmitting media elements, information which is stored in the local and remote SDPs. So when I receive the SDP response I expect the nua callstate to transition from: proceeding - completing What I experience instead is this: nta: received 200 OK for INVITE (102932847) nta: 200 OK is going to a transaction tport_release(0x804eb58): 0x8052710 by 0x8053360 with 0x8054d20 nta: timer set to 32000 ms nua(): refresh session after 901 seconds (in [895..905]) nua(): refresh session after 901 seconds soa_set_remote_sdp(static::0x80514c0, (nil), 0x8055626, 156) called soa_process_answer(static::0x80514c0) called soa_static_offer_answer_action(0x80514c0, soa_process_answer): called soa_sdp_mode_set(0x8052f88, 0x8055ae8, ): called soa_static(0x80514c0, soa_process_answer): upgrade codecs with remote description soa_static(0x80514c0, soa_process_answer): storing local description soa_activate(static::0x80514c0, (nil)) called nua(0x8051180): INVITE: processed SDP answer in 200 OK ^^ Missing proceeding - completing transition?? soa_activate(static::0x80514c0, (nil)) called nta: selecting scheme sip tport_tsend(0x804eb58) tpn = */10.xx.x.204:5060 tport_resolve addrinfo = 10.xx.x.204:5060 tport_by_addrinfo(0x804eb58): not found by name */10.xx.x.204:5060 tport_vsend returned 302 nta: sent ACK (102932847) to */10.xx.x.204:5060 nua(0x8051180): call state changed: proceeding - ready, received answer ^ Here it passes from the proceeding to the ready state. soa_get_remote_sdp(static::0x80514c0, [0xb7a11c30], [0xb7a11c2c], [(nil)]) called soa_get_params(static::0x80514c0, ...) called nua: nua_application_event: entering [...] Because of this the switch case block for nua_callstate_completing in my *_i_state event handler isn't executed. I wonder, am I missing something obvious or is it a bug (BTW I'm using libsofia-sip darcs head)? Thanks again for your patience, best regards. - 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] Missing the nua_callstate_proceeding - nua_callstate_completing state transition
On Thu, Aug 7, 2008 at 12:09 PM, Stefano Sabatini [EMAIL PROTECTED] wrote: Hi all, now I'm facing this other problem. I'm thinking about the better place where to activate the media. I thought that a good idea could be to activate the media just after I receive the answer to the SDP offer, at this point I have all the information required to activate the receiving and transmitting media elements, information which is stored in the local and remote SDPs. So when I receive the SDP response I expect the nua callstate to transition from: proceeding - completing What I experience instead is this: nta: received 200 OK for INVITE (102932847) nta: 200 OK is going to a transaction tport_release(0x804eb58): 0x8052710 by 0x8053360 with 0x8054d20 nta: timer set to 32000 ms nua(): refresh session after 901 seconds (in [895..905]) nua(): refresh session after 901 seconds soa_set_remote_sdp(static::0x80514c0, (nil), 0x8055626, 156) called soa_process_answer(static::0x80514c0) called soa_static_offer_answer_action(0x80514c0, soa_process_answer): called soa_sdp_mode_set(0x8052f88, 0x8055ae8, ): called soa_static(0x80514c0, soa_process_answer): upgrade codecs with remote description soa_static(0x80514c0, soa_process_answer): storing local description soa_activate(static::0x80514c0, (nil)) called nua(0x8051180): INVITE: processed SDP answer in 200 OK ^^ Missing proceeding - completing transition?? soa_activate(static::0x80514c0, (nil)) called nta: selecting scheme sip tport_tsend(0x804eb58) tpn = */10.xx.x.204:5060 tport_resolve addrinfo = 10.xx.x.204:5060 tport_by_addrinfo(0x804eb58): not found by name */10.xx.x.204:5060 tport_vsend returned 302 nta: sent ACK (102932847) to */10.xx.x.204:5060 nua(0x8051180): call state changed: proceeding - ready, received answer ^ Here it passes from the proceeding to the ready state. soa_get_remote_sdp(static::0x80514c0, [0xb7a11c30], [0xb7a11c2c], [(nil)]) called soa_get_params(static::0x80514c0, ...) called nua: nua_application_event: entering [...] Because of this the switch case block for nua_callstate_completing in my *_i_state event handler isn't executed. I wonder, am I missing something obvious or is it a bug (BTW I'm using libsofia-sip darcs head)? I missed this bit of information from the docs: Unless the auto-ack mode is explicitly turned off by application the client does not stay in completing state, but proceeds immediately to next state transition. So that's the expected behaviour since I didn't turned off the auto-ack mode. Regards. - 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] [NEWBIE] How to print a SIP message
On Mon, Aug 4, 2008 at 8:07 PM, Pekka Pessi [EMAIL PROTECTED] wrote:
2008/7/30 Stefano Sabatini [EMAIL PROTECTED]:
On 7/30/08, Stefano Sabatini [EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 10:31 AM, Stefano Sabatini
[EMAIL PROTECTED] wrote:
Hi all,
can you say if there is a simple way to convert a sip_t object to a char*
and viceversa?
For example I would like to print all the incoming SIP messages from
the the event callback function.
[...]
From a textual representation to a msg_t and to a sip_t:
msg_data = ...;
msg_t* msg = msg_make (sip_default_mclass(), 0, msg_data, sizeof (msg_data));
if (!msg) {
fprintf(stderr, Impossible to parse message\n);
exit(1);
}
sip_t* sip = sip_object(msg);
Still I don't know if there exists a function which returns a textual
representation of a message,
there is a sip_header_as_string(home, sip) function but not one which
prints the whole message.
Try msg_as_string()..
Yes, I don't know how I missed it (mmh maybe because I was looking for
something like sip_msg_as_string in sip...).
Also how can I get the headers from a sip_t struct, and how can I
iterate thrugh them?
sip_t has pointers to each header fields, e.g., sip_via is pointer to
a list of Via header fields. You can iterate through Via header fields
with a loop like this:
sip_t *sip = sip_object(sip);
sip_via_t *via;
for (via = sip-sip_via; via; via = via-v_next) {
...
}
If you want to iterate through each header field in the message, you
should start from msg_chain_head(msg) and then proceed in order, e.g.,
for (next = msg_chain_head(msg); *next; next = (*next)-sh_next) {
sip_header_t *sh = (*next);
msg_hclass_t const *hc = sh-sh_class;
if (sip_is_via(sh) {
sip_via_t const*via = (sip_via_t *)sh;
}
...
}
The list of all the message components (chain) also includes some
non-header elements, like request-line, status-line and message body.
There is also some complications with so called list headers like
Require, their values are combined with their first occurrence, so
headers like
Require: 100rel
Supported: timer
Require: xyzzy
will have one sip_require_t structure with tokens 100rel and
xyzzy, one sip_supported_t structure with timer and a dummy
sip_require_t structure in the chain.
Thanks so much for the detailed answer!
Regards.
-
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] sofsip_cli : how is activated the sending of RTP packets?
On Fri, Aug 1, 2008 at 4:05 PM, Michael Jerris [EMAIL PROTECTED] wrote:
Look at the i_state callback.
Hi,
that was only the first step, what I couldn't understand was all the GST part.
After diving into the libgstreamer metaphysics:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html
I'm finally starting to figure out the big scheme of things.
I'm reporting it (a probably partly wrong) description of it, both for
the archive and for fostering comments.
ssc_media_activate() in ssc_media.c is called by the ssc_invite()
method, and this call the activate method of the media subsystem
object.
Looking at the gst media subsystem as defined in ssc_media_gst.[hc],
the activate method corresponds to the priv_activate_gst callback().
What it does is to fill the information relative to the local and
remote SDP, then it calls priv_setup_rtpelements().
This function bind the application to the local UDP port for receiving
(farsight_netsocket_bind_udp_port()), create the netsocket object and
register on it the
signal handler priv_cb_ready, which is called when a ready signal
is delivered to the netsocket object:
g_signal_connect (G_OBJECT (netsocket), ready,
G_CALLBACK (priv_cb_ready), self)
For what regards the priv_cb_ready, this creates multimedia pipeline
which works like this:
RX: udp_source - rtp_depayloader - decoder - audio_sink
TX: alsa_source - encoder - rtp_payloader - udp_sink
calls the callback functions:
priv_update_rx_elements(self);
priv_update_tx_elements(self);
and finally sets the state of the pipeline to GST_STATE_PLAYING.
The priv_update_?x_elements() functions take the SDP from the context
and set it in the media elements, in the case of
priv_update_tx_elements if the SDP isn't set
(as when the first invite is sent, we need to await for the response
SDP before to be able to send media), I think the transmitting
elements stay inactive.
Finally when the respone to the invite arrives, ssc_sip.c:ssc_i_state
will call the set methods on the media subsystem object:
if (l_sdp) {
g_return_if_fail(answer_sent || offer_sent);
g_object_set(G_OBJECT(ssc-ssc_media), localsdp, l_sdp, NULL);
/* printf(%s: local SDP updated:\n%s\n\n, ssc-ssc_name, l_sdp); */
}
if (r_sdp) {
g_return_if_fail(answer_recv || offer_recv);
g_object_set(G_OBJECT(ssc-ssc_media), remotesdp, r_sdp, NULL);
/* printf(%s: remote SDP updated:\n%s\n\n, ssc-ssc_name, r_sdp); */
}
ssc_media.c:ssc_media_set_property () is called, which call
ssc_media_refresh(self);
In the case of ssc_media_gst() such method corresponds to the priv_refresh_gst:
static int priv_refresh_gst(SscMedia *parent)
{
SscMediaGst *self = SSC_MEDIA_GST (parent);
int res = 0;
/* XXX: no RX hot updates supported yet */
priv_update_tx_elements(self);
return res;
}
which simply update the transmitting elements, setting the target RTP
destination and likely actually activating the trasmitting elements.
Regards.
-
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] Correct parameter for nua_invite()
On Fri, Aug 1, 2008 at 10:55 AM, Stefano Sabatini [EMAIL PROTECTED] wrote:
On date Monday 2008-07-28 08:15:48 +, Fan Xing wrote:
I wrote a simple test code using sofia_sip to make a voip
call. However, when I execute the code, it is hang there ' entering
main loop for processing of messages'.
First suggestion: use
su_log_set_level(NULL, 9);
to increase verbosity of sofia-sip, that's bloody helpful.
I suspect I made some some mistakes when using the nua_invite function. In
my makecall() function, I called nua_invite like this:
int makecall(char const *name, char const *url)
{
//create operation context, operation handle, etc..
nua_invite(op, NUTAG_URL (url), SOATAG_ADDRESS('0.0.0.0:8000'),
NUTAG_EARLY_MEDIA (1), TAG_END ());
}
I think the problem here is that you didn't specify any SDP
capabilities, try for example with:
nua_invite(op,
SOATAG_USER_SDP_STR(m=audio 5004 RTP/AVP 0 8),
NUTAG_URL(to_url),Thanks a lot, ssabatini:-) You are right, when
I add SOATAG_USER_SDP_STR in the input parameter, it works.
I'm replying here to a mail sent privately by Fan to me:
Thanks a lot, ssabatini:-) You are right, when I add SOATAG_USER_SDP_STR in
the input parameter, it works.
But, there is one problem. The caller can not receive the sound from the
callee (the configuration on the machine is correct, for example, if I run
sofsip_cli, it works). Is it because I did not put the correct value for the
SOATAG_USER_SDP_STR? I use Ubuntu.
sofia-sip doesn't manage the media *at all*, you have to provide a
media subsystem to your own application as sofsip_cli does using
libgstreamer to provide the media framework.
I suggest you to study the code of sofsip_cli and look at how the
problem is addressed there, then eventually post here questions if you
need some help.
Regards.
-
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
[Sofia-sip-devel] [PATCH] sofsip-cli: fix some typos in src/sdp_utils.c
Hi, as in subject, regards. --- old-sofsip-cli/src/sdp_utils.c 2008-07-31 15:10:46.0 +0200 +++ new-sofsip-cli/src/sdp_utils.c 2008-07-31 15:10:46.0 +0200 @@ -21,10 +21,9 @@ * */ -/[EMAIL PROTECTED] sdpg_utils.c +/[EMAIL PROTECTED] sdp_utils.c * - * Utilizies for glib/gstreamer applications handling - * for handling SDP. + * Utilities for glib/gstreamer applications for handling SDP. * * @author Kai Vehmanen [EMAIL PROTECTED] */ - 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
[Sofia-sip-devel] [NEWBIE] How to print a SIP message
Hi all, can you say if there is a simple way to convert a sip_t object to a char* and viceversa? For example I would like to print all the incoming SIP messages from the the event callback function. (Well, I'm diving just now into docs/code, nonetheless a little help would make life a little easier.) Many thanks in advance, regards. - 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] [NEWBIE] How to print a SIP message
On Wed, Jul 30, 2008 at 10:31 AM, Stefano Sabatini [EMAIL PROTECTED] wrote: Hi all, can you say if there is a simple way to convert a sip_t object to a char* and viceversa? For example I would like to print all the incoming SIP messages from the the event callback function. (Well, I'm diving just now into docs/code, nonetheless a little help would make life a little easier.) Many thanks in advance, regards. Sorry to ping, I'm not sure if this message did arrive the first time (I'm managing problems with Sourceforge ML lately, seems I cannot send mails using my provider SMTP server, and so painfullly falling back to the Gmail web interface). As I'm exploring the problem I discovered the test program sip/test_sip_msg.c, but nothing similar to a converter msg_t/sip_t - char*, so I'm still stuck with this problem. Regards. - 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] [NEWBIE] How to print a SIP message
On 7/30/08, Stefano Sabatini [EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 10:31 AM, Stefano Sabatini
[EMAIL PROTECTED] wrote:
Hi all,
can you say if there is a simple way to convert a sip_t object to a char*
and viceversa?
For example I would like to print all the incoming SIP messages from
the the event callback function.
[...]
From a textual representation to a msg_t and to a sip_t:
msg_data = ...;
msg_t* msg = msg_make (sip_default_mclass(), 0, msg_data, sizeof (msg_data));
if (!msg) {
fprintf(stderr, Impossible to parse message\n);
exit(1);
}
sip_t* sip = sip_object(msg);
Still I don't know if there exists a function which returns a textual
representation of a message,
there is a sip_header_as_string(home, sip) function but not one which
prints the whole message.
Also how can I get the headers from a sip_t struct, and how can I
iterate thrugh them?
Thanks in advance, regards.
-
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
[Sofia-sip-devel] What's the name of a soa_session_t?
Hi, a soa_session_t is created using the soa_create() function. Documentation says: soa_session_t* soa_create ( char const * name, su_root_t * root, soa_magic_t * magic ) Create a soa session. Then according to the name you assign to it may fail to create the object. Do you have an explanation for the meaning of the name param? Many thanks in advance, as always. - 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
[Sofia-sip-devel] [PATCH] Fix misc typos in src/ssc_sip.c
Hi all,
as in subject.
Regards.
--- old-sofsip-cli/src/ssc_sip.c 2008-07-04 09:29:49.0 +0200
+++ new-sofsip-cli/src/ssc_sip.c 2008-07-04 09:29:49.0 +0200
@@ -700,7 +700,7 @@
/**
* Sends an outgoing INVITE request.
*
- * @param cli context pointer
+ * @param ssc context pointer
* @param destination SIP URI
*/
void ssc_invite(ssc_t *ssc, const char *destination)
@@ -848,7 +848,7 @@
state == sm_active) {
/* SDP O/A case 1: outgoing invite
- * - get a an description of the network addresses
+ * - get a description of the network addresses
*and available media and codecs
* - pass this information to nua_invite() in the
*SOATAG_USER_SDP_STR() tag
@@ -1619,7 +1619,7 @@
ssc_oper_t *op;
if (!registrar (op = ssc_oper_find_by_method(ssc, sip_method_register))) {
-printf(%s: REGISTER %s - updating existing registrationk\n, ssc-ssc_name, op-op_ident);
+printf(%s: REGISTER %s - updating existing registration\n, ssc-ssc_name, op-op_ident);
nua_register(op-op_handle, TAG_NULL());
return;
}
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [BUGREPORT] sofsip-cli: invite, zap, new invites are never sent
Hi all, to reproduce this issue simply send an invite, zap it, then send another invite: you get the message: UA: INVITE to sip:[EMAIL PROTECTED] pending but then no invite message is sent (as you can verify with wireshark for example). If the operation is terminated with a bye, new invites go just fine, unfortunately I couldn't get to understand what's going wrong as long as my grasp of the libgobject thing is rather shallow. BTW, if you prefer I can use the sourceforge tracking system for both patches and bugreports. Regards. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [PATCH] sofsip_cli: Implement ssc_i_options event callback
Hi, this implement a basic callback to manage incoming options events.
Please note that maybe this isn't the correct approach, indeed with
this approach sofsip_cli always returns 200 OK, while RFC 3261 states:
|The response to an OPTIONS is constructed using the standard rules for
|a SIP response as discussed in Section 8.2.6. The response code
|chosen MUST be the same that would have been chosen had the request
|been an INVITE. That is, a 200 (OK) would be returned if the UAS is
|ready to accept a call, a 486 (Busy Here) would be returned if the UAS
|is busy, etc. This allows an OPTIONS request to be used to determine
|the basic state of a UAS, which can be an indication of whether the
|UAS will accept an INVITE request.
Can you suggest how can I access the global state of the application
(for example: ready, busy, etc.)?
BTW, I noted that even when the incoming options event is not managed,
I got this message from the receiving application:
sofsip UA: unknown event 'nua_i_options' (10): 200 OK
::tag_null: 0
then a response message is currently sent. How can I override this
mechanism, for example how can I control which kind of response
message to send? (For example in the abovementioned case, when I want
to send a message telling the application is busy.)
Thanks in advance for any advice, regards.
--- old-sofsip-cli/src/ssc_sip.c 2008-07-04 14:20:10.0 +0200
+++ new-sofsip-cli/src/ssc_sip.c 2008-07-04 14:20:10.0 +0200
@@ -145,6 +145,9 @@
void ssc_r_notify(int status, char const *phrase, nua_t *nua, ssc_t *ssc,
nua_handle_t *nh, ssc_oper_t *op, sip_t const *sip,
tagi_t tags[]);
+void ssc_i_options(int status, char const *phrase, nua_t *nua, ssc_t *ssc,
+ nua_handle_t *nh, ssc_oper_t *op, sip_t const *sip,
+ tagi_t tags[]);
void ssc_r_options(int status, char const *phrase, nua_t *nua, ssc_t *ssc,
nua_handle_t *nh, ssc_oper_t *op, sip_t const *sip,
tagi_t tags[]);
@@ -466,6 +469,10 @@
ssc_r_unregister(status, phrase, nua, ssc, nh, op, sip, tags);
break;
+ case nua_i_options:
+ssc_i_options(status, phrase, nua, ssc, nh, op, sip, tags);
+break;
+
case nua_r_options:
ssc_r_options(status, phrase, nua, ssc, nh, op, sip, tags);
break;
@@ -1234,6 +1241,17 @@
}
/**
+ * Callback to an incoming OPTIONS request.
+ */
+void ssc_i_options(int status, char const *phrase,
+ nua_t *nua, ssc_t *ssc,
+ nua_handle_t *nh, ssc_oper_t *op, sip_t const *sip,
+ tagi_t tags[])
+{
+ printf(%s: OPTIONS received\n, ssc-ssc_name);
+}
+
+/**
* Callback to an outgoing OPTIONS request.
*/
void ssc_r_options(int status, char const *phrase,
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [PATCH] Fix the environment variable name for sofsip_cli conf-ssc_certdir
Hi all, as in subject, I think this fixes a bug. Regards. --- old-sofsip-cli/src/sofsip_cli.c 2008-07-02 11:25:50.0 +0200 +++ new-sofsip-cli/src/sofsip_cli.c 2008-07-02 11:25:50.0 +0200 @@ -301,7 +301,7 @@ conf-ssc_aor = getenv(SOFSIP_ADDRESS); conf-ssc_proxy = getenv(SOFSIP_PROXY); conf-ssc_registrar = getenv(SOFSIP_REGISTRAR); - conf-ssc_certdir = getenv(SOFSIP_ADDRESS); + conf-ssc_certdir = getenv(SOFSIP_CERTDIR); conf-ssc_stun_server = getenv(SOFSIP_STUN_SERVER); /* step: process command line arguments */ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [PATCH] Implement a --verbose option in sofsip_cli
Hi,
as in subject.
This should make debugging easier, I'm not sure this is the better way
to define the logging level, please provide some feedback if you think
something could be done better.
Best regards.
--- old-sofsip-cli/src/ssc_sip.h 2008-07-02 14:45:49.0 +0200
+++ new-sofsip-cli/src/ssc_sip.h 2008-07-02 14:45:49.0 +0200
@@ -108,6 +108,7 @@
const char *ssc_aor;/** Public SIP address aka AOR (SIP URI) */
const char *ssc_certdir; /** Directory for TLS certs (directory path) */
const char *ssc_contact; /** SIP contact URI (local address to use) */
+ const char *ssc_su_log_level; /** sofia-sip SU logging verboseness level */
const char *ssc_media_addr; /** Media address (hostname, IP address) */
const char *ssc_media_impl; /** Media address (hostname, IP address) */
const char *ssc_proxy; /** SIP outbound proxy (SIP URI) */
--- old-sofsip-cli/src/sofsip_cli.c 2008-07-02 14:45:49.0 +0200
+++ new-sofsip-cli/src/sofsip_cli.c 2008-07-02 14:45:49.0 +0200
@@ -285,6 +285,7 @@
/* long, short, flags, arg, arg_data, desc, arg_desc */
GOptionEntry options[] = {
{ autoanswer, 'a', 0, G_OPTION_ARG_NONE, conf-ssc_autoanswer, Auto-answer to calls, NULL },
+{ verbose, 'v', 0, G_OPTION_ARG_INT, conf-ssc_su_log_level, Set the sofia-sip logging verboseness level (0 to 9), integer},
{ register, 'R', 0, G_OPTION_ARG_NONE, conf-ssc_register, Register at startup, NULL },
{ contact, 'c', 0, G_OPTION_ARG_STRING, conf-ssc_contact, SIP contact, local address to bind to (optional), SIP-URI },
{ media-addr, 'm', 0, G_OPTION_ARG_STRING, conf-ssc_media_addr, media address (optional), address },
@@ -323,6 +324,8 @@
}
}
+ su_log_set_level(NULL, (unsigned int)conf-ssc_su_log_level);
+
su_wait_create(cli-cli_input, 0, SU_WAIT_IN);
if (su_root_register(cli-cli_root,
cli-cli_input,
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] [NEWBIE] Can't send an invite
On date Monday 2008-06-09 15:51:11 +0200, Stefano Sabatini wrote: On date Friday 2008-06-06 14:50:26 +0200, Stefano Sabatini wrote: On date Friday 2008-06-06 13:38:57 +0200, Timo Bruhn wrote: [...] Hi Stefano, maybe this helps you: nua_invite(handle, NUTAG_MEDIA_ENABLE(0), TAG_END()); As far as i know this deactivates the SDP offer/answer engine for the call, which would wait for user sdp and won't send the invite if none is provided. You can activate the engine later in the call with: nua_set_hparams(handle, NUTAG_MEDIA_ENABLE(1), TAG_END()); Yes in this way it worked fine. By the way: if you destroy the handle directly after calling nua_invite(), sofia will end the call. Maybe this causes some trouble, two. Perhaps it would be better to destroy the handle in the event callback. Good point, I'll simply leave that for now (I still have to understand how to associate an arriving message of a dialog to an already sent one). BTW, which is the simpler way to print an incoming message in the event callback function? [...] Since I enabled the sofia-sip logging facility, now I can see: make sip-inviter; and env TPORT_DEBUG=1 sip-inviter sip:xx.xx.x.204:5060 gcc -g -O0 -I/home/stefano/include/sofia-sip-1.12 -L/home/stefano/lib -lsofia-sip-ua -o sip-inviter sip-inviter.c su_port_create(0x804a008): epoll_create() = 0: OK su_socket_port_init(0x804a008, 0xb7f62f80) called su_pthread_port_init(0x804a008, 0xb7f62f80) called nua: nua_create: entering su_port_create(0x804a790): epoll_create() = 0: OK su_socket_port_init(0x804a790, 0xb7f62f80) called su_pthread_port_init(0x804a790, 0xb7f62f80) called nua: nua_stack_init: entering nua: nua_stack_set_params: entering soa_create(default, 0x804ac18, 0x804acb0) called soa_set_params(static::0x804b0a0, ...) called soa_set_params(static::0x804b0a0, ...) 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 nta: master transport created nta: bound to (localhost:5060;transport=*) nta: agent_init_via: SIP/2.0/udp localhost (sip) nta: agent_init_via: SIP/2.0/tcp localhost (sip) nta: Via fields initialized nta: Contact header created nua_register: Adding contact URL 'localhost' to list. nua: nh_create_handle: entering Sending the invite to sip:10.88.3.204:5060... nua: nua_invite: entering nua(0x804d8b8): sent signal r_invite nua: nua_handle_destroy: entering nua(0x804d8b8): sent signal r_destroy nua: nua_stack_set_params: entering nta_leg_tcreate(0x804e050) nua(0x804d8b8): adding session usage nta: selecting scheme sip nta: INVITE (100259833): Invalid argument (22) with */[xx.xx.x.204]:5060 Do you have any hint about this? What's the meaning of the 22 code? It turned out that the problem was that the stack doesn't seem to recognize as valid an IP address (using latest Sofia darcs). It is this a limitation of sofia-sip or is it an error from myself? Anyway maybe a more clear message in the function tport_prepare_and_send in would be nice. Well so I put in my /etc/hosts a name for the hardsipphone I'm sending the invite to, and now I get: Starting program: /home/stefano/src/Sandbox/C/libsofia/sip-inviter sip:[EMAIL PROTECTED]:5060 [Thread debugging using libthread_db enabled] su_port_create(0x804a008): epoll_create() = 0: OK su_socket_port_init(0x804a008, 0xb7f42f80) called su_pthread_port_init(0x804a008, 0xb7f42f80) called nua: nua_create: entering [New Thread 0xb7ac86b0 (LWP 19128)] [New Thread 0xb7ac7b90 (LWP 19133)] su_port_create(0x804a790): epoll_create() = 0: OK su_socket_port_init(0x804a790, 0xb7f42f80) called su_pthread_port_init(0x804a790, 0xb7f42f80) called nua: nua_stack_init: entering nua: nua_stack_set_params: entering soa_create(default, 0x804ac18, 0x804acb0) called soa_set_params(static::0x804b0a0, ...) called soa_set_params(static::0x804b0a0, ...) 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(): 0x804c328 nta: master transport created tport_bind_server(0x804c328) to */localhost:5060/sip tport_bind_server(0x804c328): calling tport_listen for udp tport_alloc_primary(0x804c328): new primary tport 0x804cea8 tport_listen(0x804cea8): listening at udp/127.0.0.1:5060/sip tport_bind_server(0x804c328): calling tport_listen for tcp tport_alloc_primary(0x804c328): new primary tport 0x804d1b0 tport_listen(0x804d1b0): listening at tcp/127.0.0.1:5060/sip nta: bound to (localhost:5060;transport=*) nta: agent_init_via: SIP/2.0/udp localhost
Re: [Sofia-sip-devel] [NEWBIE] How to use the resolver simple interface
On date Thursday 2008-06-12 13:40:25 +0300, Pekka Pessi wrote:
2008/6/10 Stefano Sabatini [EMAIL PROTECTED]:
I'm trying to understand how the sresolv simple interface works.
Simple interface is intended for cases where your main loop is
running with su_root_t.
You can try to use blocking interface, see utils/sip-dig.c for an example.
Thank you Pekka,
here it is a complete example of use of the blocking interface.
somehow extrapolated by sip-dig.c.
I'm posting it for the archive.
---8-
#include sofia-sip/sresolv.h
#include sofia-sip/su_log.h
#include sofia-sip/url.h
#include stdlib.h
#include stdio.h
int main(int argc, char** argv)
{
url_t *url;
if (argc = 1) {
fprintf(stderr, Missing the address to resolve);
exit(1);
}
const char* url_str = argv[1];
/* parse the string and fill accordingly all the fields of the url struct */
url = url_hdup(NULL, (void *)url_str);
if (url url-url_type == url_unknown)
url_sanitize(url);
/* Initialize Sofia-SIP library and create event loop */
su_init ();
su_log_set_level(NULL, 9);
/* root = su_root_create(NULL); */
/* at first I need to create the DNS resolver object */
/* blocking interface */
/* instantiate the resolver */
sres_resolver_t* sres = sres_resolver_new(NULL);
if(!sres) {
fprintf(stderr, Impossible to instantiate a resolver, exiting);
exit(1);
}
/* then I need the sres_record_t struct where to put the request for the
query */
sres_record_t** answers= NULL;
const char *resolvaddr = NULL;
if (host_is_ip_address(url-url_host)) {
/* it's already resolved, no need to ask the DNS server */
printf(%s\n, url-url_host);
exit(0);
}
if (sres_blocking_query(sres, sres_type_a, url-url_host, 0, answers) 0)
{
fprintf(stderr, Impossible to resolve address: %s, url);
exit(1);
}
int i;
char addr[64];
for (i = 0; answers[i]; i++) {
/* sofia redefines the inet_ntop if it isn't already defined in the
system */
su_inet_ntop(AF_INET, answers[i]-sr_a-a_addr, addr, sizeof addr);
printf(%s\n, addr);
}
sres_free_answers(sres, answers);
sres_resolver_unref(sres);
exit(0);
}
---8-
Regards.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] [NEWBIE] How to use the resolver simple interface
Hi all,
I'm trying to understand how the sresolv simple interface works.
For this reason I wrote this small application in my sandbox, it
compiles but of course it doesn't do what I'd like to do.
I checked the doxy for sres_resolver_create() but they're quite
incomplete either I'm too dumb to understand how to properly use it.
I think this interface should work by registering some handler when
waiting for the DNS query, but I cuouldn't figure out how to register
that.
Also I would like if possible a simple description about the tags in
the sres_resolver_create (that is what they're meant to contain).
Here it is the application.
8---
#include sofia-sip/sresolv.h
#include sofia-sip/su_log.h
#include stdlib.h
#include stdio.h
int main(int argc, char** argv)
{
/* the main thread of the application which handles all the incoming events
*/
su_root_t *root;
su_log_set_level(NULL, 9);
if (argc = 1) {
fprintf(stderr, Missing the address to resolve);
exit(1);
}
const char* address = argv[1];
/* Initialize Sofia-SIP library and create event loop */
su_init ();
root = su_root_create(NULL);
/* at first I need to create the DNS resolver object */
sres_resolver_t* res = sres_resolver_create(root,
etc/resolv.conf,
TAG_NULL());
/* when should I take care of the destruction of the resolver object? */
/* I think I should register somewhere an handler which manages the
response of the
* query, then invoke its destruction from there */
/* sres_resolver_destroy(res); */
/* waits for godot */
while(1)
sleep(1);
exit(0);
}
8---
Maybe I'm just too lazy and I should simply read the code, I'm doing
it but I'm still far from getting a good grasp of how the whole system
works.
By the way, I also noticed that the doxy documentation is scattered
through C and header files (while I'd expect it to be defined only in
the headers), is there a particular reason for this?
I should be very grateful for any hint you can provide.
Best regards.
-
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] [NEWBIE] Can't send an invite
On date Friday 2008-06-06 13:38:57 +0200, Timo Bruhn wrote:
[...]
Hi Stefano,
maybe this helps you:
nua_invite(handle, NUTAG_MEDIA_ENABLE(0), TAG_END());
As far as i know this deactivates the SDP offer/answer engine for the call,
which would wait for user sdp and won't
send the invite if none is provided. You can activate the engine later in the
call with:
nua_set_hparams(handle, NUTAG_MEDIA_ENABLE(1), TAG_END());
Yes in this way it worked fine.
By the way: if you destroy the handle directly after calling nua_invite(),
sofia will end the call. Maybe this causes some
trouble, two. Perhaps it would be better to destroy the handle in the event
callback.
Good point, I'll simply leave that for now (I still have to understand
how to associate an arriving message of a dialog to an already sent
one).
BTW, which is the simpler way to print an incoming message in the
event callback function?
Here it is my new try:
8-
#include stdlib.h
#include stdio.h
#include sofia-sip/nua.h
#include sofia-sip/su_log.h
/* This callback will be called by SIP stack to
* process incoming events
*/
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[])
{
static unsigned int count = 1;
printf (arrived request number %d\n
I have received an event %s status %d %s\n,
count++, nua_event_name(event), status, phrase);
nua_handle_destroy(handle);
}
/**
* Creates a communication handle, sends an INVITE request and destroys it.
*/
int send_invite (nua_t *nua, const char* callee)
{
nua_handle_t *handle;
/* create an handle */
handle = nua_handle(nua, NULL,
SIPTAG_TO_STR(callee),
TAG_END());
if (!handle) {
fprintf(stderr, Failed to instantiate an handle for the invite\n);
fprintf(stderr, Maybe another instance of a sip client running on the
same port?\n);
return -1;
}
fprintf(stderr, Sending the invite to %s...\n, callee);
nua_invite(handle,
NUTAG_MEDIA_ENABLE(0), /* disable SDP media offer
TAG_END());
nua_handle_destroy(handle);
return 0;
}
int main (int argc, char *argv[])
{
su_root_t *root;
nua_t *nua;
su_log_set_level(NULL, 9);
if (argc = 1) {
fprintf(stderr, Missing the destination target);
exit(1);
}
const char* callee = argv[1];
/* Initialize Sofia-SIP library and create event loop */
su_init ();
root = su_root_create (NULL);
nua = nua_create(root, /* Event loop */
event_callback, /* Callback for processing events */
NULL, /* Additional data to pass to callback */
NUTAG_URL(sip:localhost:5060),
TAG_END()); /* Last tag should always finish the sequence
*/
/* send an invite to a remote sip client */
send_invite (nua, callee);
/* Run event loop */
su_root_run (root);
/* Destroy allocated resources */
nua_destroy (nua);
su_root_destroy (root);
su_deinit ();
return 0;
}
8-
Since I enabled the sofia-sip logging facility, now I can see:
make sip-inviter; and env TPORT_DEBUG=1 sip-inviter sip:xx.xx.x.204:5060
gcc -g -O0 -I/home/stefano/include/sofia-sip-1.12 -L/home/stefano/lib
-lsofia-sip-ua -o sip-inviter sip-inviter.c
su_port_create(0x804a008): epoll_create() = 0: OK
su_socket_port_init(0x804a008, 0xb7f62f80) called
su_pthread_port_init(0x804a008, 0xb7f62f80) called
nua: nua_create: entering
su_port_create(0x804a790): epoll_create() = 0: OK
su_socket_port_init(0x804a790, 0xb7f62f80) called
su_pthread_port_init(0x804a790, 0xb7f62f80) called
nua: nua_stack_init: entering
nua: nua_stack_set_params: entering
soa_create(default, 0x804ac18, 0x804acb0) called
soa_set_params(static::0x804b0a0, ...) called
soa_set_params(static::0x804b0a0, ...) 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
nta: master transport created
nta: bound to (localhost:5060;transport=*)
nta: agent_init_via: SIP/2.0/udp localhost (sip)
nta: agent_init_via: SIP/2.0/tcp localhost (sip)
nta: Via fields initialized
nta: Contact header created
nua_register: Adding contact URL 'localhost' to list.
nua: nh_create_handle: entering
Sending the invite to sip:10.88.3.204:5060...
nua: nua_invite: entering
nua(0x804d8b8): sent signal r_invite
nua:
[Sofia-sip-devel] [NEWBIE] Can't send an invite
Hi all,
this is my first post here, I have a very newbie usage question and I
don't know if this is the right place wether to ask, so please tell me
if this is the case.
I'm writing a little application in my sandbox to understand the basic
mechanisms of sofia-sip, here it is the code:
---8---
#include stdlib.h
#include stdio.h
#include sofia-sip/nua.h
/* This callback will be called by SIP stack to
* process incoming events
*/
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[])
{
static unsigned int count = 1;
printf (arrived request number %d\n
I have received an event %s status %d %s\n,
count++, nua_event_name(event), status, phrase);
/* how to print a message? */
}
/**
* Creates a communication handle, sends an INVITE request and destroys it.
*/
int send_invite (nua_t *nua, const char* callee)
{
nua_handle_t *handle;
/* create an handle */
handle = nua_handle(nua, NULL,
SIPTAG_TO_STR(callee),
TAG_END());
if (!handle) {
fprintf(stderr, Failed to instantiate an handle for the invite\n);
return -1;
}
fprintf(stderr, Sending the invite...\n);
nua_invite(handle,
TAG_END());
nua_handle_destroy(handle);
return 0;
}
int main (int argc, char *argv[])
{
su_root_t *root;
nua_t *nua;
if (argc = 1) {
fprintf(stderr, Missing the destination target);
exit(1);
}
const char* callee = argv[1];
/* Initialize Sofia-SIP library and create event loop */
su_init ();
root = su_root_create (NULL);
nua = nua_create(root, /* Event loop */
event_callback, /* Callback for processing events */
NULL, /* Additional data to pass to callback */
NUTAG_URL(sip:localhost:5060),
TAG_END()); /* Last tag should always finish the sequence
*/
/* send an invite to a remote sip client */
send_invite (nua, callee);
/* Run event loop */
su_root_run (root);
/* Destroy allocated resources */
nua_destroy (nua);
su_root_destroy (root);
su_deinit ();
exit(0);
}
---8---
It simply takes the first command line arguments and send an invite to
that address.
The problem is that although I can see:
[EMAIL PROTECTED] ~/s/S/C/libsofia sip-inviter sip:10.xx.x.204:5060
Sending the invite...
I don't see any SIP messages (using wireshark), also when I set a
bogus calle such as:
[EMAIL PROTECTED] ~/s/S/C/libsofia sip-inviter sip:foo:5060
Sending the invite...
I got the same result and no complain from sofia-sip, as I would
expect if it can't resolve the address.
What am I missing?
Many thanks in advance, best regards.
-
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
