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:user...@omnity.net SIP/2.0.
Via: SIP/2.0/UDP proxyip;branch=z9hG4bK267e.e988a546.0.
To: sip:user...@omnity.net.
From: sip:user...@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:user...@mydomain.net;tag=f0253efb8005057b3cc0ab8fa35ff1d9-0dd9.
From: sip:user...@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:user...@mydomain.net SIP/2.0.
Via: SIP/2.0/UDP proxyip;branch=z9hG4bK543f.efdb2d8.0.
To: sip:user...@mydomain.net.
From: sip:user...@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='user...@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:user...@mydomain.net;tag=f0253efb8005057b3cc0ab8fa35ff1d9-9add.
From: sip:user...@mydomain.net;tag=047a42f14f0e800c0a21487d4bc09012-fab2.
CSeq: 10 PUBLISH.
Call-ID: 79a5f23d214a91de-9057@proxyip.
Server: OmniVigil 5.2-rc1.
Content-Length: 0.



#!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;
}

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to