[SR-Users] Problem with expired SIP Etag
David
kamailio.org at spam.lublink.net
Thu Apr 4 16:50:56 CEST 2013
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 at omnity.net SIP/2.0.
Via: SIP/2.0/UDP proxyip;branch=z9hG4bK267e.e988a546.0.
To: sip:user161 at omnity.net.
From: sip:user161 at omnity.net;tag=047a42f14f0e800c0a21487d4bc09012-c8fe.
CSeq: 10 PUBLISH.
Call-ID: 79a5f23d217e3597-9109 at 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 at mydomain.net;tag=f0253efb8005057b3cc0ab8fa35ff1d9-0dd9.
From: sip:user161 at mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-c8fe.
CSeq: 10 PUBLISH.
Call-ID: 79a5f23d217e3597-9109 at proxyip.
Expires: 36.
SIP-ETag: a.1363343972.1009.565433.11.
Content-Length: 0.
U 2013/03/29 14:03:14.317797
PUBLISH sip:user161 at mydomain.net SIP/2.0.
Via: SIP/2.0/UDP proxyip;branch=z9hG4bK543f.efdb2d8.0.
To: sip:user161 at mydomain.net.
From: sip:user161 at mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-fab2.
CSeq: 10 PUBLISH.
Call-ID: 79a5f23d214a91de-9057 at 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 at omnity.net'>
<dialog id='x_dialogid at 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 at mydomain.net;tag=f0253efb8005057b3cc0ab8fa35ff1d9-9add.
From: sip:user161 at mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-fab2.
CSeq: 10 PUBLISH.
Call-ID: 79a5f23d214a91de-9057 at proxyip.
Server: OmniVigil 5.2-rc1.
Content-Length: 0.
-------------- next part --------------
#!KAMAILIO
#
# $Id$
#
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
/* Uncomment these lines to enter debugging mode */
debug=1
fork=yes
log_stderror=no
disable_tcp=yes
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
children=16
# Extra stuff for Omnity
server_header="Server: OmniVigil 5.2-rc1"
user_agent_header="User-Agent: OmniVigil 5.2-rc1"
server_signature=yes
# ------------------ module loading ----------------------------------
mpath="/usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/"
loadmodule "kex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "db_mysql.so"
loadmodule "sl.so"
loadmodule "xlog.so"
loadmodule "maxfwd.so"
loadmodule "textops.so"
loadmodule "rr.so"
loadmodule "siputils.so"
loadmodule "pv.so"
loadmodule "presence.so"
loadmodule "presence_dialoginfo.so"
loadmodule "presence_mwi.so"
#loadmodule "presence_xml.so"
loadmodule "sanity.so"
loadmodule "mi_fifo.so"
loadmodule "avpops.so"
loadmodule "regex.so"
# ----------------- setting module-specific parameters ---------------
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# -- presence params --
modparam("presence", "db_url", "mysql://kamailio:secret@127.0.0.1/kamailio")
modparam("presence", "server_address", "sip:myip:5060")
modparam("presence", "timeout_rm_subs", 0) # failed NOTIFY doesn't cause subscription to be cancelled - Fixed BLF failing on aastra
modparam("presence", "db_mode", 2)
modparam("presence", "max_expires",3600 )
modparam("presence", "expires_offset", 30)
# BLF fixes #45116
# Lots of space for tracking publishes, there are too many publishes in memory vs the space in the hash table
modparam("presence", "pres_htable_size", 15 )
#modparam("presence", "fallback2db" ,1 )
modparam("presence", "db_update_period", 5);
modparam("presence_dialoginfo", "force_single_dialog", 1)
modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
# The following are corrections for performance on GXP phones
# RFC value 32000
modparam("tm", "wt_timer", 32000)
# ------------------------- request routing logic -------------------
# main routing logic
route{
if(!sanity_check("1511", "7"))
{
xlog("L_INFO", "Rejected request, malformed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
exit;
}
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
if (is_method("OPTIONS"))
{
xlog("L_DEBUG", "Reply to OPTIONS - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
sl_send_reply('200', 'ok');
exit;
}
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!is_method("SUBSCRIBE|PUBLISH")) {
sl_send_reply("488", "Not Acceptable Here");
exit;
}
# Block retransmissions
if (! t_newtran())
{
sl_reply_error();
exit;
};
if(is_method("PUBLISH"))
{
handle_publish();
t_release();
} else if( is_method("SUBSCRIBE"))
{
handle_subscribe();
t_release();
};
exit;
}
More information about the sr-users
mailing list