Hello,

I have two Kamailio servers. Running 3.3.2. One uses PUA to send PUBLISH to the second which has presence module.

When the presence server replies to the PUBLISH, it includes a SIP-ETag and an Expires header.

So, in the case I caught on my servers yesterday, the reply had an Expires header of 34.

Trouble is, 60 seconds later, when PUA sent the PUBLISH, it had the SIP-ETag in the PUBLISH header even though the entity tag was expired. But RFC3903 says that when the publish expires, the entity tag expires as well.

The publish was for a dialog-info and both PUBLISHes were generated using the pua_mi module command pua_publish. I don't set the etag in the pua_publish command, it's kamailio that remembers it.

Here is grep pua kamailio.cfg on the first server :

loadmodule "pua.so" loadmodule "pua_mi.so" loadmodule "pua_dialoginfo.so" modparam("pua_dialoginfo", "include_localremote", 1) modparam("pua_dialoginfo", "include_tags", 1) modparam("pua_dialoginfo", "include_callid", 0) modparam("pua", "hash_size", 15) modparam("pua", "db_mode", 0) modparam("pua_dialoginfo", "send_publish_flag", 13) modparam("pua", "update_period", 6 ) # I added this to see if the problem would be fixed modparam("pua_dialoginfo", "caller_confirmed", 1)

I didn't capture the mi udp packets, but I did get the SIP, see below

I think the problem has to do with expires_offset. I set this to reduce SUBSCRIBE expiration by 30 seconds, but it is also reducing PUBLISH expiration by 30 seconds. Do you think this might be the source of my problem?

What else might be causing this ? Is there anyway to set the expires_offset for SUBSCRIBE but not for the PUBLISH?

Any other ideas what might be going on here?

Thanks,

David

Here is the SIP I captured on the pua server :

U 2013/03/29 14:01:41.005025 PUBLISH sip:user161@omnity.net SIP/2.0. Via: SIP/2.0/UDP proxyip;branch=z9hG4bK267e.e988a546.0. To: sip:user161@omnity.net. From: sip:user161@omnity.net;tag=047a42f14f0e800c0a21487d4bc09012-c8fe. CSeq: 10 PUBLISH. Call-ID: 79a5f23d217e3597-9109@proxyip. Content-Length: 0. Max-Forwards: 70. Event: dialog. Expires: 66. SIP-If-Match: a.1363343972.1019.567098.10.

U 2013/03/29 14:01:41.298041 SIP/2.0 200 OK. Via: SIP/2.0/UDP proxyip;branch=z9hG4bK267e.e988a546.0. To: sip:user161@mydomain.net;tag=f0253efb8005057b3cc0ab8fa35ff1d9-0dd9. From: sip:user161@mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-c8fe. CSeq: 10 PUBLISH. Call-ID: 79a5f23d217e3597-9109@proxyip. Expires: 36. SIP-ETag: a.1363343972.1009.565433.11. Content-Length: 0.

U 2013/03/29 14:03:14.317797 PUBLISH sip:user161@mydomain.net SIP/2.0. Via: SIP/2.0/UDP proxyip;branch=z9hG4bK543f.efdb2d8.0. To: sip:user161@mydomain.net. From: sip:user161@mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-fab2. CSeq: 10 PUBLISH. Call-ID: 79a5f23d214a91de-9057@proxyip. Content-Length: 271. Max-Forwards: 70. Event: dialog. Expires: 91. SIP-If-Match: a.1363343972.1009.565433.11. 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='user161@omnity.net'> <dialog id='x_dialogid@192.168.2.5' direction='recipient'> <state>early</state> </dialog> </dialog-info>

U 2013/03/29 14:03:14.319691 SIP/2.0 412 Conditional request failed. Via: SIP/2.0/UDP proxyip;branch=z9hG4bK543f.efdb2d8.0. To: sip:user161@mydomain.net;tag=f0253efb8005057b3cc0ab8fa35ff1d9-9add. From: sip:user161@mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-fab2. CSeq: 10 PUBLISH. Call-ID: 79a5f23d214a91de-9057@proxyip. Server: OmniVigil 5.2-rc1. Content-Length: 0.