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
