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
