Hi Brett,
Big thanks for all the assistance. I'll work on some patches tonight to
the route logic, and let you all know in the morning.
Thanks
Doug
Brett Nemeroff wrote:
> Bah....
> I think I spoke to quick the auth id does have the domain in it..
>
> I think something is buggy here really It shouldn't be authenticating
> like that. For a temp fix I'd just use the textopts mod to reject auth
> ids with invalid characters. I'm interested in how this gets
> resolved..
>
> Maybe you can do something like
> $avp(s:authname) = $(Au{uri.user}) + $ar
>
> or this would be userful too:
> $avp(s:username) = $(Au{uri.user})
>
> Or something similar.. BTW, there seems to be some discrepancy in the
> docs over "$ar"
>
> Let us know what works. :)
> -Brett
>
>
> On Wed, Apr 7, 2010 at 2:04 PM, Douglas Lane <[email protected]> wrote:
>
>> 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
>>
>>
>
> _______________________________________________
> 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
