[OpenSIPS-Users] Strange username registration
Douglas Lane
doug at wd.co.za
Thu Apr 8 19:38:17 CEST 2010
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<rrevels at bandwidth.com> 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<doug at wd.co.za> 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:18005556667 at domain.com 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%40domain.com at 1.2.3.4:62689;transport=TCP>.
>>>>> To:<sip:18005556667 at domain.com>.
>>>>> From:<sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com>.
>>>>> From:<sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
>>>>> From:<sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com 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:18005556667 at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
>>>>> From:<sip:doug%40domain.com at domain.com>;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:18005556667 at domain.com 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%40domain.com at 1.2.3.4:62689;transport=TCP>.
>>>>> To:<sip:18005556667 at domain.com>.
>>>>> From:<sip:doug%40domain.com at domain.com>;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="doug at domain.com",realm="domain.com",nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648",uri="sip:18005556667 at domain.com",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:18005556667 at domain.com>.
>>>>> From:<sip:doug%40domain.com at domain.com>;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<doug at wd.co.za> 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<doug at wd.co.za> 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<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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
More information about the Users
mailing list