case QOP_STATE: /* TODO - add qop support */ LOG(L_ERR,"ERROR:uac:parse_authenticate_body: no qop support " "for the moment :-(\n"); goto error; auth->qop = val; break;

case QOP_STATE: /* TODO - add qop support */ break;

modparam("uac","ignore_qop",1);

Hello, since a lot of providers has change there authentication to qop="auth" the uac_auth(); function of the uac module can't use anymore. by google I found a lot of requests for qop with uac_auth and also the official feature request 1345887. Is a target date known for a solution, maybe it's possible with 1.2.0? Feature Request [ 1345887 ] Implement qop functionality in uac module p.s.: I know it's on the road map, but it is needed so often...... thanks. Andreas

Thomas Gelf schrieb: > Same problem here. As I make intensive use of uac_auth() and need to > authenticate against Proxies sending me the qop parameter in their > authentication challenge, in the meantime I helped myself by simply > commenting out the "goto error" section in modules/uac/auth_hdr.c. > > I just changed > >> case QOP_STATE: >> /* TODO - add qop support */ >> LOG(L_ERR,"ERROR:uac:parse_authenticate_body: no >> qop support " >> "for the moment :-(\n"); >> goto error; >> auth->qop = val; >> break; > > to > >> case QOP_STATE: >> /* TODO - add qop support */ >> break; > > somewhere around line 215. > I already used this "fix" to ignore the qop value and from my opinion it should be OK if qop=auth, because the result of the digest should be the same for qop = "auth" or unspecified see page 14 in the following draft of an example http://www.softarmor.com/wgdb/docs/draft-smith-sip-auth-examples-00.txt but! by this way the Authenticated Request from OpenSER does not contains qop="auth" in the response which is maybe a problem for some gateways. > Sure, that's not the way things should be solved - but at the moment > it fits my needs. And as of RFC 2617 I should be fine - not sure > about > RFC3261. Section 22.4(.8) states that "the 'qop' parameter must > unfor- > tunately remain optional for clients and servers to receive" - so imo > it should be ok. (?) > > To be sincere I did never REALLY understand this whole qop thingy. > Afaik > OpenSER isn't able to increment cseq in it's UAC module as this > module > doesn't have any dialog support. And in my believes that's why the > UAC > module has been designed to fail if it recieves a challenge > containing > qop (because it isn't able to do it the right way). > I believe that the fail is wanted to be able to forward the 401|407 to the calling client which is maybe able to answer a challenge which contains qop > Nonetheless with my little "patch" everything "just works": > > -> UAC module sends an INVITE request > -> remote sends it's 407 message, containing nonce and qop (but no > cnonce) > -> 407 gets acknowledged > -> UAC module ignores the qop (as error handling is commented out) > and > sends a new INVITE request with the correct nonce (and is > therefore > doing correct digest authentication) but with wrong cseq (eg same > cseq as previous INVITE = cseq supplied from client) but the response does not contains the chosen qop value > -> remote party (proxy asking for authentication) accepts my INVITE > > I'm doing so since AVP support has been added to uac_auth() - see > also > http://www.openser.org/pipermail/devel/2006-March/002162.html and it > worked fine with all versions of OpenSER I compiled since this date. > > It would be great if (unless cseq incrementation support will once be > added to UAC) upstream sources could comment out this section (as I > showed above). > > I don't see any grave issues in doing so - and it would probably help > people who need this feature. Would such a modification be an > option for > OpenSER 1.2? You could also add an optional swich like > > > modparam("uac","ignore_qop",1); > I think we can save the time to build a modparam, this time could be better used for a final solution, because it's still not working with qoq="auth-int" or qop="auth-int, auth" and if it's really needed everybody can uncomment and compile it self. I found an answer from Bogdan in the devel list that the cseq and qop limits will not be removed with 1.2 http://www.mail-archive.com/devel@openser.org/msg04951.html but I hope in the next roadmap for 1.3 it can be changed for optional to todo to get this feature...... > Please let me know if you like my proposal or if I'm talking > bullshit :) no it's not bullshit ;-) as the problem is really old....... regards, Andreas > > Kind regards, > Thomas Gelf > > > Andreas Heise schrieb: >> >> Hello, >> since a lot of providers has change there authentication to >> qop="auth" >> the uac_auth(); function of the uac module can't use anymore. >> >> by google I found a lot of requests for qop with uac_auth and also >> the official feature request 1345887. >> Is a target date known for a solution, maybe it's possible with >> 1.2.0? >> >> Feature Request [ 1345887 ] Implement qop functionality in uac >> module >> >> p.s.: I know it's on the road map, but it is needed so often...... >> >> thanks. >> Andreas >> > > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

case QOP_STATE: /* TODO - add qop support */ LOG(L_ERR,"ERROR:uac:parse_authenticate_body: no qop support " "for the moment :-(\n"); goto error; auth->qop = val; break;

case QOP_STATE: /* TODO - add qop support */ break;

modparam("uac","ignore_qop",1);

Hello, since a lot of providers has change there authentication to qop="auth" the uac_auth(); function of the uac module can't use anymore. by google I found a lot of requests for qop with uac_auth and also the official feature request 1345887. Is a target date known for a solution, maybe it's possible with 1.2.0? Feature Request [ 1345887 ] Implement qop functionality in uac module p.s.: I know it's on the road map, but it is needed so often...... thanks. Andreas