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
