2009/6/30 Inca Rose :
> I know the STUN code is not complete or is not 100% integrated on NUA
> or NTA.
> I would like to take a look and see if I can finish this work by
> integrating the missing parts.
> I have done similar work on my company's own SIP Stack and STUN Stack.
> All that I need is
Hi;
I know the STUN code is not complete or is not 100% integrated on NUA
or NTA.
I would like to take a look and see if I can finish this work by
integrating the missing parts.
I have done similar work on my company's own SIP Stack and STUN Stack.
All that I need is a some guidelines on where
Hello All,
Is there any reason why STUN is not mentioned in the Sofia-SIP features
table page, even though it is supported? Here's the link:
http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html
Best Regards,
Jerry
2007/12/20, Ge@@ru <[EMAIL PROTECTED]>:
> So, we can consider our patch or somethings like that a valid solution
> for this segfault?! :)
Certainly yes, but it is not solving all the cases.
> Happy Christmas and Happy New Year!
Merry Christmas everyone!
--Pekka
> On Thu, 2007-12-20 at 15:13 +0
So, we can consider our patch or somethings like that a valid solution
for this segfault?! :)
Thanks you very much.
Happy Christmas and Happy New Year!
Ge@@ru
On Thu, 2007-12-20 at 15:13 +0200, Pekka Pessi wrote:
> 2007/12/7, Ge@@ru <[EMAIL PROTECTED]>:
> > I try to use STUN feature of Sofia i
2007/12/7, Ge@@ru <[EMAIL PROTECTED]>:
> I try to use STUN feature of Sofia i have the following problem:
>
> If i try to destroy stun_handle_t (with stun_handle_destroy) inside
> stun_bind_cb there is always a segfault at row 2001 of stun.c file
> because sofia try to access to req variable after
I try to use STUN feature of Sofia i have the following problem:
If i try to destroy stun_handle_t (with stun_handle_destroy) inside
stun_bind_cb there is always a segfault at row 2001 of stun.c file
because sofia try to access to req variable after that req is been
destroyed by stun_handle_destro
Hello,
I just pushed a small workaround for a bug in stund-0.94 and older
(http://sourceforge.net/projects/stun/). The new stund-0.96 version is ok.
Unfortunately this server sw is deployed quite widely, and the chances of
encountering old implementations is quite high, so I thought it's better
On Wed, 26 Apr 2006, Pekka Pessi wrote:
On 4/20/06, Dimitri E. Prado <[EMAIL PROTECTED]> wrote:
It seems that all stun*.c files need conditionals like
#if HAVE_FUNC
I added the #if HAVE_FUNC thing to stunc.c, which missed it and used __func__.
Sorry, my bad. I'll promise to try remembering t
On 4/20/06, Dimitri E. Prado <[EMAIL PROTECTED]> wrote:
> It seems that all stun*.c files need conditionals like
> #if HAVE_FUNC
...
I added the #if HAVE_FUNC thing to stunc.c, which missed it and used __func__.
> What's the peferred way to report such things, do you prefer to have it
> added dir
o: [email protected]
>Subject: RE: [Sofia-sip-devel] STUN and TLS
>
>My bad!! I have been working on the latest code from
>sourceforge, but I just
>found out that the stun code on dev-126.openlaboratory.net is
>much different
>and might not have this proble
My bad!! I have been working on the latest code from sourceforge, but I just
found out that the stun code on dev-126.openlaboratory.net is much different
and might not have this problem.
> > locating one that does use it. I noticed that the current sofia stun
> > implementation does not work witho
It seems that all stun*.c files need conditionals like
#if HAVE_FUNC
#elif HAVE_FUNCTION
#define __func__ __FUNCTION__
#else
#define __func__ "stun"
#endif
In order to compile under MSVC , otherwise MSVC barfs at
__func__
What’s the peferred way to report such things, do yo
Hi,
On Thu, 20 Apr 2006, Dimitri E. Prado wrote:
Even though RFC3489 mandates the use of "shared secrets" through TLS , quite
a few STUN implementations do not use it. I am actually having a hard time
yeps, this is a bit tricky thing. Also, in the RFC3489bis, the TLS based
mechanism will pro
Hello All,
Even though RFC3489 mandates the use of “shared secrets”
through TLS , quite a few STUN implementations do not use it. I am actually
having a hard time locating one that does use it. I noticed that the current sofia stun implementation
does not work without shared keys, even
Hello,
On Fri, 13 Jan 2006 [EMAIL PROTECTED] wrote:
Lots of other changes done; several bug fixes in state machines,
restructuring. All references to stun servers etc. are now kept inside
stun_discovery objects. This way it's basically possible to use one
stun_handle with different STUN servers
Jou,
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf
>Of ext Kai Vehmanen
>Sent: 11. tammikuuta 2006 20:34
>To: [email protected]
>Subject: RE: [Sofia-sip-devel] STUN NAT type discovery works (?)
>
>
On Wed, 11 Jan 2006 [EMAIL PROTECTED] wrote:
It was only a straight-forward implementation in stunc.c, but I now
zapped unnecessary su_root_breaks and moved NAT type and lifetime
determinations to start in callback after successful stun_bind_done.
Ok great!
Btw, one pretty serious issue: the
Hey,
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf
>Of ext Kai Vehmanen
>Sent: 11. tammikuuta 2006 18:54
>To: [email protected]
>Subject: Re: [Sofia-sip-devel] STUN NAT type discovery works (?)
>
&g
On Thu, 5 Jan 2006 [EMAIL PROTECTED] wrote:
STUN's new structure starts to be stabilized. I just updated CVS to
Here's a few issues I've noted when I've ported the farsight-netsocket
code to the latest API release.
1. stun_handle has the information of the TLS and UDP sockets, su_root
etc.
Martti,
I added the tport integration functions to stun.h:
/** Callback invoked by stun handle when it has a message to send. */
typedef int (*stun_send_callback)(stun_magic_t *magic,
stun_handle_t *se,
int socket,
On Tue, 10 Jan 2006 [EMAIL PROTECTED] wrote:
Yes, we are using darcs (mostly with Pekka). Our repository is at
[EMAIL PROTECTED]:sofia-sip. Pekka has been kindly
granting developer accesses for the tree itself, but maybe you can fetch
the tree via http (I haven't tried it :| )?
yeps, Pekka's
--
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf
>Of ext Rob Taylor
>Sent: 10. tammikuuta 2006 11:46
>To: Mela Martti (Nokia-NRC/Helsinki)
>Cc: [email protected]
>Subject: Re: [Sofia-sip-devel] STUN NAT type discovery works (?)
>
>Martti, c
TED] [mailto:[EMAIL PROTECTED] On Behalf Of ext
> Abner José
> Sent: 6. tammikuuta 2006 19:24
> To: [email protected]
> Subject: Re: [Sofia-sip-devel] STUN NAT type discovery works (?)
>
>
> Hi Martti,
>
>
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext
Abner José
Sent: 6. tammikuuta 2006 19:24
To: [email protected]
Subject: Re: [Sofia-sip-devel] STUN NAT type discovery works (?)
Hi Martti,
Really
Hi Martti,
Really great news about STUN and I'll test it ASAP!
Well, about the get_lifetime mechanism I was working on it, but now it's stoped because I have some vacation days! ;)
I'll come back to work in the half of current month and I can keep working on get_lifetime, if you don't finish it i
Hey,
STUN's new structure starts to be stabilized. I just updated CVS to
contain modifications that should enable STUN NAT type determination
with the asyncrounous API. Next week STUN related work should be that
far that we we could integrate this to tport, too.
This is how it looks now: there a
27 matches
Mail list logo
