sr-dev

sr-dev@lists.kamailio.org

17 participants
44270 discussions

[Kamailio] Why is the nonce expiry checked so late?

by Alex Hermann

Hello, Why is the nonce expiry checked in post_auth instead of pre_auth? Now the expiry is checked after the username/password is checked against the DB. That seems a bit odd. I moved the check to check_nonce (which is called from pre_auth) and it seems to work fine. Did I miss something? Security issue? -- Greetings, Alex Hermann

15 years, 2 months

SF.net SVN: openser:[5956] branches/1.5/modules/utils/conf.c

by Marius Zbihlei

Revision: 5956 http://openser.svn.sourceforge.net/openser/?rev=5956&view=rev Author: mariuszbihlei Date: 2009-11-17 16:02:06 +0000 (Tue, 17 Nov 2009) Log Message: ----------- Added fix http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4fed4c7… to kamailio (problems where when the string was in the form of "0=on\n\0" ; this function caused a segmentation fault(canaries where overwritten). ) Modified Paths: -------------- branches/1.5/modules/utils/conf.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

15 years, 2 months

[Tracker] Created: (SER-437) In memory registrations not being flushed to database

by Bill McNamara (JIRA)

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.com out_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.com out_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

15 years, 2 months

flag for not trying to create a new tcp connection?

by jh＠tutpro.com

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

15 years, 2 months

parse_headers question

by jh＠tutpro.com

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

15 years, 2 months

trouble with testing $var

by jh＠tutpro.com

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

15 years, 2 months

git:sr_3.0: script engine: verbose conversion-to-int errors

by Andrei Pelinescu-Onciul

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…

15 years, 2 months

[ openser-Bugs-2892560 ] Inconsistent $rP contents

by SourceForge.net

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_…

15 years, 2 months

[ openser-Bugs-2897594 ] uac_auth does't work in 3.0

by SourceForge.net

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_…

15 years, 2 months

[ openser-Bugs-2897594 ] uac_auth does't work in 3.0

by SourceForge.net

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_…

15 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev