[SR-Users] pua_dialoginfo publish sent without recieved etag (intermittent)

Wed Oct 21 13:35:39 CEST 2015

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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151021/89bd7165/attachment.html>
-------------- next part --------------
U 2015/10/21 08:53:33.427545 10.7.0.109:5060 -> 10.7.0.54:5060

PUBLISH sip:user01 at domain.com:5061 SIP/2.0.
Via: SIP/2.0/UDP 194.213.29.109;branch=z9hG4bKc0bf.5220e8b2000000000000000000000000.0.
To: <sip:user01 at domain.com:5061>.
From: <sip:user01 at domain.com:5061>;tag=dc193272077e3034e2352f60374fbd88-51e2.
CSeq: 10 PUBLISH.
Call-ID: 151c497d03f288ff-17786 at 194.213.29.109.
Content-Length: 619.
User-Agent: kamailio_proxy.
Max-Forwards: 70.
Event: dialog.
Expires: 126.
Content-Type: application/dialog-info+xml.
.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:user01 at domain.com:5061">
  <dialog id="2490238042 at 192.168.1.235" call-id="2490238042 at 192.168.1.235" direction="initiator">
    <state>Trying</state>
    <remote>
      <identity>sip:user02 at domain.com:5061</identity>
      <target uri="sip:user02 at domain.com:5061"/>
    </remote>
    <local>
      <identity>sip:user01 at domain.com:5061</identity>
      <target uri="sip:user01 at domain.com:5061"/>
    </local>
  </dialog>
</dialog-info>

U 2015/10/21 08:53:33.430883 10.7.0.54:5060 -> 10.7.0.109:5060

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 194.213.29.109;branch=z9hG4bKc0bf.5220e8b2000000000000000000000000.0;received=10.7.0.109.
To: <sip:user01 at domain.com:5061>;tag=145ace6a3d5ec4c1cfd3798362d1102c-03ee.
From: <sip:user01 at domain.com:5061>;tag=dc193272077e3034e2352f60374fbd88-51e2.
CSeq: 10 PUBLISH.
Call-ID: 151c497d03f288ff-17786 at 194.213.29.109.
Expires: 126.
SIP-ETag: a.1445282824.23391.695.0.
Server: kamailio_presence.
Content-Length: 0.
.

U 2015/10/21 08:53:33.436429 10.7.0.109:5060 -> 10.7.0.54:5060

PUBLISH sip:user01 at domain.com:5061 SIP/2.0.
Via: SIP/2.0/UDP 10.7.0.109;branch=z9hG4bK656f.5220e8b2000000000000000000000000.0.
To: <sip:user01 at domain.com:5061>.
From: <sip:user01 at domain.com:5061>;tag=dc193272077e3034e2352f60374fbd88-35aa.
CSeq: 10 PUBLISH.
Call-ID: 151c497d03f288ff-17714 at 194.213.29.109.
Content-Length: 655.
User-Agent: kamailio_proxy.
Max-Forwards: 70.
Event: dialog.
Expires: 11.
SIP-If-Match: a.1445282824.23391.695.0.
Content-Type: application/dialog-info+xml.
.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:user01 at domain.com:5061">
  <dialog id="2490238042 at 192.168.1.235" call-id="2490238042 at 192.168.1.235" direction="initiator">
    <state>terminated</state>
    <remote>
      <identity>sip:user02 at domain.com:5061</identity>
      <target uri="sip:user02 at domain.com:5061"/>
    </remote>
    <local>
      <identity>sip:user01 at domain.com:5061</identity>
      <target uri="sip:user01 at 192.168.1.235:3800;transport=TLS;alias=212.2.172.228~26345~3"/>
    </local>
  </dialog>
</dialog-info>

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.7.0.109;branch=z9hG4bK656f.5220e8b2000000000000000000000000.0.
To: <sip:user01 at domain.com:5061>;tag=145ace6a3d5ec4c1cfd3798362d1102c-7ef0.
From: <sip:user01 at domain.com:5061>;tag=dc193272077e3034e2352f60374fbd88-35aa.
CSeq: 10 PUBLISH.
Call-ID: 151c497d03f288ff-17714 at 194.213.29.109.
Expires: 11.
SIP-ETag: a.1445282824.23393.688.1.
Server: kamailio_presence.
Content-Length: 0.
.