In memory registrations not being flushed to database
-----------------------------------------------------
Key: SER-437
URL: http://tracker.iptel.org/browse/SER-437
Project: SER
Issue Type: Bug
Components: Registrar
Affects Versions: 2.0
Environment: SER 2.0.0
MySQL server version 5.1.30-community MySQL Community Server (GPL)
RedHat linux 2.6.9-78.0.13.0.1.ELsmp #1 SMP Wed Jan 14 19:37:48 EST 2009 x86_64 x86_64
Reporter: Bill McNamara
We have been seeing occasions where successful registrations coming in are not being inserted into the MySQL ser.location table.
Our ser.cfg file has 'modparam("usrloc", "db_mode",1)' and we have on average around 45 registered UA's at any given time.
We have tried sercmd usrloc.flush, but the database records are still not there.
Stopping and starting the SER process clears up the issue and the records are placed into the location table.
I might try a sercmd usrloc.delete_uid next time it happens.
The problem is intermittent as far as I can tell, it has happened to 4 different URI's in the past two weeks that we know of. I can not tell if it just started or has been happening since the server went online last year. Two of the 4 we know about had an issue with their ISP and lost their connection to the internet for an hour or so, if that helps.
Since we do not really know what is going on or causing this, we are unable to reproduce the situation.
Below are the wireshark trace of the registration and the output from sercmd usrloc.dump_file for the URI that was having the problem.
Any ideas?
Thanks,
Bill
Here is the output for the number from sercmd usrloc.dump_file:
.../Record...
...Record(0x2a982eadf0)...
domain: 'location'
uid : '19202271666(a)proxy1.connectmevoice.com'
~~~Contact(0x2a982eae88)~~~
domain : 'location'
uid : '19202271666(a)proxy1.connectmevoice.com'
aor : 'sip:19202271666@proxy1.connectmevoice.com'
Contact : 'sip:19202271666@192.168.1.101:39424'
Expires : 83
q :
Call-ID : '2063884751-39424-1(a)192.168.1.101'
CSeq : 6728
User-Agent: 'Grandstream HT-502 V1.1C 1.0.1.41'
received : 'sip:75.86.180.55:49101;dstip=66.29.74.34;dstport=5060'
instance : '<urn:uuid:00000000-0000-1000-8000-000B821F70BE>'
State : CS_SYNC
Flags : 1
Sock : 0x5f34a8
next : (nil)
prev : (nil)
~~~/Contact~~~~
Here is the wireshark trace of the registration:
Session Initiation Protocol
Request-Line: REGISTER sip:proxy1.connectmevoice.com SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.1.101:39424;branch=z9hG4bK98094499;rport
Route: <sip:proxy1.connectmevoice.com:5060;lr>
From: <sip:19202271666@proxy1.connectmevoice.com>;tag=1051201288
SIP from address: sip:19202271666@proxy1.connectmevoice.com
SIP tag: 1051201288
To: <sip:19202271666@proxy1.connectmevoice.com>
SIP to address: sip:19202271666@proxy1.connectmevoice.com
Call-ID: 2063884751-39424-1(a)192.168.1.101
CSeq: 6725 REGISTER
Contact: <sip:19202271666@192.168.1.101:39424>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F70BE>"
Contact Binding: <sip:19202271666@192.168.1.101:39424>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F70BE>"
Authorization: Digest username="19202271666", realm="66.29.74.34", nonce="4afaab487973eff84b22056a4f9ebc106db41066", uri="sip:proxy1.connectmevoice.com", response="ebabc75cc2c225bfb65c5a295d0d47ce", algorithm=MD5
Authentication Scheme: Digest
Username: "19202271666"
Realm: "66.29.74.34"
Nonce Value: "4afaab487973eff84b22056a4f9ebc106db41066"
Authentication URI: "sip:proxy1.connectmevoice.com"
Digest Authentication Response: "ebabc75cc2c225bfb65c5a295d0d47ce"
Algorithm: MD5
Max-Forwards: 70
User-Agent: Grandstream HT-502 V1.1C 1.0.1.41
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0
Session Initiation Protocol
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 192.168.1.101:39424;branch=z9hG4bK98094499;rport=49056;received=75.86.180.55
From: <sip:19202271666@proxy1.connectmevoice.com>;tag=1051201288
SIP from address: sip:19202271666@proxy1.connectmevoice.com
SIP tag: 1051201288
To: <sip:19202271666@proxy1.connectmevoice.com>;tag=db5ed27b68106b9f580ea17ae7c95a75.6d09
SIP to address: sip:19202271666@proxy1.connectmevoice.com
SIP tag: db5ed27b68106b9f580ea17ae7c95a75.6d09
Call-ID: 2063884751-39424-1(a)192.168.1.101
CSeq: 6725 REGISTER
Expires: 600
Min-Expires: 240
WWW-Authenticate: Digest realm="66.29.74.34", nonce="4afaad8c58152b3cf117e5ccc933b6edcf782e5a", stale=true
Authentication Scheme: Digest
Realm: "66.29.74.34"
Nonce Value: "4afaad8c58152b3cf117e5ccc933b6edcf782e5a"
Stale Flag: true
Server: Sip EXpress router (2.0.0 (x86_64/linux))
Content-Length: 0
Warning: 392 66.29.74.34:5060 "Noisy feedback tells: pid=23609 req_src_ip=75.86.180.55 req_src_port=49056 in_uri=sip:proxy1.connectmevoice.comout_uri=sip:proxy1.connectmevoice.com via_cnt==1"
Session Initiation Protocol
Request-Line: REGISTER sip:proxy1.connectmevoice.com SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.1.101:39424;branch=z9hG4bK897800051;rport
Route: <sip:proxy1.connectmevoice.com:5060;lr>
From: <sip:19202271666@proxy1.connectmevoice.com>;tag=1051201288
SIP from address: sip:19202271666@proxy1.connectmevoice.com
SIP tag: 1051201288
To: <sip:19202271666@proxy1.connectmevoice.com>
SIP to address: sip:19202271666@proxy1.connectmevoice.com
Call-ID: 2063884751-39424-1(a)192.168.1.101
CSeq: 6726 REGISTER
Contact: <sip:19202271666@192.168.1.101:39424>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F70BE>"
Contact Binding: <sip:19202271666@192.168.1.101:39424>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F70BE>"
Authorization: Digest username="19202271666", realm="66.29.74.34", nonce="4afaad8c58152b3cf117e5ccc933b6edcf782e5a", uri="sip:proxy1.connectmevoice.com", response="a7e984a4c4746562efa8869c3cdaf3a2", algorithm=MD5
Authentication Scheme: Digest
Username: "19202271666"
Realm: "66.29.74.34"
Nonce Value: "4afaad8c58152b3cf117e5ccc933b6edcf782e5a"
Authentication URI: "sip:proxy1.connectmevoice.com"
Digest Authentication Response: "a7e984a4c4746562efa8869c3cdaf3a2"
Algorithm: MD5
Max-Forwards: 70
User-Agent: Grandstream HT-502 V1.1C 1.0.1.41
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.168.1.101:39424;branch=z9hG4bK897800051;rport=49056;received=75.86.180.55
From: <sip:19202271666@proxy1.connectmevoice.com>;tag=1051201288
SIP from address: sip:19202271666@proxy1.connectmevoice.com
SIP tag: 1051201288
To: <sip:19202271666@proxy1.connectmevoice.com>;tag=db5ed27b68106b9f580ea17ae7c95a75.a660
SIP to address: sip:19202271666@proxy1.connectmevoice.com
SIP tag: db5ed27b68106b9f580ea17ae7c95a75.a660
Call-ID: 2063884751-39424-1(a)192.168.1.101
CSeq: 6726 REGISTER
Expires: 600
Min-Expires: 240
Contact: <sip:19202271666@192.168.1.101:39424>;expires=600;received="sip:75.86.180.55:49056;dstip=66.29.74.34;dstport=5060"
Contact Binding: <sip:19202271666@192.168.1.101:39424>;expires=600;received="sip:75.86.180.55:49056;dstip=66.29.74.34;dstport=5060"
Server: Sip EXpress router (2.0.0 (x86_64/linux))
Content-Length: 0
Warning: 392 66.29.74.34:5060 "Noisy feedback tells: pid=23604 req_src_ip=75.86.180.55 req_src_port=49056 in_uri=sip:proxy1.connectmevoice.comout_uri=sip:proxy1.connectmevoice.com via_cnt==1"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.iptel.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
is there a flag that i can set before calling t_relay that causes
t_relay not to try to create a new tcp connection to the destination if
one does not already exist? this would be handy when t_relaying to
registered tcp contacts.
-- juha
while writing rr_count function, i noticed that after calling
if (parse_headers(msg, HDR_EOH_F, 0) == -1) {
when then going trough the headers of list msg->record_route, that list
contained also other than rr headers. so i need to test the header type
like this:
header = msg->record_route;
while (header) {
if (header->type == HDR_RECORDROUTE_T) {
why is that, i.e., why does parse_headers add other that rr headers to
msg->record_route list? i imagined that when all headers are parsed,
each header is added only to its own list and nowhere else.
-- juha
i wrote alias_contact() function and seems to work fine. i have not
yet written handle_alias(), but tried to first use scripting means for
that. that led into trouble with testing is $var has value.
i have this piece of code:
xlog("L_INFO", "R-URI is <$ru>\n");
$var(tmp) = $(ru{uri.param,alias});
xlog("L_INFO", "Alias param is <$var(tmp)>\n");
if ($var(tmp)) {
xlog("L_INFO", "Alias param is <$var(tmp)>\n");
$du = $var(tmp);
xlog("L_INFO", "Routing in-dialog $rm from <$fu> to <$du>\n");
} else {
xlog("L_INFO", "Routing in-dialog $rm from <$fu> to <$ru>\n");
}
and i get to syslog:
Nov 8 12:51:10 localhost /usr/sbin/sip-proxy[4506]: INFO: R-URI is <sip:jh_test_fi@192.98.101.10:5074;transport=tcp;alias="192.98.101.10:55375;transport=tcp">
Nov 8 12:51:10 localhost /usr/sbin/sip-proxy[4506]: INFO: Alias param is <192.98.101.10:55375;transport=tcp>
Nov 8 12:51:10 localhost /usr/sbin/sip-proxy[4506]: INFO: Routing in-dialog BYE from <sip:test@as.test.fi> to <sip:jh_test_fi@192.98.101.10:5074;transport=tcp;alias="192.98.101.10:55375;transport=tcp">
why does the test
if ($var(tmp)) {
fail to figure out that $var(tmp) has value?
-- juha
Module: sip-router
Branch: sr_3.0
Commit: c744f71c858f34d41741d90e0d5cb05e48cf8016
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c744f71…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Mon Nov 16 19:41:02 2009 +0100
script engine: verbose conversion-to-int errors
- more verbose errors (all of them contain now the config file
position for the error).
- integer conversion errors will now by default log a warning
message. Like before they won't cause the expression evaluation
to fail, they'll just evaluate the failed conversion to 0.
The behaviour can be changed using the defines at the top of
rvalue.c. To restore the old behaviour (no int conversion error
message and error ignored), comment out the following defines:
RV_STR2INT_VERBOSE_ERR, RV_STRINT_ERR, EVAL_GET_INT_ERR_WARN,
RVAL_GET_INT_ERR_IGN. For more info see the comments in the
file.
---
lvalue.c | 4 +-
rvalue.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 193 insertions(+), 41 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=c74…
Bugs item #2892560, was opened at 2009-11-05 13:18
Message generated for change (Settings changed) made by axlh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2892560&group_…
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: core
Group: ver 1.4.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent $rP contents
Initial Comment:
The $rP (request-uri's transport) is broken. When $ru is set with a ";transport=XXX" parameter, the contents of $rP show the entire parameter instead of its parsed value.
The following config snippet:
$ru = 'sip:123@invalid';
TRACE("Transport=[$rP]");
$ru = 'sip:123@invalid;transport=udp';
TRACE("Transport=[$rP]");
$ru = 'sip:123@invalid;transport=tcp';
TRACE("Transport=[$rP]");
creates the following log:
Nov 5 13:14:26 Transport=[UDP]
Nov 5 13:14:26 Transport=[transport=udp]
Nov 5 13:14:26 Transport=[transport=tcp]
Expected would be:
Nov 5 13:14:26 Transport=[UDP]
Nov 5 13:14:26 Transport=[UDP]
Nov 5 13:14:26 Transport=[TCP]
----------------------------------------------------------------------
>Comment By: Alex Hermann (axlh)
Date: 2009-11-10 17:09
Message:
It is ok now, thanks for the quick fix.
(SF is getting worse by the day. Now it is impossible to see comments....)
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-11-06 14:01
Message:
Should be fixed on 1.4, 1.5 and 3.0 (git), please test and let me know if
is ok. Thanks.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2892560&group_…
Bugs item #2897594, was opened at 2009-11-14 09:14
Message generated for change (Comment added) made by miconda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2897594&group_…
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: modules
Group: ver devel
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Mangust (mangust2)
>Assigned to: Daniel-Constantin Mierla (miconda)
Summary: uac_auth does't work in 3.0
Initial Comment:
in file modules_k/uac/auth.c
line 235:
for( hdr=rpl->headers ; hdr ; hdr=hdr->next )
{
// -->> if ( hdr->type!=HDR_OTHER_T)
// -->> continue;
if (cmp_hdrname_str(&hdr->name, &hdr_name)==0)
return hdr;
}
commented out line prevent from recognizing authentication field causing error.
Nov 14 04:02:28 v /usr/local/sbin/kamailio[24361]: ERROR: uac [auth.c:244]: reply has no auth hdr (WWW-Authenticate)
Nov 14 04:02:28 v /usr/local/sbin/kamailio[24361]: ERROR: uac [auth.c:419]: failed to extract authenticate hdr
maybe because authentication now not HDR_OTHER_T but
HDR_WWW_AUTHENTICATE_T /* WWW-Authenticate header field */,
HDR_PROXY_AUTHENTICATE_T /* Proxy-Authenticate header field */,
according to:
http://www.asipto.com/pub/kamailio-devel-guide/
for a moment i just comment it out
will also try:
if ( hdr->type!=HDR_WWW_AUTHENTICATE_T && hdr->type!=HDR_PROXY_AUTHENTICATE_T )
continue;
if (cmp_hdrname_str(&hdr->name, &hdr_name)==0)
return hdr;
----------------------------------------------------------------------
>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-11-16 14:21
Message:
OK. Thanks for testing!
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-16 14:13
Message:
I seen changes was made in code on GIT. I approve that authentication now
works.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-11-15 06:18
Message:
Your patch seems ok, I will double check and fix. Thanks!
----------------------------------------------------------------------
Comment By: Mangust (mangust2)
Date: 2009-11-14 09:26
Message:
A! it happen because before in v1.5 ./parser/hf.h
/**
* SIP Header types.
* if you add a new type:
* - make sure it's not greater than 63
* - make sure you add the corresponding flag to the hdr_flags_t defs
below
* - update clean_hdr_field (in hf.c)
* - update sip_msg_cloner (modules/tm/sip_msg.c)
* - update parse_headers (msg_parser.c)
*/
enum _hdr_types_t {
HDR_ERROR_T = -1 /**< Error while parsing */,
HDR_OTHER_T = 0 /**< Some other header field */,
HDR_VIA_T = 1 /**< Via header field */,
HDR_VIA1_T = 1 /**< First Via header field */,
HDR_VIA2_T = 2 /**< only used as flag */,
HDR_TO_T /**< To header field */,
HDR_FROM_T /**< From header field */,
HDR_CSEQ_T /**< CSeq header field */,
HDR_CALLID_T /**< Call-Id header field */,
HDR_CONTACT_T /**< Contact header field */,
HDR_MAXFORWARDS_T /**< MaxForwards header field */,
HDR_ROUTE_T /**< Route header field */,
HDR_RECORDROUTE_T /**< Record-Route header field */,
HDR_PATH_T /**< Path header fiels */,
HDR_CONTENTTYPE_T /**< Content-Type header field */,
HDR_CONTENTLENGTH_T /**< Content-Length header field */,
HDR_AUTHORIZATION_T /**< Authorization header field */,
HDR_EXPIRES_T /**< Expires header field */,
HDR_PROXYAUTH_T /**< Proxy-Authorization hdr field */,
HDR_SUPPORTED_T /**< Supported header field */,
HDR_PROXYREQUIRE_T /**< Proxy-Require header field */,
HDR_UNSUPPORTED_T /**< Unsupported header field */,
HDR_ALLOW_T /**< Allow header field */,
HDR_EVENT_T /**< Event header field */,
HDR_ACCEPT_T /**< Accept header field */,
HDR_ACCEPTLANGUAGE_T /**< Accept-Language header field */,
HDR_ORGANIZATION_T /**< Organization header field */,
HDR_PRIORITY_T /**< Priority header field */,
HDR_SUBJECT_T /**< Subject header field */,
HDR_USERAGENT_T /**< User-Agent header field */,
HDR_ACCEPTDISPOSITION_T /**< Accept-Disposition hdr field */,
HDR_CONTENTDISPOSITION_T /**< Content-Disposition hdr field */,
HDR_DIVERSION_T /**< Diversion header field */,
HDR_RPID_T /**< Remote-Party-ID header field */,
HDR_REFER_TO_T /**< Refer-To header fiels */,
HDR_SESSION_EXPIRES_T /**< Session-Expires header field */,
HDR_MIN_SE_T /**< Min-SE header field */,
HDR_PPI_T /**< P-Preferred-Identity header field */,
HDR_PAI_T /**< P-Asserted-Identity header field */,
HDR_PRIVACY_T /**< Privacy header field */,
HDR_RETRY_AFTER_T /**< Retry-After header field */,
HDR_EOH_T /**< Some other header field */
};
Was NO HDR_WWW_AUTHENTICATE_T or HDR_PROXY_AUTHENTICATE_T so authenticate
header was matching HDR_OTHER_T
----------------------------------------------------------------------
Comment By: Mangust (mangust2)
Date: 2009-11-14 09:20
Message:
yes, this work as well:
for( hdr=rpl->headers ; hdr ; hdr=hdr->next )
{
if ( hdr->type!=HDR_WWW_AUTHENTICATE_T &&
hdr->type!=HDR_PROXY_AUTHENTICATE_T )
continue;
if (cmp_hdrname_str(&hdr->name, &hdr_name)==0)
return hdr;
}
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2897594&group_…
Bugs item #2897594, was opened at 2009-11-14 07:14
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2897594&group_…
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: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mangust (mangust2)
Assigned to: Nobody/Anonymous (nobody)
Summary: uac_auth does't work in 3.0
Initial Comment:
in file modules_k/uac/auth.c
line 235:
for( hdr=rpl->headers ; hdr ; hdr=hdr->next )
{
// -->> if ( hdr->type!=HDR_OTHER_T)
// -->> continue;
if (cmp_hdrname_str(&hdr->name, &hdr_name)==0)
return hdr;
}
commented out line prevent from recognizing authentication field causing error.
Nov 14 04:02:28 v /usr/local/sbin/kamailio[24361]: ERROR: uac [auth.c:244]: reply has no auth hdr (WWW-Authenticate)
Nov 14 04:02:28 v /usr/local/sbin/kamailio[24361]: ERROR: uac [auth.c:419]: failed to extract authenticate hdr
maybe because authentication now not HDR_OTHER_T but
HDR_WWW_AUTHENTICATE_T /* WWW-Authenticate header field */,
HDR_PROXY_AUTHENTICATE_T /* Proxy-Authenticate header field */,
according to:
http://www.asipto.com/pub/kamailio-devel-guide/
for a moment i just comment it out
will also try:
if ( hdr->type!=HDR_WWW_AUTHENTICATE_T && hdr->type!=HDR_PROXY_AUTHENTICATE_T )
continue;
if (cmp_hdrname_str(&hdr->name, &hdr_name)==0)
return hdr;
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-16 12:13
Message:
I seen changes was made in code on GIT. I approve that authentication now
works.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-11-15 04:18
Message:
Your patch seems ok, I will double check and fix. Thanks!
----------------------------------------------------------------------
Comment By: Mangust (mangust2)
Date: 2009-11-14 07:26
Message:
A! it happen because before in v1.5 ./parser/hf.h
/**
* SIP Header types.
* if you add a new type:
* - make sure it's not greater than 63
* - make sure you add the corresponding flag to the hdr_flags_t defs
below
* - update clean_hdr_field (in hf.c)
* - update sip_msg_cloner (modules/tm/sip_msg.c)
* - update parse_headers (msg_parser.c)
*/
enum _hdr_types_t {
HDR_ERROR_T = -1 /**< Error while parsing */,
HDR_OTHER_T = 0 /**< Some other header field */,
HDR_VIA_T = 1 /**< Via header field */,
HDR_VIA1_T = 1 /**< First Via header field */,
HDR_VIA2_T = 2 /**< only used as flag */,
HDR_TO_T /**< To header field */,
HDR_FROM_T /**< From header field */,
HDR_CSEQ_T /**< CSeq header field */,
HDR_CALLID_T /**< Call-Id header field */,
HDR_CONTACT_T /**< Contact header field */,
HDR_MAXFORWARDS_T /**< MaxForwards header field */,
HDR_ROUTE_T /**< Route header field */,
HDR_RECORDROUTE_T /**< Record-Route header field */,
HDR_PATH_T /**< Path header fiels */,
HDR_CONTENTTYPE_T /**< Content-Type header field */,
HDR_CONTENTLENGTH_T /**< Content-Length header field */,
HDR_AUTHORIZATION_T /**< Authorization header field */,
HDR_EXPIRES_T /**< Expires header field */,
HDR_PROXYAUTH_T /**< Proxy-Authorization hdr field */,
HDR_SUPPORTED_T /**< Supported header field */,
HDR_PROXYREQUIRE_T /**< Proxy-Require header field */,
HDR_UNSUPPORTED_T /**< Unsupported header field */,
HDR_ALLOW_T /**< Allow header field */,
HDR_EVENT_T /**< Event header field */,
HDR_ACCEPT_T /**< Accept header field */,
HDR_ACCEPTLANGUAGE_T /**< Accept-Language header field */,
HDR_ORGANIZATION_T /**< Organization header field */,
HDR_PRIORITY_T /**< Priority header field */,
HDR_SUBJECT_T /**< Subject header field */,
HDR_USERAGENT_T /**< User-Agent header field */,
HDR_ACCEPTDISPOSITION_T /**< Accept-Disposition hdr field */,
HDR_CONTENTDISPOSITION_T /**< Content-Disposition hdr field */,
HDR_DIVERSION_T /**< Diversion header field */,
HDR_RPID_T /**< Remote-Party-ID header field */,
HDR_REFER_TO_T /**< Refer-To header fiels */,
HDR_SESSION_EXPIRES_T /**< Session-Expires header field */,
HDR_MIN_SE_T /**< Min-SE header field */,
HDR_PPI_T /**< P-Preferred-Identity header field */,
HDR_PAI_T /**< P-Asserted-Identity header field */,
HDR_PRIVACY_T /**< Privacy header field */,
HDR_RETRY_AFTER_T /**< Retry-After header field */,
HDR_EOH_T /**< Some other header field */
};
Was NO HDR_WWW_AUTHENTICATE_T or HDR_PROXY_AUTHENTICATE_T so authenticate
header was matching HDR_OTHER_T
----------------------------------------------------------------------
Comment By: Mangust (mangust2)
Date: 2009-11-14 07:20
Message:
yes, this work as well:
for( hdr=rpl->headers ; hdr ; hdr=hdr->next )
{
if ( hdr->type!=HDR_WWW_AUTHENTICATE_T &&
hdr->type!=HDR_PROXY_AUTHENTICATE_T )
continue;
if (cmp_hdrname_str(&hdr->name, &hdr_name)==0)
return hdr;
}
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2897594&group_…