Bogdan,
Over the last day or so I've noticed some other weirdness too, particularly
with engage_media_proxy() not working reliably. I'm thinking I might have
pieces-parts of different builds laying around. I'm not always the best at
removing /usr/local/lib/opensips before I install a new build.
I started fresh with 6547 tonight being sure to remove the old lib directory
before installing. Both this issue and the Mediaproxy one seem to have
resolved themselves.
How much manual housekeeping should be required after an update from svn? I'd
prefer not to believe I'm the only one who has encountered issues like this. :)
- Jeff
On Jan 27, 2010, at 6:54 AM, Bogdan-Andrei Iancu wrote:
> Hi Jeff,
>
> Got your email - I used the SB you had and from script check_address() -
> to be able to check with your IPs . It worked
>
> Also I tested using some IPs from our network versus
> check_source_address() and again, It worked.
>
> Please apply the attached patched (just debugs) and use debug=4 to
> capture the logs to see what is going wrong in your case.
>
> Regards,
> Bogdan
>
>
> Bogdan-Andrei Iancu wrote:
>> I do not think this is related to the registrar update, but rather to
>> the "permissions" fixes from today (see rev 6539).
>>
>> I did some tests and seams to work ok - if you want, you can privately
>> send me the dump of the address table and the IP which does not match,
>> just to check what is going on.
>>
>> Regards,
>> Bogdan
>>
>> Jeff Pyle wrote:
>>
>>> Bogdan,
>>>
>>> I didn't catch it before, but it appears the update seems to have broken
>>> the following:
>>>
>>> if (check_source_address("1","$avp(s:peer_uuid)")) {
>>> .. do stuff ..
>>> }
>>>
>>> The check_source_address returns false. As a temporary workaround I've
>>> added lines the following lines:
>>>
>>> if ($si == '2.3.4.5') {
>>> .. do stuff ..
>>> } else if ($si == '2.3.4.6') {
>>> .. do the same stuff .. {
>>> } else if ...
>>>
>>>
>>> - Jeff
>>>
>>>
>>> On Jan 25, 2010, at 11:49 PM, Jeff Pyle wrote:
>>>
>>>
>>>
>>>> Bogdan,
>>>>
>>>> Early results have this update working perfectly.
>>>>
>>>>
>>>> - Jeff
>>>>
>>>>
>>>> On Jan 25, 2010, at 10:29 AM, Jeff Pyle wrote:
>>>>
>>>>
>>>>
>>>>> Bogdan,
>>>>>
>>>>> Will do. Thanks.
>>>>>
>>>>>
>>>>>
>>>>> - Jeff
>>>>>
>>>>>
>>>>> On Jan 25, 2010, at 9:35 AM, Bogdan-Andrei Iancu wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Jeff,
>>>>>>
>>>>>> See revision #6527 on trunk - if you could run some more tests on it and
>>>>>> report if works ok, it will be great.
>>>>>>
>>>>>> Regards,
>>>>>> Bogdan
>>>>>>
>>>>>> Jeff Pyle wrote:
>>>>>>
>>>>>>
>>>>>>> The "f" flag sounds fantastic. Thanks.
>>>>>>>
>>>>>>>
>>>>>>> - Jeff
>>>>>>>
>>>>>>>
>>>>>>> On Jan 18, 2010, at 9:24 AM, Bogdan-Andrei Iancu wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Jeff,
>>>>>>>>
>>>>>>>> Jeff Pyle wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Iñaki,
>>>>>>>>>
>>>>>>>>> On Jan 9, 2010, at 5:00 PM, Iñaki Baz Castillo wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> El Sábado, 9 de Enero de 2010, Jeff Pyle escribió:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> The docs say that when using the "b" flag with lookup() when
>>>>>>>>>>> multiple
>>>>>>>>>>> records are present, it will load only the one with the highest q.
>>>>>>>>>>> What
>>>>>>>>>>> if the q is the same for all? How does it decide which to use?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I've not tested it with multiple users sharing same "q". however it
>>>>>>>>>> should
>>>>>>>>>> fetch all the users with highest "q", not just one of them.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Perhaps I'm asking the wrong question. I'm looking to allow only one
>>>>>>>>> registration per user in the sense that if a second successful
>>>>>>>>> registration comes in it will replace tne existing one. My approach
>>>>>>>>> so far is to use a max_contacts=2 and the lookup() function with the
>>>>>>>>> "b" flag to retrieve only one.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> maybe without the "b" flag as the "b" flag will return you all the
>>>>>>>> registered contacts.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> max_contacts=1 returns a 503 to the new "replacement" registration
>>>>>>>>> request, so that's out.
>>>>>>>>>
>>>>>>>>> Perhaps the hot ticket is to run an all-DB mode running a manual
>>>>>>>>> mysql query with avp_db_query after successful REGISTER
>>>>>>>>> authentication but before the save() so we can remove any existing
>>>>>>>>> registrations before the new one is saved. Thoughts?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> No way - the SIP contact matching is much to complicated to do it at
>>>>>>>> DB
>>>>>>>> level.
>>>>>>>>
>>>>>>>>
>>>>>>>> As I found that kind of behaviour was more and more asked by people, I
>>>>>>>> will add a new flag "f" to force at save() time the override of the
>>>>>>>> existing contacts if the max_contacts() was exceeded.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bogdan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> - Jeff
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Bogdan-Andrei Iancu
>>>>>>>> www.voice-system.ro
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Regards,
>>>>>>> --------
>>>>>>> Jeff Pyle
>>>>>>> Director, Voice Engineering
>>>>>>> Fidelity Voice & Data | 23250 Chagrin Blvd, Suite 250 | Beachwood, Ohio
>>>>>>> 44122
>>>>>>> P: 216-245-4106
>>>>>>> F: 216-595-0706
>>>>>>> E: [email protected]
>>>>>>>
>>>>>>> Visit us at http://www.fidelityvoice.com
>>>>>>>
>>>>>>> 2008 & 2009 Inductee to the prestigious Weatherhead 100
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
> <permission.diff>_______________________________________________
> 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
