Hi,
I have attached an example where it is working, in this case the BLF is
disabled when the 2nd publish is sent to the presence server, in the
example where it is not working, it appears that the BLF stays enabled,
its as if it never gets a notify message for the terminated call state.
I assume this is becase the presence server cant update the existing
presentity entry and therefor doesnt send the associated notification.
It's intermitent in the sense that it could happen on the 1st test call,
or I could have 5 successfull calls and then this issue occurs, but yes,
as you say, the issue presented itself with the BLF not being disabled,
I am assuming it is because the etag is not sent in the subsequent
publish message, however, if it can be worked around by not considering
the etag I am willing to try it. I had a look at the presence and
presence_dialoginfo module documentation and I cannot see an module
parameter which may enable/disable the etag check.
I managed to work around the expiry of the entry out the database by
setting the override_lifetime pua_dialoginfo module parameter, however,
the blf issue still persists even with the expiry working.
Thanks
On 20/10/2015 20:37, Daniel-Constantin Mierla wrote:
Hello,
the source code needs to be checked, iirc, at some point there was an
option to use last publish, so the etag was not really considered.
You said 'intermitent', but I assume is not the case that etag is used
for follow up publish, just the effect on blf.
Cheers,
Daniel
On 17/10/15 13:24, Asgaroth wrote:
Hi All,
I've come accross an intermittent issue where an initial publish is
sent to our presence server, proxy recieves the subsequent 200 with
etag, but the following publish sent does not contain the
sip-if-match header of the recieved 200, which ends up causing
trouble with BLF on our test devices, it also has the added side
affect of not being cleared out of the presentity table, these
entries need to be manually removed.
This does not occur all the time, I can use the same phone and make
several calls before this issue occurs. It is not limited to a device
type, we've tried with panasonic, polycom, cisco, zoiper, yealink and
linksys devices, all exhibit the same sporadic behaviour.
I've attached an example sip trace of the publish messages where this
happens, you can see the second publish doesnt have the sip-if-match
header whose content should be that of the sip-etag in the previous
200 to the initial publish.
I'm not sure if there is something I am misunderstanding here, a
configuration issue, or if this is indeed a bug.
Both the proxy and the presence server are running kamailio v4.3.3.
Any pointers/suggestions/guidance would be appreciated.
If you need any additional info, please dont hesitate to ask.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio -http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users