Hi,
Some interesting behavior with kam-3.0, which I haven't experienced with <= 1.5:
Let's say I have two subscribers A and B registered. A has a received-value in location table, B has it set to NULL.
If I call lookup() for A, $ru is set to the registered contact, and $du is set to the received-value. When for example A is busy, I catch it with a failure route and rewrite $ru to B. Calling lookup() again sets my $ru to the contact of B, but since the received-value of B is NULL in the DB, the $du is still pointing to the received-value of A, instead of being set to null.
A quick-fix is to set $du to null before calling lookup(), but I'm wondering if this is a bug or intended behavior?
Thanks, Andreas
Are you using newest 3.0 ? (git checkout) I remember I once also had a problem with PVs which had stored old values, but I can not remember naymore which PV it was.
regards klaus
Am 11.05.2010 14:59, schrieb Andreas Granig:
Hi,
Some interesting behavior with kam-3.0, which I haven't experienced with <= 1.5:
Let's say I have two subscribers A and B registered. A has a received-value in location table, B has it set to NULL.
If I call lookup() for A, $ru is set to the registered contact, and $du is set to the received-value. When for example A is busy, I catch it with a failure route and rewrite $ru to B. Calling lookup() again sets my $ru to the contact of B, but since the received-value of B is NULL in the DB, the $du is still pointing to the received-value of A, instead of being set to null.
A quick-fix is to set $du to null before calling lookup(), but I'm wondering if this is a bug or intended behavior?
Thanks, Andreas
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 5/11/10 2:59 PM, Andreas Granig wrote:
Hi,
Some interesting behavior with kam-3.0, which I haven't experienced with <= 1.5:
Let's say I have two subscribers A and B registered. A has a received-value in location table, B has it set to NULL.
If I call lookup() for A, $ru is set to the registered contact, and $du is set to the received-value. When for example A is busy, I catch it with a failure route and rewrite $ru to B. Calling lookup() again sets my $ru to the contact of B, but since the received-value of B is NULL in the DB, the $du is still pointing to the received-value of A, instead of being set to null.
A quick-fix is to set $du to null before calling lookup(), but I'm wondering if this is a bug or intended behavior?
at the first sight, looking into the code, should be the same in 1.5. Are you sure is different? Practically the registrar/usrloc were touched just a bit, nothing in the lookup or save functionality.
Looking in tm at execution of failure route, the dst_uri is recovered from the winning branch. lookup updates the dst_uri only if it is a value in location record.
Right now, I would say that lookup should reset any existing dst_uri if received is null. Other opinions? Is anyone setting dst_uri before lookup and needs it after?
Cheers, Daniel
2010/5/11 Daniel-Constantin Mierla miconda@gmail.com:
Right now, I would say that lookup should reset any existing dst_uri if received is null.
IMHO it's the expected behaviour, if not it would be a chaos as we should take care of manually reseting N pseudovariables (perhaps N+1 tomorrow).
On 5/11/10 10:56 PM, Iñaki Baz Castillo wrote:
2010/5/11 Daniel-Constantin Mierlamiconda@gmail.com:
Right now, I would say that lookup should reset any existing dst_uri if received is null.
IMHO it's the expected behaviour, if not it would be a chaos as we should take care of manually reseting N pseudovariables (perhaps N+1 tomorrow).
in this case is only 1, dst uri, no matter tomorrow are N + M :-) .
Cheers, Daniel
at the first sight, looking into the code, should be the same in 1.5. Are you sure is different? Practically the registrar/usrloc were touched just a bit, nothing in the lookup or save functionality.
Hmmm... You're right, I'm not sure about 1.5, since I only used this version for load-balancing.
At least, I can confirm it was working fine with 1.3. However, it's definitely reproducable with 3.0, since I only have this one on my lab servers at the moment.
You need any additional information or something to track it down?
Andreas
On 5/12/10 11:33 AM, Andreas Granig wrote:
at the first sight, looking into the code, should be the same in 1.5. Are you sure is different? Practically the registrar/usrloc were touched just a bit, nothing in the lookup or save functionality.
Hmmm... You're right, I'm not sure about 1.5, since I only used this version for load-balancing.
At least, I can confirm it was working fine with 1.3. However, it's definitely reproducable with 3.0, since I only have this one on my lab servers at the moment.
You need any additional information or something to track it down?
no, I found it in the code. I am going to commit on master soon.
Cheers, Daniel
On 5/13/10 11:30 AM, Daniel-Constantin Mierla wrote:
On 5/12/10 11:33 AM, Andreas Granig wrote:
at the first sight, looking into the code, should be the same in 1.5. Are you sure is different? Practically the registrar/usrloc were touched just a bit, nothing in the lookup or save functionality.
Hmmm... You're right, I'm not sure about 1.5, since I only used this version for load-balancing.
At least, I can confirm it was working fine with 1.3. However, it's definitely reproducable with 3.0, since I only have this one on my lab servers at the moment.
You need any additional information or something to track it down?
no, I found it in the code. I am going to commit on master soon.
commit done: http://lists.sip-router.org/pipermail/sr-dev/2010-May/007530.html
Practically is one line of code. I had not time to do some testing, should be no side effects, though. I will analyze a bit to see if has other impacts and then backport to 3.0.x. If you do some tests with 3.0.x meanwhile, just let me know the results.
Thanks, Daniel
Cheers, Daniel
-
Andreas Granig -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion