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

2008-01-23 Thread Pekka Pessi
2008/1/22, Jerry Richards <[EMAIL PROTECTED]>:
> If I call "sip_update_default_mclass(sip_extend_mclass(NULL))" during
> initialization as you mention below, then which field of the (INVITE) sip
> message (in the NUA callback function) would I find the "Alert-Info" header?
>
> Up until now, I have been pulling it out of the "sip->sip_unknown->un_name
> field", but it looks like that will no longer work?

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

-- 
Pekka.Pessi mail at nokia.com

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


[Sofia-sip-devel] [ sofia-sip-Bugs-1878039 ] Memory leak in handling of incoming ACK request

2008-01-23 Thread SourceForge.net
Bugs item #1878039, was opened at 2008-01-23 17:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1878039&group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tirthankar Saha (tirthankarsaha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in handling of incoming ACK request

Initial Comment:
Valgrind reports leaks in a simple UAS application written using Sofia-NUA 
library (1.12.7). One possible leak which has been noticed is in handling of 
incoming ACK request for 2xx response. 

Prelim analysis suggests that the memory home for the incoming ACK request is 
not un-ref-ed (since it is not stored as separate irq object in any saved list)

Adding the following code block (delimited by PATCH_START comment in code 
snippet below) at the end of nua_event() function in nua.c fixes the leak. This 
may not be the proper fix.



/*# Receive event from protocol machine and hand it over to application */
void nua_event(nua_t *root_magic, su_msg_r sumsg, event_t *e)
{
  nua_t *nua;
  nua_handle_t *nh = e->e_nh;
  enter;

  e->e_nh = NULL;

  if (nh) {
if (!nh->nh_ref_by_user && nh->nh_valid) {
  nh->nh_ref_by_user = 1;
  nua_handle_ref(nh);
}
  }

  if (!nh || !nh->nh_valid) {   /* Handle has been destroyed */
if (nua_log->log_level >= 7) {
  char const *name = nua_event_name(e->e_event) + 4;
  SU_DEBUG_7(("nua(%p): event %s dropped\n", (void *)nh, name));
}
if (nh && !NH_IS_DEFAULT(nh) && nua_handle_unref(nh)) {
#if HAVE_NUA_HANDLE_DEBUG
  SU_DEBUG_0(("nua(%p): freed by application\n", (void *)nh));
#else
  SU_DEBUG_9(("nua(%p): freed by application\n", (void *)nh));
#endif
}
if (e->e_msg)
  msg_destroy(e->e_msg), e->e_msg = NULL;
return;
  }

  nua = nh->nh_nua; assert(nua);

  if (NH_IS_DEFAULT(nh))
nh = NULL;

  if (e->e_event == nua_r_shutdown && e->e_status >= 200)
nua->nua_shutdown_final = 1;

  if (nua->nua_callback) {
nua_event_frame_t frame[1];

su_msg_remove_refs(sumsg);/* Remove references to tasks */
su_msg_save(frame->nf_saved, sumsg);
frame->nf_nua = nua;
frame->nf_next = nua->nua_current, nua->nua_current = frame;

nua->nua_callback(e->e_event, e->e_status, e->e_phrase,
  nua, nua->nua_magic,
  nh, nh ? nh->nh_magic : NULL,
  e->e_msg ? sip_object(e->e_msg) : NULL,
  e->e_tags);

su_msg_destroy(frame->nf_saved);

if (frame->nf_nua == NULL)
  return;
nua->nua_current = frame->nf_next;
  }

/* __PATCH_START__ */
  if (e && e->e_msg && e->e_event == nua_i_ack)
  {
 /*specific for ACK event*/
 su_home_unref(msg_home(e->e_msg));
  }
/* __PATCH_END__ */



  if (nh && nua_handle_unref(nh)) {
#if HAVE_NUA_HANDLE_DEBUG
SU_DEBUG_0(("nua(%p): freed by application\n", (void *)nh));
#else
SU_DEBUG_9(("nua(%p): freed by application\n", (void *)nh));
#endif
  }
}


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1878039&group_id=143636

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


Re: [Sofia-sip-devel] proxy authentication failed when redirecting

2008-01-23 Thread Pekka Pessi
2008/1/23, Martin Drasar <[EMAIL PROTECTED]>:
> 1) I have modified the proxy to send some realm and it didn't help.
> 2) reINVITE
> I'm not sure how the reinvite works so I have just tried this piece of code:
> nua_invite(nh, TAG_END());
> Problem is that the invite is sent, but it's not challenged. (Don't have
> an idea why. Proxy is Alcatel OmniPCX enterprise.)
> 3) I have tried to debug deep into the bovels of sofia and I have found
> that in the function nua_stack_authenticate value of nh->nh_ds->ds_cr is
> NULL.

Is there something in nh->nh_auth?

> Also nh_authorize returns 0.

Could you have a peek in 407 response, is the
sip->sip_proxy_authenticate non-NULL? Does nua call auc_challenge()?

-- 
Pekka.Pessi mail at nokia.com

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


Re: [Sofia-sip-devel] proxy authentication failed when redirecting

2008-01-23 Thread Martin Drasar
Pekka Pessi napsal(a):
> 2008/1/18, Martin Drasar <[EMAIL PROTECTED]>:
>   
>> I have a problem with proxy authentication.
>>
>> My user agent registers itself with proxy without a problem. However
>> when I want it to redirect a call, the following happens:
>>
>> 1) REFER is sent to proxy
>> 2) Proxy answers with 407
>> 3) In nua_r_refer event I use this code to answer the challenge:
>>
>> const char* realm =
>> msg_params_find(sip->sip_proxy_authenticate->au_params, "realm=");
>> sprintf(authString, "Digest:%s:%s:%s", realm, proxy->username,
>> proxy->password);
>> nua_authenticate(proxy->proxyHandle, NUTAG_AUTH(authString), TAG_END());
>>
>> 4) Then I get 904 "No matching challenge"
>> 
>
> Weird.
>
> It seems to me that REFER manages to trash its dialog if it is used on
> a new handle, but it should not affect your case. Have you tried to
> send other in-dialog requests, like re-INVITE? What happens when they
> are challenged?
>
> Could you also try to narrow down the problem and try with a proxy
> that has something in realm?
>
> --Pekka
Hi Pekka,
thanks for the response.

1) I have modified the proxy to send some realm and it didn't help.
2) reINVITE
I'm not sure how the reinvite works so I have just tried this piece of code:
nua_invite(nh, TAG_END());
Problem is that the invite is sent, but it's not challenged. (Don't have 
an idea why. Proxy is Alcatel OmniPCX enterprise.)
3) I have tried to debug deep into the bovels of sofia and I have found 
that in the function nua_stack_authenticate value of nh->nh_ds->ds_cr is 
NULL.
Also nh_authorize returns 0.

I don't know what might help you in tracking down the issue, but if you 
give me some more pointers I will try to find more.

Thanks
Martin

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


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


Re: [Sofia-sip-devel] proxy authentication failed when redirecting

2008-01-23 Thread Pekka Pessi
2008/1/23, Martin Drasar <[EMAIL PROTECTED]>:
> > Could you have a peek in 407 response, is the
> > sip->sip_proxy_authenticate non-NULL? Does nua call auc_challenge()?

> auc_challenge is called, but the first parameter (nh->nh_auth) is NULL.
> sip->sip_proxy_authenticate has some data inside.

Hm. And when auc_challenge returns, is nh->nh_auth updated?

-- 
Pekka.Pessi mail at nokia.com

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


Re: [Sofia-sip-devel] proxy authentication failed when redirecting

2008-01-23 Thread Martin Drasar
Pekka Pessi napsal(a):
> 2008/1/23, Martin Drasar <[EMAIL PROTECTED]>:
>   
>> 1) I have modified the proxy to send some realm and it didn't help.
>> 2) reINVITE
>> I'm not sure how the reinvite works so I have just tried this piece of code:
>> nua_invite(nh, TAG_END());
>> Problem is that the invite is sent, but it's not challenged. (Don't have
>> an idea why. Proxy is Alcatel OmniPCX enterprise.)
>> 3) I have tried to debug deep into the bovels of sofia and I have found
>> that in the function nua_stack_authenticate value of nh->nh_ds->ds_cr is
>> NULL.
>> 
>
> Is there something in nh->nh_auth?
>
>   
>> Also nh_authorize returns 0.
>> 
>
> Could you have a peek in 407 response, is the
> sip->sip_proxy_authenticate non-NULL? Does nua call auc_challenge()?
>
>   
auc_challenge is called, but the first parameter (nh->nh_auth) is NULL.
sip->sip_proxy_authenticate has some data inside.

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


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


Re: [Sofia-sip-devel] proxy authentication failed when redirecting

2008-01-23 Thread Martin Drasar
Pekka Pessi napsal(a):
> 2008/1/23, Martin Drasar <[EMAIL PROTECTED]>:
>   
>>> Could you have a peek in 407 response, is the
>>> sip->sip_proxy_authenticate non-NULL? Does nua call auc_challenge()?
>>>   
>
>   
>> auc_challenge is called, but the first parameter (nh->nh_auth) is NULL.
>> sip->sip_proxy_authenticate has some data inside.
>> 
>
> Hm. And when auc_challenge returns, is nh->nh_auth updated?
>
>   
yes, it is and nua_client_response returns 0


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


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


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

2008-01-23 Thread Jerry Richards
Hi,

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

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

Best Regards,
Jerry


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

2008/1/22, Jerry Richards <[EMAIL PROTECTED]>:
> If I call "sip_update_default_mclass(sip_extend_mclass(NULL))" during 
> initialization as you mention below, then which field of the (INVITE) 
> sip message (in the NUA callback function) would I find the "Alert-Info"
header?
>
> Up until now, I have been pulling it out of the 
> "sip->sip_unknown->un_name field", but it looks like that will no longer
work?

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

--
Pekka.Pessi mail at nokia.com


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


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

2008-01-23 Thread Michael Jerris
You can access the whole header as:

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

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

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

Mike



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

> Hi,
>
> Okay, I added a call to sip_alert_info(sip) in the callback function  
> when I
> receive the nua_i_invite 100 event.  However, the ai_params and ai_url
> fields of the sip_alert_info_t structured returned from  
> sip_alert_info() is
> not valid ASCII data (i.e. negative numbers).
>
> Is there any other way to get at that data?  Or anything else I can  
> try?
>
> Best Regards,
> Jerry
>
>
> -Original Message-
> From: Pekka Pessi [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 23, 2008 3:43 AM
> To: Jerry Richards
> Cc: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: SIPTAG_P_PREFERRED_IDENTITY()
>
> 2008/1/22, Jerry Richards <[EMAIL PROTECTED]>:
>> If I call "sip_update_default_mclass(sip_extend_mclass(NULL))" during
>> initialization as you mention below, then which field of the (INVITE)
>> sip message (in the NUA callback function) would I find the "Alert- 
>> Info"
> header?
>>
>> Up until now, I have been pulling it out of the
>> "sip->sip_unknown->un_name field", but it looks like that will no  
>> longer
> work?
>
> There is no field, you have to use accessor function
> sip_alert_info(sip) (which will return pointer to sip_alert_info_t  
> struct).
>
> --
> Pekka.Pessi mail at nokia.com
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


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


[Sofia-sip-devel] ANNOUNCE: Sofia SIP release 1.12.8

2008-01-23 Thread Pekka Pessi
Hello all,

The latest and most shiniest Sofia SIP 1.12.8 is now out. The source
tar is available from sourceforge.net, the CVS on sourceforge.net has
been updated, and the up-to-date sources are also available from our
darcs repo at .

The release notes can be found below.

--Pekka

===
Release notes for Sofia SIP version 1.12.8 (2007-01-23)
===

Sofia SIP is an open-source SIP User-Agent library, compliant with
the IETF RFC3261 specification. It can be used as a building block
for SIP client software for uses such as VoIP, IM, and many other
real-time and person-to-person communication services. The primary
target platform for Sofia SIP is GNU/Linux. Sofia SIP is based on a
SIP stack developed at the Nokia Research Center. Sofia SIP is
licensed under the LGPL.


==
Release notes for Sofia-SIP 1.12.8
==

Changes since last release
--

Beside bugfixes, a server graylisting was added to nta and a few
improvements in event handling were made in nua interface.

A check-based test program was added, too.

API/ABI changes and versioning
--

New features in API are marked with Doxytag macro @NEW_1_12_8 or
@VERSION_1_12_8.

libsofia-sip-ua:
- Added nta_sip_is_internal(), nta_msg_is_internal() function in
  . Deprecating nta_is_internal_msg().
- Added su_msg_new(), su_msg_send_to() and su_msg_deinitializer() for more
  robust and light-weight message passing in 
- Added su_home_lock(), su_home_trylock(), and su_home_unlock() in
  
- Added type-neutral template macros for hash tables
HTABLE2_DECLARE2(), HTABLE2_PROTOS2(),
  and HTABLE2_BODIES2().
- Added sres_cache_set_srv_priority() in  and
  sres_set_cached_srv_priority()  for graylisting
  SRV records for inresponsive servers.
- nua_create()/nta_agent_create()/tport_bind() now joins to multicast group
  if "maddr" parameter is specified
- This release is ABI/API compatible with applications linked against
  any 1.12.x release. However, applications built against this release won't
  work against an older library. The ABI has been tested with the nua module
  unit test (test_nua) built against original 1.12.0 release.

libsofia-sip-ua-glib:
- No ABI/API changes, compatible with 1.12.0. Note, libsofia-sip-ua-glib
  interface is not considered stable and may change in a future 1.12.x
  release.

Contributors to this release


- Bernhard Suttner contributed patch to soa for using a=inactive attribute
  with call hold
- Stefan Leuenberger from Netmodule contributed the hack for changing
  priority of SRV records if a SIP server was inresponsive
- Daniele Rondina contributed patches fixing crash in STUN discovery cleanup
  and for transport handling with nta_outgoing_*create()
- Youness Alaoui sent a iPhone build fix
- Michael Jerris and Stefan Knoblich from Freeswitch project reported
  numerous bugs and contributed fixes

See the AUTHORS file in the distribution package.

Notes on new features
-

* SIP Server Graylisting

  The hack contributed by Stefan Leuenberger from Netmodule changes the
  priority of SRV records which are used when SIP URI is resolved.

  If your domain has multiple servers, you can define separate SRV records
  for them. If any of them becomes unresponsive, a SIP request sent to it
  times out or gets rejected because of network error and Sofia SIP
  automatically retries with another server. However, as Sofia SIP does not
  keep track of failed servers with the next request it may again try first
  the failed server. The graylisting reprioritizes the SRV records so that the
  priority of the failed server gets reduced and it won't be tried again
  until all other servers have failed, too. Note that the SIP URI resolver
  may get confused when using this kind of reprioritizing if a single SRV
  record corresponds to multiple servers or servers with multiple addresses.

  You can disable the reprioritizing hack by including tag
  NTATAG_GREYLIST(0) with nua_create(), nua_set_params(), nta_agent_create()
  or nta_agent_set_params().

Bugs fixed in this release
--

* Fixed su_home_init not initializing suh_lock.
* Fixed memory leak when increasing hash table size
* Fixed problems with multiple authentication challenges.
* Fixed sf.net bug #1816647: Outbound contact does not make it to dialogs.
* Fixed problem with tagargs, amd64 and Sun CC.
* Fixed nta_outgoing_*create() not using NTATAG_TPORT() if
  NTATAG_DEFAULT_PROXY() was set.
* Fixed memory leak from nua operations.
* Fixed crash when INVITE destroyed session before UPDATE or PRACK completed
* Fixed crash in stun when destroying stun context during discovery callback
* Fixed nta timer interval calculation ignoring some transactions
* Fixed request merging when clie

[Sofia-sip-devel] sofia-sip changes (2008-01-23)

2008-01-23 Thread Sofia-SIP Darcs Changes
This posting was generated automatically from darcs repo
.

Wed Jan 23 21:25:07 EET 2008  [EMAIL PROTECTED]
  * RELEASE, configure.ac: 1.12.8devel

M ./RELEASE -78 +40
M ./configure.ac -1 +1

Wed Jan 23 20:18:16 EET 2008  [EMAIL PROTECTED]
  * test_100rel.c: added test for redirect after 100rel response.

M ./libsofia-sip-ua/nua/test_100rel.c -1 +480

Wed Jan 23 20:08:55 EET 2008  [EMAIL PROTECTED]
  * nua: terminate dialog when redirected and re-establish it with new request

M ./libsofia-sip-ua/nua/nua_dialog.c -6 +19
M ./libsofia-sip-ua/nua/nua_dialog.h +2
M ./libsofia-sip-ua/nua/nua_stack.c -6 +25

Wed Nov 21 14:10:40 EET 2007  Pekka Pessi <[EMAIL PROTECTED]>
  * test_tport.c: skipping tests on TLS if send fails. 

M ./libsofia-sip-ua/tport/test_tport.c -3 +36

Wed Jan 23 20:25:52 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  tagged 1.12.8


Wed Jan 23 20:25:46 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  tagged rel-sofia-sip_1_12_8


Wed Jan 23 20:25:42 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  * RELEASE, configure.ac: release 1.12.8

M ./RELEASE -29 +20
M ./configure.ac -1 +1

Wed Jan 23 20:22:39 EET 2008  [EMAIL PROTECTED]
  * test_nta.c: fixed memset() usage. MSG_TRUNC.

M ./libsofia-sip-ua/nta/test_nta.c -5 +5

Thu Jan 17 14:57:29 EET 2008  [EMAIL PROTECTED]
  * configure.ac: prerelease version

M ./configure.ac -1 +1

Wed Jan 23 19:11:09 EET 2008  [EMAIL PROTECTED]
  * torture_sip.c: added tests for accessing other extra headers beside 
P-Asserted-Identity/P-Preferred-Identity

M ./libsofia-sip-ua/sip/torture_sip.c +46

Wed Jan 23 18:05:58 EET 2008  [EMAIL PROTECTED]
  * nta.c: asserting in proper place when handling queue tail

M ./libsofia-sip-ua/nta/nta.c -1 +2

Wed Jan 23 18:05:23 EET 2008  [EMAIL PROTECTED]
  * nta.c: ignore tags in nta_leg_by_dialog() if they are empty strings

M ./libsofia-sip-ua/nta/nta.c -2 +5

Wed Jan 23 18:01:11 EET 2008  [EMAIL PROTECTED]
  * nta.c: now using RFC3261-compliant dialog-matching

M ./libsofia-sip-ua/nta/nta.c -32 +24
M ./libsofia-sip-ua/nta/test_nta_api.c -1 +3

Wed Jan 23 17:13:36 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  * test_tport.c: using blocking sockets in test_incomplete()

M ./libsofia-sip-ua/tport/test_tport.c -5 +6

Wed Jan 23 17:13:00 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  * torture_su.c: set blocking on

M ./libsofia-sip-ua/su/torture_su.c -1 +4

Wed Jan 23 17:11:14 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  * win32 project files: fixed slash direction

M ./win32/libsofia-sip-ua-static/libsofia_sip_ua_static.vcproj -10 +10
M ./win32/libsofia-sip-ua/libsofia_sip_ua.vcproj -18 +18
M ./win32/tests/test_htable/test_htable.vcproj -16 +16
M ./win32/tests/test_memmem/test_memmem.vcproj -16 +16
M ./win32/tests/test_nta/test_nta.vcproj -16 +16
M ./win32/tests/test_nua/test_nua.vcproj -16 +16
M ./win32/tests/test_su/test_su.vcproj -16 +16
M ./win32/tests/test_tport/test_tport.vcproj -16 +16
M ./win32/tests/torture_rbtree/torture_rbtree.vcproj -16 +16
M ./win32/tests/torture_su/torture_su.vcproj -16 +16
M ./win32/tests/torture_su_alloc/torture_su_alloc.vcproj -16 +16
M ./win32/tests/torture_su_bm/torture_su_bm.vcproj -16 +16
M ./win32/tests/torture_su_port/torture_su_port.vcproj -16 +16
M ./win32/tests/torture_su_root/torture_su_root.vcproj -16 +16
M ./win32/tests/torture_su_tag/torture_su_tag.vcproj -16 +16
M ./win32/tests/torture_su_time/torture_su_time.vcproj -16 +16
M ./win32/tests/torture_su_timer/torture_su_timer.vcproj -16 +16
M ./win32/utils/localinfo/localinfo.vcproj -16 +16
M ./win32/utils/sip_dig/sip_dig.vcproj -16 +16
M ./win32/utils/sip_options/sip_options.vcproj -16 +16
M ./win32/utils/sip_options_static/sip_options_static.vcproj -16 +16
M ./win32/utils/stunc/stunc.vcproj -16 +16

Wed Jan 23 17:07:30 EET 2008  Pekka Pessi <[EMAIL PROTECTED]>
  * soa_static.c: fixed signedness error

M ./libsofia-sip-ua/soa/soa_static.c -1 +1

Wed Jan 23 16:47:50 EET 2008  [EMAIL PROTECTED]
  * test_nta.c: fixed receiving with sink socket

M ./libsofia-sip-ua/nta/test_nta.c -63 +60

Wed Jan 23 13:56:11 EET 2008  [EMAIL PROTECTED]
  * sip_extra.c, sip_parser.c: updated documentation

M ./libsofia-sip-ua/sip/sip_extra.c -12 +51
M ./libsofia-sip-ua/sip/sip_parser.c -1 +13

Tue Jan 22 21:04:29 EET 2008  [EMAIL PROTECTED]
  * RELEASE: updated.

M ./RELEASE -15 +49

Tue Jan 22 20:59:44 EET 2008  [EMAIL PROTECTED]
  * nta.c: added NTATAG_GRAYLIST(). 
  
  Use NTATAG_GRAYLIST() as ttl value for sres_set_cached_srv_priority().

M ./libsofia-sip-ua/nta/nta.c -7 +30
M ./libsofia-sip-ua/nta/nta_internal.h +2
M ./libsofia-sip-ua/nta/nta_tag.c -1 +26
M ./libsofia-sip-ua/nta/sofia-sip/nta_tag.h +6

Tue Jan 22 20:57:38 EET 2008  [EMAIL PROTECTED]
  * sres: added ttl parameter to sres_set_cached_srv_priority() and 
sres_cache_set_srv_p

[Sofia-sip-devel] Registration/Subscription Refresh

2008-01-23 Thread Jerry Richards
Hello All,

What are the intervals that sofia-sip refreshes registrations
(nua_register())?  And Subscriptions (i.e. nua_subscribe())?

I presume it's a function of the Expires field?  The reason I'm asking is
that it does not appear consistent.

Best Regards,
Jerry


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


Re: [Sofia-sip-devel] Registration/Subscription Refresh

2008-01-23 Thread Pekka Pessi
2008/1/23, Jerry Richards <[EMAIL PROTECTED]>:
> What are the intervals that sofia-sip refreshes registrations
> (nua_register())?  And Subscriptions (i.e. nua_subscribe())?
>
> I presume it's a function of the Expires field?  The reason I'm asking is
> that it does not appear consistent.

The refresh interval is based on expires parameter in Contact for
REGISTER and in Subscription-State header for SUBSCRIBE. (If there is
none, I think Expires is used instead). The actually used refresh
interval is random, see nua_dialog_usage_set_refresh() in
nua_dialog.c.

-- 
Pekka.Pessi mail at nokia.com

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