4 Apr
2013
4 Apr
'13
5:50 p.m.
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(a)omnity.net'>
<dialog id='x_dialogid(a)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.