[OpenSIPS-Users] Strange username registration
Douglas Lane
doug at wd.co.za
Wed Apr 7 21:04:09 CEST 2010
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:18005556667 at domain.com 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%40domain.com at 1.2.3.4:62689;transport=TCP>.
To: <sip:18005556667 at domain.com>.
From: <sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com>.
From: <sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
From: <sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com 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:18005556667 at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
From: <sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com 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%40domain.com at 1.2.3.4:62689;transport=TCP>.
To: <sip:18005556667 at domain.com>.
From: <sip:doug%40domain.com at domain.com>;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="doug at domain.com",realm="domain.com",nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648",uri="sip:18005556667 at domain.com",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:18005556667 at domain.com>.
From: <sip:doug%40domain.com at domain.com>;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 <doug at wd.co.za> 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 <doug at wd.co.za> 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 <doug at wd.co.za> 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: username at domain.com
>>>>>>>
>>>>>>> when it should be
>>>>>>> Auth Id: username
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 7, 2010 at 12:33 AM, Douglas Lane <doug at wd.co.za> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Iñaki Baz Castillo wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2010/4/6 Douglas Lane <doug at wd.co.za>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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%40domain.com at 1.2.3.4;rinstance=0051b76a880b6325;transport=TCP>.
>>>>>>>> To: <sip:doug%40domain.com at domain.com>.
>>>>>>>> From: <sip:doug%40domain.com at domain.com>;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="doug at domain.com",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%40domain.com at domain.com>.
>>>>>>>> From: <sip:doug%40domain.com at domain.com>;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%40domain.com at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.5bf0.
>>>>>>>> From: <sip:doug%40domain.com at domain.com>;tag=7adae37b.
>>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q..
>>>>>>>> CSeq: 2 REGISTER.
>>>>>>>> Contact:
>>>>>>>> <sip:doug%40domain.com at 1.2.3.4;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
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opensips.org
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
More information about the Users
mailing list