[OpenSIPS-Users] Strange username registration

Douglas Lane doug at wd.co.za
Wed Apr 7 20:15:20 CEST 2010


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
>   



More information about the Users mailing list