Hey Brett and Richard,
I was holding thumbs for this one, but it appears to not have made a
difference:
loadmodule "auth_db.so"
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "password_column_2", "password")
modparam("auth_db",
"db_url","mysql://url_to_mysql_been_masked_for_security_purposes")
modparam("auth_db", "load_credentials", "$avp(s:caller_uuid)=id")
modparam("auth_db", "use_domain", 1)
Now I'm concerned that there is a routing logic issue or a bug as I was
sure this would fix the issue.
Any suggestions?
Thanks
Doug
On 2010/04/08 6:13 PM, Brett Nemeroff wrote:
> That's actually a really good point:
> http://www.opensips.org/html/docs/modules/1.6.x/auth_db.html#id228115
>
> "As described in the previous section this parameter contains name of
> column holding pre-calculated HA1 string that were calculated
> including the domain in the username. This parameter is used only when
> calculate_ha1 is set to 0 and user agent send a credentials containing
> the domain in the username"
>
> I think Richard solved this for you. Because password_column_2 points
> to the column with the hash for the user+domain, it's going to work if
> they put the domain in the username. I think your best solution here
> is to set password_column_2 to the same value as password_column and
> not use the ha1b field at all.
>
>
>
> On Thu, Apr 8, 2010 at 6:35 AM, Richard Revels<[email protected]> wrote:
>
>> I think if you don't populate the ha1b column in the subscriber table it
>> would also solve this problem by not passing the auth check. Depending on
>> how you populate the table this may be done outside your control in which
>> case you could use the password_column_2 modparam and set it to a column
>> like ha1 (rather than ha1b) and it would also always fail if the username
>> auth field also contained the domain.
>>
>> Richard
>>
>> On Apr 7, 2010, at 3:22 PM, Douglas Lane wrote:
>>
>>
>>> Hi Brett,
>>>
>>> Big thanks for all the assistance. I'll work on some patches tonight to
>>> the route logic, and let you all know in the morning.
>>>
>>> Thanks
>>> Doug
>>>
>>> Brett Nemeroff wrote:
>>>
>>>> Bah....
>>>> I think I spoke to quick the auth id does have the domain in it..
>>>>
>>>> I think something is buggy here really It shouldn't be authenticating
>>>> like that. For a temp fix I'd just use the textopts mod to reject auth
>>>> ids with invalid characters. I'm interested in how this gets
>>>> resolved..
>>>>
>>>> Maybe you can do something like
>>>> $avp(s:authname) = $(Au{uri.user}) + $ar
>>>>
>>>> or this would be userful too:
>>>> $avp(s:username) = $(Au{uri.user})
>>>>
>>>> Or something similar.. BTW, there seems to be some discrepancy in the
>>>> docs over "$ar"
>>>>
>>>> Let us know what works. :)
>>>> -Brett
>>>>
>>>>
>>>> On Wed, Apr 7, 2010 at 2:04 PM, Douglas Lane<[email protected]> wrote:
>>>>
>>>>
>>>>> 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:[email protected] 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%[email protected]:62689;transport=TCP>.
>>>>> To:<sip:[email protected]>.
>>>>> From:<sip:doug%[email protected]>;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:[email protected]>.
>>>>> From:<sip:doug%[email protected]>;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:[email protected]>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
>>>>> From:<sip:doug%[email protected]>;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:[email protected] 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:[email protected]>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
>>>>> From:<sip:doug%[email protected]>;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:[email protected] 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%[email protected]:62689;transport=TCP>.
>>>>> To:<sip:[email protected]>.
>>>>> From:<sip:doug%[email protected]>;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="[email protected]",realm="domain.com",nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648",uri="sip:[email protected]",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:[email protected]>.
>>>>> From:<sip:doug%[email protected]>;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<[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
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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
