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 :
> > 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 configuration under MinGW
On date Tuesday 2010-07-06 19:35:38 +0300, Pekka Pessi phoned this:
> 2010/7/6 Stefano Sabatini :
> > 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
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 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
[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] [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 : > > 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 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
Re: [Sofia-sip-devel] [PATCH] Fix configuration under MinGW
On date Tuesday 2010-07-06 11:55:57 -0400, Michael Jerris phoned: > Do these CFLAGS get into the build as well? a bit worried that we > need to do both this for the tests, and using top_ for the build. Indeed I'm not sure this fix is right at all, at least it is working for me but it may badly fails in other scenarios. I have no special expertise with auto* tools, and I still can't grasp how it solves the problem of defining the same flags for both the configure file and the Makefile. Hope someone with expertise in that area (Pekka?) can shed some light. [...] Regards. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] MinGW and libtool problem
Hi all,
after my latest fixes/hacks I'm still having problems with
compilation. Now it fails when calling libtool:
make[4]: Entering directory `/c/x/y/sofia-sip_1_12_10/libsofia-sip-ua/su'
/bin/sh ../../libtool --tag=CC --mode=link gcc -Wall -g -O2 -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 -Wl,--enable-auto-image-base -o addrinfo.exe addrinfo.o libsu.la -lpthread
-L./win32/pthread -lpthreadVC2 -lws2_32 -lwsock32
../../libtool: line 1933: cd: ./win32/pthread: Not a directory
libtool: link: cannot determine absolute directory name of `./win32/pthread'
gcc -Wall -g -O2 "-I{srcdir}/win32/pthread" -DWINVER=0x0501 -D_WIN32_WINNT=0x050
1 -DIN_LIBSOFIA_SIP_UA -DIN_LIBSOFIA_SRES -mms-bitfields -pipe -mno-cygwin -mwin
dows -mconsole -Wall -g -O0 -Wl,--enable-auto-image-base -o addrinfo.exe addrinf
o.o ./.libs/libsu.a -L./win32/pthread -lpthread -lpthreadVC2 -lws2_32 -lwsock32
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: cannot
find -lpthreadVC2
It's precisely failing in this snippet of the libtool script:
-L*)
dir=`$echo "X$arg" | $Xsed -e 's/^-L//'`
# We need an absolute path.
case $dir in
[\\/]* | [A-Za-z]:[\\/]*) ;;
*)
absdir=`cd "$dir" && pwd`
if test -z "$absdir"; then
$echo "$modename: cannot determine absolute directory name of
\`$dir'" 1>&2
absdir="$dir"
notinst_path="$notinst_path $dir"
fi
dir="$absdir"
;;
Since $dir is: ./win32/pthread, and the current dir is
libsofia-sip-ua/su, it's trying to cd to
libsofia-sip-ua/su/win32/pthread which is unexisting. I hacked libtool
to do:
absdir=`cd ../../"$dir" && pwd`
but this doesn't sound like the correct solution, as libtool is
auto-generated (and I'm rather clueless about it and all the libtool
thing) .
Can someone give some hint about a correct fix?
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 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:
In-Reply-To:
References:
From: Stefano Sabatini
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 ]])
+
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
[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
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
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 : > > 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 > > > > 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
[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
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 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
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] 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 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
[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] How to disable auto-respond for incoming REFER
In data Monday 2009-10-12 16:18:04 +0300, Pekka Pessi ha scritto:
> 2009/10/5 Stefano Sabatini :
> > I tried with NUTAG_APPL_METHOD("REFER") in nua_create(), indeed sofia
> > doesn't reply, problem is that my nua_respond() calls are ignored
> > anyway.
>
> For non-INVITE transactions you have to include NUTAG_WITH*() tag.
Yes thanks, trying with NUTAG_WITH_CURRENT(nua) worked just fine.
For the archive, I used that like this:
nua_respond(nh, SIP_202_ACCEPTED, NUTAG_WITH_CURENT(nua), TAG_END());
> > I'm using sofia-sip-1.12.9, are you aware of some issues in the
> > code? Also could you spot for a point in the code where to look?
>
> nua_stack_respond(), REFER server in nua_notifier.c?
Thanks, BYE.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
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 disable auto-respond for incoming REFER
Hi all, current documentation for the nua_i_refer event states: Incoming REFER call transfer. The tag list will contain tag NUTAG_REFER_EVENT() with the Event header constructed from the REFER request. It will also contain the SIPTAG_REFERRED_BY() tag with the Referred-By header containing the identity of the party sending the REFER. The Referred-By structure contained in the tag is constructed from the From header if the Referred-By header was not present in the REFER request. The application can let the nua to send NOTIFYs from the call it initiates with nua_invite() if it includes in the nua_invite() arguments both the NUTAG_NOTIFY_REFER() with the handle with which nua_i_refer was received and the NUTAG_REFER_EVENT() from nua_i_refer event tags. Parameters: status status code of response sent automatically by stack phrase a short textual description of status code nh operation handle associated with the incoming request hmagic application context associated with the handle (NULL if outside of an already established session) sip incoming REFER request tagsNUTAG_REFER_EVENT() SIPTAG_REFERRED_BY() and seems to *assume* that the response to the REFER event will be automatically sent, and I experienced the sofia-sip stack will automatically send a response with status 202. I wonder if it is possible to disable this behavior, and manually choose (e.g. with nua_respond()) which response to give to the REFER method. Many thanks in advance. Regards. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ 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
[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] 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] nua_i_state and nua_callstate_terminating
Hi all, I need to manage all the cases when sofia sends a BYE just in one point of code, and *before* it gets the reply to the BYE with nua_r_bye. The nua_i_state event with a nua_callstate_terminating state looks perfect for this purpose, but unfortunately it looks like sofia does not generate a nua_i_state event for that change of state. I'm using sofia-sip 1.12.9. Or it is indeed a bug or a feature missing from sofia, or am I missing something? Also I wonder if there could be such a nua_i_state event when the CANCEL is sent (always by nua_bye) instead of the BYE. Many thanks in advance, regards. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-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
On date Thursday 2009-03-05 15:48:49 +0100, Stefano Sabatini phoned this: > On date Tuesday 2009-03-03 20:35:50 +0200, Pekka Pessi phoned this: [...] > 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'm tackling the problem setting the call-id in the handle magic when I receive the nua_r_invite event. This isn't very nice, since the call-id is defined in the handle when I create it, so before I get the nua_r_invite I don't have that information in the magic, but it works for my own purposes. So again, would be possible to extend the nua_handle interface in order to make it possible to *extract* from the handle the Call-ID? > > 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. > [...] Again many thanks in advance. BYE -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-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] 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 <> 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
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 : > > 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
[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
Re: [Sofia-sip-devel] Move documentation from *.c to *.h
On date Monday 2009-03-02 17:15:27 +0200, Pekka Pessi phoned this: > 2009/3/2 Stefano Sabatini : > > 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. > > I think the documentation should as close to implementation as > possible. For C, it means that the macros, public structs, etc. should > be documented in .h files, functions in .c files. This way there is > much better chances that the documentation gets updated when the > functionality is updated. > > The interface gets documented in one place, however, thanks to Dimitri > van Heesch and Doxygen. I think most editors can get from headers to > doxygen-generated docs in a couple of keystrokes or mouse clicks. Or > to the source code, if you prefer raw @annotation. > > For Sofia, it is a bit ambiguous how to document tags as there is not > much to implement. The type-casting function is declared within the > macro in *.h and the actual name and type in *.c. I prefer a short > list *.h files and in some Sofia SIP modules I have moved the > documentation into the *_tag.c files. Other problematic things > include the platform-specific parts of su modules. > > Generally separating documentation from implementation creates extra > work that is needed to get the documentation updated. That extra work > has a tendency of not getting done as you might have noticed from > those @briefs now in *.h files. Indeed I don't consider this duplication a good idea, hopefully they should be documented in just a single point, either in the implementation or in the declaration. Since the headers are exposed to the user rather than the implementation (and not necessarily the user has the sources available), then I believe the documentation should go there. Doxygen is nice, but ask for the user to use JAT (Just Another Tool) means to add another layer of complexity on him, and I like the idea to simply read the headers and get all what I need (declaration *and* documentation). Also I still have to figure out a good way to integrate doxygen with emacs (but I'll do as I'll have more time). > > If that's OK I'll post here some patches for doing that, one header at > > a time. > > If you want to get rid of duplicate and contradictory @brief entries > I'd prefer removing the extra @brief comments from headers rather than > collecting the documentation to the *.h files. OK. 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] sofsip-cli compilation problems
On date Friday 2009-02-27 13:40:22 +, luo cheng phoned this: > Hi, > > I am trying to compile sofiasip cli example. But i am getting mission one > header file error: > > ssc_sip.c:64:29: ssc_media_fsgst.h: No such file or directory > > Actually it is true there is no such header file with my downloaded package? > So who knows where to find this header file? Downloaded it with darcs, and the file is there, maybe there has been an error in the packaging. > Another question is about ./configure options, how can i choose the > implementation options, e.g. i only want to have primary implementation? configure --help usually helps. Cheers. -- 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 : > > 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 Wednesday 2009-01-14 14:16:28 +0200, Pekka Pessi phoned this: > 2009/1/14 Stefano Sabatini : > > 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
[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 Monday 2009-01-12 16:19:06 +0200, Pekka Pessi phoned this: > 2009/1/12 Stefano Sabatini : > > 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
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 :
> > 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
#include
#include
#include
#include
#include
#include
/**
* 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
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 : > > 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
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 "),
> > 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 ;tag=m4KHeHvHZeU8Q
> > To: ;foo=bar
> > Call-ID: 8f686cee-3254-122c-6ebf-001a4b5c8ed5
> > CSeq: 107512154 INVITE
> > Contact:
> > 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(""), 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 ;tag=4tjrS2F4397pp
> > To:
> > Call-ID: f27c4f9b-3254-122c-0e84-001a4b5c8ed5
> > CSeq: 107512237 INVITE
> > Contact:
> > 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=100&url=/
___
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 "),
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 ;tag=m4KHeHvHZeU8Q
To: ;foo=bar
Call-ID: 8f686cee-3254-122c-6ebf-001a4b5c8ed5
CSeq: 107512154 INVITE
Contact:
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(""), 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 ;tag=4tjrS2F4397pp
To:
Call-ID: f27c4f9b-3254-122c-0e84-001a4b5c8ed5
CSeq: 107512237 INVITE
Contact:
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=100&url=/
___
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=100&url=/
___
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=100&url=/
___
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=100&url=/
___
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=100&url=/ ___ 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 12:31:47 +0200, elisa_murgia phoned this: > -- Initial Header --- > > >From : "Stefano Sabatini" [EMAIL PROTECTED] > To : sofia-sip-devel@lists.sourceforge.net > Cc : > Date : Mon, 22 Sep 2008 23:46:00 +0200 > Subject : Re: [Sofia-sip-devel] Using SOFIA-SIP just as a parser > > > > Hello again, > I've tried what you have suggested me, but it seems that it can work only if > I have strings with just a single sip message. My goal is, also, to > manipulate strings which hold more than one message and to use sofia to > divide and to parse carried messages. > I used msg-make() applied to the whole string and it s useful to find the > first sip message. > > msg_t* msg=msg_make(sip_default_mclass, 0, data, -1); > > msg_t* next=msg_next(msg); > > In this way sofia seems to find the second message begin, but it's not able > to parse it. > > When I use then > > msg_extract(next) > > it returns -1, like an error occurred. > > Is there a way to divide the string before to apply msg_make()? > > Any suggestion would be very appreciated. > Regards. I don't think you can use the sofia-sip external API to do that. What you can do is to use the code used *internally* by sofia-sip, check in: libsofia-sip-ua/sip/parser.c Maybe you could even convince the authors to export that functionality or provide a patch for that yourself... [...] 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=100&url=/ ___ 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 and > 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=100&url=/ ___ 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 Monday 2008-09-22 00:27:03 +0200, elisa_murgia phoned this: > Hello all, > > I'm new in SOFIA-SIP and I would like to use it just as a parser. I > mean that I have my own textual messages and I would like to send > them without using SOFIA structure. Then I need to parse incoming > messages and to capture some headers and status code. I ask: how is > it possible? I was thinking to use msg.h module and to fill message > buffer m_buffer with my textual message. Am I right? Thank you in > advance. Regards Elisa Hi, I think this should be relevant: http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/2660 Ciao - 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=100&url=/ ___ 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: 1>Linking... 1> Creating library .\Debug/sip_options_static.lib and object .\Debug/sip_options_static.exp 1>libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_ip 1>libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_reg 1>libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_reg 1>libsofia_sip_ua_static.lib(sres.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _sres_parse_win32_reg_parse_dnsserver 1>libsofia_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 1>Build log was saved at "file://c:\Users\fooobar\Documents\programmi\sofia-sip-1.12.9\win32\utils\sip_options_static\Debug\BuildLog.htm" 1>sip_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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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 Thursday 2008-09-11 17:32:10 +0200, Rémi BUISSON phoned this: > Hi, > > I have no idea how to do with a thread so I found an another solution. > > I have the SIP stack which receive commands from a python interface via > DBus. > > Try to do this it works very well for me. [...] Thank you but it definitevely doesn't look like a viable solution for me, due to the dependencies involved. Unfortunately this looks like an awkward constraint for me, or maybe I'm just wrong and I don't know how to properly use correctly the API. Can someone comment on this? TIA, 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=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Initialize sofia in the main context thread and run it in another thread
Hi all, I don't know if what is written in subject is possible. Indeed if I try to initialize the sofia stack in the main thread, and then instantiate a new thread and exececute su_root_run() in its context I get this error: SIPEngineTest: su_base_port.c:322: su_base_port_run: Assertion `su_port_own_thread(self)' failed. 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? TIA, best 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=100&url=/ ___ 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=100&url=/ ___ 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 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.
> > > >
> > > > 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 approach 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?
> > >
> > > Do I need to use the interface defined in su_wait.h?
> > > I was using the functions provided in another library for managing
> > > threading.
> >
> > Well I read the documentation for su_wait.h but I stll can't figure
> > out how to use it.
> >
> > Since there is no way to create explicitly a thread, I think the
> > nearest think to the thread concept is the task, then I can't see any
> > reference to mutexes so I have no idea about how synchronization may
> > work here (mmh well should I use messages for that?).
> >
> > Please can someone suggest just a simple way to use the sofia API to
> > create and run a thread?
>
> Here it is my first attempt at sofia threading:
[...]
New try using su_task_execute this time.
--8<-
#include
#include
#include
#include
/* this defines the kind of magic to pass to the handler, contains the
application context */
#define SU_ROOT_MAGIC_T void
#include
#include
int task_function(void* opaque) {
int i;
printf("click clack click clack...\n");
for (i=10; i > 0; i--) {
sleep(1);
printf("%d...\n", i);
}
printf("BOOM...\n");
return 0;
}
int main (int argc, char *argv[])
{
su_root_t *root;
/* Initialize Sofia-SIP library and create event loop */
su_init();
root = su_root_create(NULL); /* create a root object, don't pass to it any
context */
/* enable threading, now su_clone_start will start a new thread */
if (!su_root_threading(root, 1)) {
fprintf(stderr, "Failed to activate threading\n");
exit(1);
}
su_task_r task;
su_task_init(task); /* init the task */
int task_ended = 0;
if (su_task_execute(task, &task_function, NULL, &task_ended) < 0) {
fprintf(stderr, "Failed to execute the task\n");
exit(1);
}
printf("main process thread...\n");
/* how can I understand when the task thread is terminated?
* for now it will continue forever... */
while (1)
sleep(1);
/* Destroy allocated resources */
su_root_destroy(root);
/* how to notify the main thread of the termination of the task thread? */
su_task_deinit(task);
su_deinit();
exit(0);
}
--8<-
This always crashes with this backtrace:
(gdb) r
[Thread debugging using libthread_db enabled]
[New Thread 0xb7a576b0 (LWP 24551)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a576b0 (LWP 24551)]
0xb7ed4d84 in su_port_own_thread (self=0x0) at su_port.h:332
(gdb) bt
#0 0xb7ed4d84 in su_port_own_thread (self=0x0) at su_port.h:332
#1 0xb7ed4d20 in su_task_execute (task=0xbfd724a8, function=0x80486f4
, arg=0x0, return_value=0xbfd724a4) at su_root.c:338
#2 0x080487ec in main () at su-thread4.c:42
Ideas?
TIA, regards (and sorry for the mails flood).
-
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=100&url=/
___
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 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.
> > >
> > > 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 approach 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?
> >
> > Do I need to use the interface defined in su_wait.h?
> > I was using the functions provided in another library for managing
> > threading.
>
> Well I read the documentation for su_wait.h but I stll can't figure
> out how to use it.
>
> Since there is no way to create explicitly a thread, I think the
> nearest think to the thread concept is the task, then I can't see any
> reference to mutexes so I have no idea about how synchronization may
> work here (mmh well should I use messages for that?).
>
> Please can someone suggest just a simple way to use the sofia API to
> create and run a thread?
Here it is my first attempt at sofia threading:
--8<-
#include
#include
#include
#include
/* this defines the kind of magic to pass to the handler, contains the
application context */
#define SU_ROOT_MAGIC_T void
#include
#include
int countdown_init(su_root_t* root, su_root_magic_t* magic)
{
int i;
printf("click clack click clack...\n");
for (i=10; i > 0; i--) {
sleep(1);
printf("%d...\n", i);
}
return 0;
}
void countdown_deinit(su_root_t* root, su_root_magic_t* magic)
{
printf("BOOM...\n");
}
int main (int argc, char *argv[])
{
su_root_t *root;
/* Initialize Sofia-SIP library and create event loop */
su_init();
root = su_root_create(NULL); /* create a root object, don't pass to it any
context */
/* enable threading, now su_clone_start will start a new thread */
if (!su_root_threading(root, 1)) {
fprintf(stderr, "Failed to activate threading\n");
exit(1);
}
su_clone_r clone;
/* this is blocking */
su_clone_start(root,
clone,
NULL,
&countdown_init,
&countdown_deinit);
printf("main process thread...\n");
/* Destroy allocated resources */
su_root_destroy(root);
su_deinit();
exit(0);
}
--8<-
And this is the output:
click clack click clack...
10...
9...
8...
7...
6...
5...
4...
3...
2...
1...
main process thread...
In this case the call to the countdown_init function is blocking,
furthermore the countdown_deinit function is not called at all.
What (possbily silly) am I missing?
TIA, 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=100&url=/
___
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 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. > > > > 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? > > Do I need to use the interface defined in su_wait.h? > I was using the functions provided in another library for managing threading. Well I read the documentation for su_wait.h but I stll can't figure out how to use it. Since there is no way to create explicitly a thread, I think the nearest think to the thread concept is the task, then I can't see any reference to mutexes so I have no idea about how synchronization may work here (mmh well should I use messages for that?). Please can someone suggest just a simple way to use the sofia API to create and run a 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=100&url=/ ___ 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 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. > > 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? Do I need to use the interface defined in su_wait.h? I was using the functions provided in another library for managing threading. [...] 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Stop the nua stack
On 9/1/08, Rémi BUISSON <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I didn't success in stopping the nua stack.
>
> Here is my client code :
[...]
> /* if(sip->sip_payload && strcmp(sip->sip_payload->pl_data, TEARDOWN)
> == 0)
> {
> su_root_break(root);
> }*/
> if (status == STATUS_OK) {
> printDebug("end\n");
> /*su_root_break(appl->root); * I
> would like to stop here */
> return;
> }
Well if you comment all the places where is called the su_root_break()
function I think
you'll have to wait a lot to see sofia-sip breaks it itself...
[...]
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=100&url=/
___
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, Stefano Sabatini <[EMAIL PROTECTED]> wrote: > 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 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. 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. [...] 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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 negotiate the response SDP to an INVITE
On Wed, Aug 6, 2008 at 8:15 PM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > 2008/8/6 Stefano Sabatini <[EMAIL PROTECTED]>: >> In other words I would like to override the default behaviour, which >> consists in sending immediately the ACK for the remote SDP offer, >> when I would like to keep continuing with the S/O negotiation. >> >> Can you give me some indication regarding how to achieve that? > > You have to do a re-INVITE after the ACK, it is not possible to > initiate another offer-answer round in the original INVITE > transaction. > > But why do you want to do that? The answer just indicates that > answerer supports both your codecs. Do you want to make sure that the > A-law codec 8 is never used? Hi Pekka, thanks for your reply. I wanted to implement the scenario in RFC 3264, section 10.2, "One of N Codec Selection". So when the answerer responds, I want to lock down the set of codecs to use to only one. 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=100&url=/ ___ 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 negotiate the response SDP to an INVITE
Hi all,
I'm sending an invite with this function:
---8<
void si_invite(si_t *si, const char* destination)
{
si_oper_t* op = si_oper_create(si, SIP_METHOD_INVITE, destination,
TAG_END());
if (!op) {
printf("%s: failed to create an operation\n", si->name);
return;
}
printf("%s: sending the invite to %s...\n", si->name, destination);
nua_invite(op->handle)
NUTAG_MEDIA_ENABLE(1),
SOATAG_USER_SDP_STR("m=audio 5004 RTP/AVP 0 8"),
TAG_END());
}
---8<
I have this handler called by the nua event callback function:
-8<---
void app_i_state(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[])
{
char const *l_sdp = NULL, *r_sdp = NULL;
int audio = nua_active_inactive, video = nua_active_inactive, chat
= nua_active_inactive;
int offer_recv = 0, answer_recv = 0, offer_sent = 0, answer_sent = 0;
int state = nua_callstate_init;
tl_gets(tags,
NUTAG_CALLSTATE_REF(state),
NUTAG_OFFER_RECV_REF(offer_recv),
NUTAG_ANSWER_RECV_REF(answer_recv),
NUTAG_OFFER_SENT_REF(offer_sent),
NUTAG_ANSWER_SENT_REF(answer_sent),
SOATAG_LOCAL_SDP_STR_REF(l_sdp),
SOATAG_REMOTE_SDP_STR_REF(r_sdp),
TAG_END());
printf("Call-State: '%s'\n", nua_callstate_name(state));
if (l_sdp) {
printf("local SDP updated:\n%s\n", l_sdp);
}
if (r_sdp) {
printf("remote SDP updated:\n%s\n", r_sdp);
}
}
-8<---
I'm seeing this dialog:
SIP/SDP -->
<--- SIP 180 Ringing
< SIP/SDP 200 OK
---> SIP ACK 200 OK
Since I'm receiving this SDP message:
v=0
o=MxSIP 0 312671187 IN IP4 10.88.3.204
s=SIP Call
c=IN IP4 10.XX.X.204
t=0 0
m=audio 3000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
I would like to be able to disable one of the above two possible
streams, for example selecting just one with
an SDP like this:
v=0
o=- 7540392608856471085 7407346358474901725 IN IP4 10.XX.X.67
s=-
c=IN IP4 10.XX.X.67
t=0 0
m=audio 5004 RTP/AVP 0
a=rtpmap: 0 PCMU/8000
a=sendrcv
.
In other words I would like to override the default behaviour, which
consists in sending immediately the ACK for the remote SDP offer,
when I would like to keep continuing with the S/O negotiation.
Can you give me some indication regarding how to achieve that?
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=100&url=/
___
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=100&url=/
___
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 set media subsystem
On Mon, Aug 4, 2008 at 12:46 PM, Fan Xing <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I had a very simple voip application using sofia_sip and gstreamer.
> However, when I execute the code, 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).
>
> I studied the code of sofsip_cli and added the initialization of
> gstreamer in my code.
>
> #if HAVE_GST
> {
> guint major, minor, micro, nano;
> gst_init (NULL, NULL);
> gst_version (&major, &minor, µ, &nano);
> g_message ("This program is linked against GStreamer %d.%d.%d\n",
> major, minor, micro);
> }
> #endif
>
> However, I still do not get the sound.
>
> What else should be done in the code to make the 'audio' work? The
> complete code is attached below.
Eh eh, it's not that simple, you need to setup all the media system,
initializing gst isn't sufficient.
The libgstreamer developer's guide:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html
is an highly recommended reading if you want to understand how the
sofsip_cli media subsystem works.
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=100&url=/
___
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=100&url=/
___
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=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] sofsip_cli : how is activated the sending of RTP packets?
Hi all, I think this question should be easily addressed by someone which is familiar with the design of sofsip_cli, especially the part which deals with the media. During the invite the media subsystem is activated calling the activate method defined on the object, whatever it is. Then I can't figure out how it is activated the sending of the RTP packets, in other words when the response to the INVITE is received I can't see any event managed by sofia-sip which activates the delivery of the media stream, nonetheless at this point I can see (for example with wireshark) the RTP packets are sent, so I think some form of callback system is used for starting to send them. Just a few notions about the mechanism implemented would be sufficient. 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=100&url=/ ___ 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 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),
/* SOATAG_ADDRESS("0.0.0.0:8000"), */
NUTAG_EARLY_MEDIA(1),
TAG_END ());
Note also that SOATAG_ADDRESS seems to conflict with SOATAG_USER_SDP,
when they both are present the call seems to fail, the sofia-sip stack
logging also doesn't help, and I currently don't understand what's
the meaning of that tag.
[...]
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=100&url=/
___
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: Improve the behaviour of the set command
Hi,
with this patch the nua settings are not printed anymore at startup,
but whenever the user issue the "set" command.
Rationale: avoid to scare the user at startup with unwanted settings
printing, and provide a more useful output for the set command.
Also changes location to the code which prints the:
"Starting sofsip-cli in interactive mode. Issue 'h' to get list of
available commands."
banner, which seems to be more suited for src/sofsip_cli.c rather than
for src/ssc_sip.c.
Regards.
--- old-sofsip-cli/src/ssc_sip.c 2008-07-31 15:52:08.0 +0200
+++ new-sofsip-cli/src/ssc_sip.c 2008-07-31 15:52:08.0 +0200
@@ -246,7 +246,6 @@
TAG_IF(conf->ssc_certdir,
NUTAG_CERTIFICATE_DIR(conf->ssc_certdir)),
TAG_NULL());
-nua_get_params(ssc->ssc_nua, TAG_ANY(), TAG_NULL());
}
else {
ssc_destroy(ssc);
@@ -1897,8 +1896,6 @@
ssc->ssc_address = su_strdup(ssc->ssc_home, new_address);
}
}
-
- printf("\nStarting sofsip-cli in interactive mode. Issue 'h' to get list of available commands.\n");
}
/**
@@ -1920,7 +1917,7 @@
void ssc_print_settings(ssc_t *ssc)
{
- printf("SIP address...: %s\n", ssc->ssc_address);
+ nua_get_params(ssc->ssc_nua, TAG_ANY(), TAG_NULL());
}
void ssc_param(ssc_t *ssc, char *param, char *s)
--- old-sofsip-cli/src/sofsip_cli.c 2008-07-31 15:52:08.0 +0200
+++ new-sofsip-cli/src/sofsip_cli.c 2008-07-31 15:52:08.0 +0200
@@ -162,6 +162,7 @@
cli->cli_ssc = ssc_create(cli->cli_home, cli->cli_root, cli->cli_conf);
if (res != -1 && cli->cli_ssc) {
+printf("\nStarting sofsip-cli in interactive mode. Issue 'h' to get list of available commands.\n");
cli->cli_ssc->ssc_exit_cb = sofsip_shutdown_cb;
cli->cli_ssc->ssc_auth_req_cb = sofsip_auth_req_cb;
-
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=100&url=/___
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=100&url=/___ 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=100&url=/ ___ 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=100&url=/
___
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=100&url=/ ___ 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=100&url=/ ___ 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] [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] Say something when there is no operation to zap
Hi,
as in subject, feel free to improve the reported message.
Regards.
--- old-sofsip-cli/src/ssc_sip.c 2008-07-04 11:15:58.0 +0200
+++ new-sofsip-cli/src/ssc_sip.c 2008-07-04 11:15:58.0 +0200
@@ -1215,6 +1215,8 @@
priv_destroy_oper_with_disconnect (ssc, op);
/* ssc_oper_destroy(ssc, op); */
}
+ else
+ printf("No operations to zap\n");
}
/**
-
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 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] [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
[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 --aor option in sofsip_cli
Hi all,
actually the aor may be set only setting the SOFSIP_ADDRESS env var,
this patch makes it possible to set it through commandline (which
overrides env var settings).
Regards.
--- old-sofsip-cli/src/sofsip_cli.c 2008-07-02 11:00:40.0 +0200
+++ new-sofsip-cli/src/sofsip_cli.c 2008-07-02 11:00:40.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 },
+{ "aor", 'A', 0, G_OPTION_ARG_STRING, &conf->ssc_aor, "Set the address of record", "SIP-URI" },
{ "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" },
-
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] Problem compiling sofsip-cli nice_tester
On date Monday 2008-06-30 18:29:06 +0300, [EMAIL PROTECTED] wrote: > Hi, > > sorry for the late reply. > > On 18 June 2008, Stefano Sabatini wrote: > >It fails when I try to compile nice_tester (src dir in the > >sofsip-cli source root): > >[EMAIL PROTECTED] ~/s/s/src> make > [...] > >/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function > `_start': > >(.text+0x18): undefined reference to `main' collect2: ld returned 1 > exit status > [...] > > > >Is the problem reproducible or is something borken in my system? > > That's a bug in the makefiles. If you don't have libnice development > files installed (which is ok, not required), nice_tester should > not be built at all. > > I just fixed this in the darcs tree. Thanks for the report! I confirm it works now. Thanks for the fix!! Best 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
Re: [Sofia-sip-devel] SDP extension negotiation
On date Friday 2008-06-27 10:03:46 +0200, Jean Dumercq wrote:
>
> Hello, this is my first message and i'm a sofia-sip newbie. I have to do a
> simple application with sdp negotiation, but the problem is I need to
> negotiate specific attributes. My sdp looks like:
>
> SOATAG_USER_SDP_STR("v=0\r\nm=audio 5000 RTP/AVP 18 8\r\n"
> "a=rtpmap:18 G729/8000\r\n"
> "a=rtpmap:8 PCMA/8000\r\n"
> "a=interval:5 10\r\n"
> "a=method:M1 M2 M3\r\n")
>
> I succeed to negotiate the codec but not the specific attributes
> "interval" and "method". How can I do that? Is there a tag I missed?
> Perhaps I need to modify the stack but I have a lot of difficulties
> to understand it.
Just a little suggestion, since I'm a sofia-sip newbie myself and I'm
facing the same difficulties.
Read and study the code of the relatively simple reference
implementation of a sofia-sip application sifsip-cli, also it would
help to check here and there the code of libsofia-sip itself, the code
at first appears huge and complicated so you have to spend some time
within its gutters before to catch the big scheme (as an incentive for
doing that: there is a lot to learn by doing that).
Basically this is the main layout of sofsip_cli:
* sofsip_cli is the application context
* root is the application root, where is registered the keyboard
event handler callback
* ssc is the signaling event subsystem, it contains a nua object which
is created during the system startup, and manages all signaling
events (Incoming messages and Response messages)
* media events are managed through GStreamer
Also, both for the archive and to incentive readers to post some
feedback it would help to provide some code snippet showing the
problem you're trying to tackle.
HTH, 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] [PATCH] Make sofsip-cli exit in case of cli parsing error
Hi,
trivial patch which does as in subject.
Regards.
--- old-sofsip-cli/src/sofsip_cli.c 2008-06-23 17:30:44.0 +0200
+++ new-sofsip-cli/src/sofsip_cli.c 2008-06-23 17:30:44.0 +0200
@@ -295,6 +295,7 @@
{ NULL }
};
GOptionContext *context;
+ GError *error = NULL;
/* step: process environment variables */
conf->ssc_aor = getenv("SOFSIP_ADDRESS");
@@ -309,7 +310,10 @@
#if HAVE_GST
g_option_context_add_group (context, gst_init_get_option_group ());
#endif
- g_option_context_parse(context, &ac, &av, NULL);
+ if (!g_option_context_parse(context, &ac, &av, &error)) {
+ g_print ("option parsing failed: %s\n", error->message);
+ exit (1);
+ }
g_option_context_free(context);
for (i = 1; i < ac; i++) {
-
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] Problem compiling sofsip-cli nice_tester
Hi all, I'm getting some problem when compiling sofsip-cli, latest darcs. It fails when I try to compile nice_tester (src dir in the sofsip-cli source root): [EMAIL PROTECTED] ~/s/s/src> make /bin/sh ../libtool --tag=CC --mode=link gcc -I/home/stefano/include/ -L/home/stefano/lib -o nice_tester nice_tester.o libsofsip-cli-objects.la -L/home/stefano/lib -lsofia-sip-ua -L/home/stefano/lib -lsofia-sip-ua-glib -lsofia-sip-ua -lglib-2.0 -pthread -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -lgobject-2.0 -lglib-2.0 -lreadline -lncurses -lpthread gcc -I/home/stefano/include/ -o nice_tester nice_tester.o -pthread -L/home/stefano/lib ./.libs/libsofsip-cli-objects.a /home/stefano/lib/libsofia-sip-ua-glib.so /home/stefano/lib/libsofia-sip-ua.so /usr/lib/libgstreamer-0.10.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgthread-2.0.so -lrt /usr/lib/libxml2.so /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -lreadline -lncurses -lpthread -Wl,--rpath -Wl,/home/stefano/lib -Wl,--rpath -Wl,/home/stefano/lib /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make: *** [nice_tester] Error 1 Is the problem reproducible or is something borken in my system? Regards and thanks in advance for your help. - 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 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_s
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
#include
#include "sofia-sip/url.h"
#include
#include
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
#include
#include
#include
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 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): cal
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
#include
#include
#include
/* 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: nua_handle_destroy: entering
[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
#include
#include
/* 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
