Hi Brett, Auth is definately being done on the INVITE as well, but once again, this succeeds even though it has another @domain part.
I know it all looks right, the problem is, OpenSIPS is even storing the location data as username [at] domain [dot] com [at] domain [dot] com. And I can't rely on using the Auth ID for billing as a lot of other correctly configured clients are using Digest username="doug",realm="domain.com". I guess I'd have to put the two vars together, $au and $ar (or $ad) and then if $au contains a domain name, just to strip it off or something? As requested, trace follows: IP: 1.2.3.4 is the client IP: 5.6.7.8 is the OpenSIPS proxy T 1.2.3.4:62689 -> 5.6.7.8:5060 [AP] INVITE sip:[email protected] SIP/2.0. Via: SIP/2.0/TCP 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:doug%[email protected]:62689;transport=TCP>. To: <sip:[email protected]>. From: <sip:doug%[email protected]>;tag=1b164627. Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU.. CSeq: 1 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. User-Agent: X-Lite Beta release 4.0 v3 stamp 55153. Content-Length: 188. . v=0. o=- 7 2 IN IP4 192.168.0.113. s=CounterPath X-Lite 4.0. c=IN IP4 1.2.3.4. t=0 0. m=audio 58262 RTP/AVP 0 8 3 101. a=sendrecv. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. # T 5.6.7.8:5060 -> 1.2.3.4:62689 [AP] SIP/2.0 100 Trying. Via: SIP/2.0/TCP 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport=62689. To: <sip:[email protected]>. From: <sip:doug%[email protected]>;tag=1b164627. Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU.. CSeq: 1 INVITE. Server: OpenSIPS (1.6.1-tls (x86_64/linux)). Content-Length: 0. . # T 5.6.7.8:5060 -> 1.2.3.4:62689 [AP] SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/TCP 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport=62689. To: <sip:[email protected]>;tag=cdff758d742c799b04c91123cd1608d5.fdd1. From: <sip:doug%[email protected]>;tag=1b164627. Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU.. CSeq: 1 INVITE. Proxy-Authenticate: Digest realm="domain.com", nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648". Server: OpenSIPS (1.6.1-tls (x86_64/linux)). Content-Length: 0. . ### T 1.2.3.4:62689 -> 5.6.7.8:5060 [AP] ACK sip:[email protected] SIP/2.0. Via: SIP/2.0/TCP 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport. Max-Forwards: 70. To: <sip:[email protected]>;tag=cdff758d742c799b04c91123cd1608d5.fdd1. From: <sip:doug%[email protected]>;tag=1b164627. Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU.. CSeq: 1 ACK. Content-Length: 0. . ## T 1.2.3.4:62689 -> 5.6.7.8:5060 [AP] INVITE sip:[email protected] SIP/2.0. Via: SIP/2.0/TCP 1.2.3.4:24022;branch=z9hG4bK-d8754z-a5ba7a6914ca1e45-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:doug%[email protected]:62689;transport=TCP>. To: <sip:[email protected]>. From: <sip:doug%[email protected]>;tag=1b164627. Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU.. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: Digest username="[email protected]",realm="domain.com",nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648",uri="sip:[email protected]",response="2a7d0482c71d07180af31548fc344904",algorithm=MD5. User-Agent: X-Lite Beta release 4.0 v3 stamp 55153. Content-Length: 188. . v=0. o=- 7 2 IN IP4 192.168.0.113. s=CounterPath X-Lite 4.0. c=IN IP4 1.2.3.4. t=0 0. m=audio 58262 RTP/AVP 0 8 3 101. a=sendrecv. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. ## T 5.6.7.8:5060 -> 1.2.3.4:62689 [AP] SIP/2.0 100 Trying. Via: SIP/2.0/TCP 1.2.3.4:24022;branch=z9hG4bK-d8754z-a5ba7a6914ca1e45-1---d8754z-;rport=62689. To: <sip:[email protected]>. From: <sip:doug%[email protected]>;tag=1b164627. Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU.. CSeq: 2 INVITE. Server: OpenSIPS (1.6.1-tls (x86_64/linux)). Content-Length: 0. Brett Nemeroff wrote: > Well something is up... > look at the trace, the auth username in the REGISTER is *right*.. > > that $Au is being set from the FROM I suspect (which is WRONG). > > Almost as if authentication is not being performed on the INVITE at > all. Can you send a trace of the INVITE? > > If you arn't authenticating the INVITEs I'd expect this behavior with > an improperly set client. > -Brett > > > > > On Wed, Apr 7, 2010 at 1:34 PM, Douglas Lane <[email protected]> wrote: > >> Hi Brett, >> >> For billing , I use an AVP which is then sent to FreeRADIUS for >> normalization by CDRTool. >> >> The billing_party avp is constructed like so: >> >> $avp(s:billing_party)=$Au; >> >> And now I've just read the following: >> >> $Au - username for accounting purposes. It's a selective pseudo variable >> (inherited from acc module). It returns $au if exits or From username >> otherwise. >> >> Hmmm I'm wondering if its using the From header? >> >> As for authorization, I'm sure it should be failing - I actually thought >> I had stuffed up my multi-domain support, or done something wrong, but >> definitely domains are working correctly. As far as I'm aware, the >> username section in the digest should only hold the username and not the >> realm / domain name in it. >> >> In any case, the fact that the auth id contains the username and the >> realm is something I need to reject as its not a truly legal >> registration / authorization. I'm assuming auth_db module problem does a >> sanity check on the username section of the digest when authorizing, and >> if it has a @ portion in it, probably strips it out so that it can >> register successfully. Hmmm thats actually something I should test - see >> if I change the auth id to something like username [at] bob [dot] com >> and then have domain [dot] com in the domain part and see if that registers. >> >> Thanks >> Doug >> >> >> Brett Nemeroff wrote: >> >>> Ok, well something is wrong there.. >>> >>> I suspect that you are probably using different headers for billing >>> and authentication.. >>> >>> The auth should really be failing... >>> >>> Actually, relooking at your REGISTER message, the auth id is fine, >>> which is why the REGISTER succeeds.. However, I bet you arn't logging >>> the auth id for billing.. I can't remember how CDRTool logs that bit >>> of the top of my head. >>> >>> On Wed, Apr 7, 2010 at 1:15 PM, Douglas Lane <[email protected]> wrote: >>> >>> >>>> Hi Brett, >>>> >>>> I agree to the rejecting part, as then client can phone support. The >>>> problem is, if I don't make a plan to do some fancy searches to reject >>>> the message, OpenSIPS happily auths the request correctly, and the user >>>> can make and receive calls. >>>> >>>> Thats what has had me a panic as www_authorize returns success on this, >>>> so does proxy_authorize. The issue is when the billing server (CDRTool) >>>> does its rating, it sees username [at] domain [dot] com [at] domain >>>> [dot] com as the billing party, instead of username [at] domain [dot] >>>> com and hey presto - FREE calls. (well default rated anyway) >>>> >>>> Anyway, was looking through the textopt functions, and search() seems >>>> the right tool to use, but I don't see it has any options to narrow down >>>> to like the WWW header as well as the To header of the message - any >>>> suggestions? >>>> >>>> Thanks >>>> Doug >>>> >>>> >>>> Brett Nemeroff wrote: >>>> >>>> >>>>> There's only so much you can do for user error... either correct it >>>>> silently, allowing them to work, even though they did it wrong (you >>>>> could automatically remove the extra domain param), or reject it. >>>>> >>>>> I suppose a third method would be to redirect them to a feature server >>>>> that could actually announce to them what they did wrong "I'm sorry, >>>>> but you seem to have configured your SIP client improperly". >>>>> >>>>> I personally would reject this kind of failure.. which I think would >>>>> be the default behavior if you didn't do anything since the username >>>>> param wouldn't match anything valid. >>>>> >>>>> -Brett >>>>> >>>>> >>>>> >>>>> On Wed, Apr 7, 2010 at 1:02 PM, Douglas Lane <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>>> Hi Brett, >>>>>> >>>>>> I know the problem is with the auth id, and I was using Xlite as an >>>>>> example. Unfortunately when we hand the SIP accounts out, we don't have >>>>>> control over the client setting up the end device (such as an >>>>>> audiocodes, siemens, linksys or alike). So I was looking for a way I >>>>>> could reject it due to invalid characters. >>>>>> >>>>>> I'll look into textopts and move forward from there - thanks for all the >>>>>> assistance. >>>>>> >>>>>> Thanks >>>>>> Doug >>>>>> >>>>>> >>>>>> Brett Nemeroff wrote: >>>>>> >>>>>> >>>>>> >>>>>>> You could probably use textops to search the auth username for the "@" >>>>>>> character and simply reject with a code like "401","Invalid Characters >>>>>>> in Auth Id" >>>>>>> >>>>>>> With clients like xlite, it'll probably display in the screen when >>>>>>> attempting to register. >>>>>>> >>>>>>> However, this really seems like the auth id on the client is just >>>>>>> setup improperly and should be an easy fix: >>>>>>> >>>>>>> Seems like in XLite you have: >>>>>>> Auth Id: [email protected] >>>>>>> >>>>>>> when it should be >>>>>>> Auth Id: username >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 7, 2010 at 12:33 AM, Douglas Lane <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Iñaki Baz Castillo wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2010/4/6 Douglas Lane <[email protected]>: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> My clients register as username [at] domain [dot] com, which works >>>>>>>>>> perfectly. CDRTool then checks the billing party portion, and bills >>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> Recently, I've noticed the odd client registering as username [at] >>>>>>>>>> domain [dot] com [at] domain [dot] com. This causes a problem in the >>>>>>>>>> billing server, as it tries to find subscriber username [at] domain >>>>>>>>>> [dot] com [at] domain [dot] com instead of username [at] domain >>>>>>>>>> [dot] com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Which exact REGISTER field you mean? From URI? To URI? Contact URI? >>>>>>>>> credentials username? credentials realm? >>>>>>>>> >>>>>>>>> Could you please paste an example of such REGISTER? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hi Inaki, >>>>>>>> >>>>>>>> As requested, please find below REGISTER request: >>>>>>>> >>>>>>>> IP 1.2.3.4 is the client >>>>>>>> IP 5.6.7.8 is the server >>>>>>>> domain.com is the domain/realm used to register >>>>>>>> >>>>>>>> T 1.2.3.4:58889 -> 5.6.7.8:5060 [AP] >>>>>>>> REGISTER sip:domain.com SIP/2.0. >>>>>>>> Via: SIP/2.0/TCP >>>>>>>> 192.168.0.236:10990;branch=z9hG4bK-d8754z-375adf06ebab9063-1---d8754z-;rport. >>>>>>>> Max-Forwards: 70. >>>>>>>> Contact: >>>>>>>> <sip:doug%[email protected];rinstance=0051b76a880b6325;transport=TCP>. >>>>>>>> To: <sip:doug%[email protected]>. >>>>>>>> From: <sip:doug%[email protected]>;tag=7adae37b. >>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q.. >>>>>>>> CSeq: 2 REGISTER. >>>>>>>> Expires: 3600. >>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>>>>>>> SUBSCRIBE, INFO. >>>>>>>> User-Agent: X-Lite Beta release 4.0 v3 stamp 55153. >>>>>>>> Authorization: Digest >>>>>>>> username="[email protected]",realm="domain.com",nonce="4bbc186000007a99f8b3ca45e77563c7b19f6ea461817c3e",uri="sip:domain.com",response="96bf9f599ddf3057c5bc48faf9a1d923",algorithm=MD5. >>>>>>>> Content-Length: 0. >>>>>>>> . >>>>>>>> >>>>>>>> # >>>>>>>> T 5.6.7.8:5060 -> 1.2.3.4:58889 [AP] >>>>>>>> SIP/2.0 100 Trying. >>>>>>>> Via: SIP/2.0/TCP >>>>>>>> 192.168.0.236:10990;branch=z9hG4bK-d8754z-375adf06ebab9063-1---d8754z-;rport=58889;received=1.2.3.4. >>>>>>>> To: <sip:doug%[email protected]>. >>>>>>>> From: <sip:doug%[email protected]>;tag=7adae37b. >>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q.. >>>>>>>> CSeq: 2 REGISTER. >>>>>>>> Server: OpenSIPS (1.6.1-tls (x86_64/linux)). >>>>>>>> Content-Length: 0. >>>>>>>> . >>>>>>>> >>>>>>>> # >>>>>>>> T 5.6.7.8:5060 -> 1.2.3.4:58889 [AP] >>>>>>>> SIP/2.0 200 OK. >>>>>>>> Via: SIP/2.0/TCP >>>>>>>> 192.168.0.236:10990;branch=z9hG4bK-d8754z-375adf06ebab9063-1---d8754z-;rport=58889;received=1.2.3.4. >>>>>>>> To: >>>>>>>> <sip:doug%[email protected]>;tag=cdff758d742c799b04c91123cd1608d5.5bf0. >>>>>>>> From: <sip:doug%[email protected]>;tag=7adae37b. >>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q.. >>>>>>>> CSeq: 2 REGISTER. >>>>>>>> Contact: >>>>>>>> <sip:doug%[email protected];rinstance=0051b76a880b6325;transport=TCP>;expires=3600;received="sip:1.2.3.4:58889;transport=TCP". >>>>>>>> Server: OpenSIPS (1.6.1-tls (x86_64/linux)). >>>>>>>> Content-Length: 0. >>>>>>>> >>>>>>>> >>>>>>>> Invites are also similar just with the From header being set - so I >>>>>>>> assume if we can fix this, then I can apply the same type of fix to >>>>>>>> register requests. >>>>>>>> >>>>>>>> Either I need to be able to reject the above messages with invalid >>>>>>>> formatted headers, or I need t rewrite things (which I'm not always >>>>>>>> comfortable doing within opensips) >>>>>>>> >>>>>>>> I appreciate the assistance. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Doug >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
