Hi Stefano, that's interesting one of my proxies is also an Alcatel OmniPCX, but since my OpenSER ignore the qop it's working fine the OXE accept the new INVITE without qop=auth. Your INVITE with authentication information is the same as my and seems to be ok. My OmniPCX is an OXE R7.1
It's easy to add the qop=auth static for OpenSER by this way:
/* #define ALGORITHM_FIELD_S "algorithm="MD5"" */ #define ALGORITHM_FIELD_S "algorithm="MD5", qop=auth"
but it is NOT successful with OmniPCX, because "cnonce" and "nc" are still missing, but they are mandatory if qop is used ;-(
p.s.: the double quotes are used only in the 401/407 message from the server (qop="auth") in the INVITE with Authenticated Request it must used without (qop=auth)
regards, Andreas
Stefano Capitanio schrieb:
Hello,
i'm sure that the recompiled module is running :-( what happens is that OpenSER answer to the 407 message with a new INVITE containing authentication information (and this is right) but the other server (an Alcatel OmniPCX) doesn't like it and answer with another 407. maybe it's because OpenSER doesn't insert in the "Proxy-Authorization" Header the qop="auth" parameter? username and password are set correctly and i use static credential in openser.
here are the interesting messages (193.205.139.139 is OpenSER, i've skipped ACK and Trying messages):
U 193.205.139.139:5060 -> 172.16.2.10:5060 *INVITE* sip:2294@172.16.2.10:5060 SIP/2.0. Record-Route: sip:193.205.139.139;lr=on;ftag=1583161212. Via: SIP/2.0/UDP 193.205.139.139;branch=z9hG4bK16d1.3552d5a7.0. Via: SIP/2.0/UDP 193.205.218.107:5060;rport=5060;branch=z9hG4bK3C00C0185E8A4E4584E24BF53D8D552E.
From: 089 sip:089@193.205.139.139;tag=1583161212. To: sip:2294@193.205.139.139. Contact: sip:089@193.205.218.107:5060. Call-ID: 5AD06AF6-9A37-4099-B5F3-58DCD21009F7@193.204.7.58. CSeq: 23670 INVITE. Max-Forwards: 69. Content-Type: application/sdp. User-Agent: X-Lite release 1105x. Content-Length: 309. . v=0. o=089 1687151 1687164 IN IP4 193.205.218.107. s=X-Lite. c=IN IP4 193.205.139.139. t=0 0. m=audio 50240 RTP/AVP 0 8 3 98 97 101. a=rtpmap:0 pcmu/8000. a=rtpmap:8 pcma/8000. a=rtpmap:3 gsm/8000. a=rtpmap:98 iLBC/8000. a=rtpmap:97 speex/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv.
U 172.16.2.10:65471 -> 193.205.139.139:5060 *SIP/2.0 407 Proxy Authentication Required.* Proxy-Authenticate: Digest qop="auth",nonce="753d3031565dc070588bc6723fba3dae",realm="172.16.2.10". To: sip:2294@193.205.139.139;tag=aabbc0f292583150372f16081d1513a4. From: 089 sip:089@193.205.139.139;tag=1583161212. Call-ID: 5AD06AF6-9A37-4099-B5F3-58DCD21009F7@193.204.7.58. CSeq: 23670 INVITE. Via: SIP/2.0/UDP 193.205.139.139;branch=z9hG4bK16d1.3552d5a7.0. Via: SIP/2.0/UDP 193.205.218.107:5060;rport=5060;branch=z9hG4bK3C00C0185E8A4E4584E24BF53D8D552E.
Content-Length: 0.
U 193.205.139.139:5060 -> 172.16.2.10:5060 *INVITE* sip:2294@172.16.2.10:5060 SIP/2.0. Record-Route: sip:193.205.139.139;lr=on;ftag=1583161212. Via: SIP/2.0/UDP 193.205.139.139;branch=z9hG4bK16d1.3552d5a7.1. Via: SIP/2.0/UDP 193.205.218.107:5060;rport=5060;branch=z9hG4bK3C00C0185E8A4E4584E24BF53D8D552E.
From: 089 sip:089@193.205.139.139;tag=1583161212. To: sip:2294@193.205.139.139. Contact: sip:089@193.205.218.107:5060. Call-ID: 5AD06AF6-9A37-4099-B5F3-58DCD21009F7@193.204.7.58. CSeq: 23670 INVITE. Max-Forwards: 69. Content-Type: application/sdp. User-Agent: X-Lite release 1105x. Content-Length: 309. Proxy-Authorization: Digest username="xxxxxxx", realm="172.16.2.10", nonce="753d3031565dc070588bc6723fba3dae", uri="sip:2294@172.16.2.10:5060", response="0f2d0fe3296f6c93f9f6fd4a05206567", algorithm="MD5". . v=0. o=089 1687151 1687164 IN IP4 193.205.218.107. s=X-Lite. c=IN IP4 193.205.139.139. t=0 0. m=audio 50240 RTP/AVP 0 8 3 98 97 101. a=rtpmap:0 pcmu/8000. a=rtpmap:8 pcma/8000. a=rtpmap:3 gsm/8000. a=rtpmap:98 iLBC/8000. a=rtpmap:97 speex/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv.
U 172.16.2.10:65471 -> 193.205.139.139:5060 *SIP/2.0 407 Proxy Authentication Required.* Proxy-Authenticate: Digest qop="auth",nonce="753d3031565dc070588bc6723fba3dae",realm="172.16.2.10". To: sip:2294@193.205.139.139;tag=50234ce96a2fb0581f63689873e105f0. From: 089 sip:089@193.205.139.139;tag=1583161212. Call-ID: 5AD06AF6-9A37-4099-B5F3-58DCD21009F7@193.204.7.58. CSeq: 23670 INVITE. Via: SIP/2.0/UDP 193.205.139.139;branch=z9hG4bK16d1.3552d5a7.1. Via: SIP/2.0/UDP 193.205.218.107:5060;rport=5060;branch=z9hG4bK3C00C0185E8A4E4584E24BF53D8D552E.
Content-Length: 0.
*thank you very much for your help!* Stefano
Andreas Heise ha scritto:
Hello, are you sure the your recompiled uac modul is running instead the old one ? Try to add a debug line like following to be sure....
case QOP_STATE: /* TODO - add qop support */ LOG(L_WARN,"INFO: qop detected and ignored ;-) \n"); break;
what happens exactly? Tried your OpenSER to send a new INVITE with PA header or is the 407 was relayed to the caller? A ngrep trace would be helpful
regards, Andreas
Stefano Capitanio schrieb:
Hi,
i have the same problem authenticating with a server that respond with qop="auth". i modified auth_hdr.c: case QOP_STATE: /* TODO - add qop support */ break;
then i recompiled the module with make modules=modules/uac modules and copied "uac.so" to /usr/local/lib/openser/modules/uac.so and restarted openser
but it doesn't work! I've tried also with: case QOP_STATE: /* TODO - add qop support */ auth->qop = val; break;
have I made any mistake?
thanks for your help, Stefano
Andreas Heise ha scritto:
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: noqop 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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users