[OpenSIPS-Users] Strange username registration

Wed Apr 7 20:06:22 CEST 2010

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
>