Ok, I'm starting to think these may in fact actually be dialogs from previous incoming calls. When the dialog sets are dumped there is a huge list (e.g. 3000+) of:
[in] [est] <--uri too long-->
entries shown. The "uri too long" agrees with the typical incoming calls I receive. I'm guessing the former two columns mean 'incoming' and 'established.' I still don't understand how that's possible since pjsip is acknowledging BYEs (with an ACK) sent by the remote party, so everything should be cleaned up. Again, I'm using pjsua2 here so as far as I know I shouldn't have to be doing anything explicit here aside from making sure my Call subclass is being destructed.
In the pjsip log output, I do see lines like this when the call first comes in:
18:39:50.544 dlg0x7fdfac11f ...Session count inc to 3 by mod-invite
18:39:50.544 dlg0x7fdfac11f ...Session count inc to 3 by mod-pjsua
but when the same call disconnects, I only see this 'session count decrement' message when the BYE is received:
18:40:29.945 dlg0x7fdfac0e7 ......Session count dec to 4 by mod-invite
Should I be seeing a similar log line when mod-pjsua decreases the reference counter as well?
Any pointers about where I should begin to debug this issue?
On Tue, Aug 22, 2017 at 2:16 AM, mscdexdotexe <mscdex@xxxxxxxxxx> wrote:
I should add I'm not 100% sure that the dialog memory pools are from the qualify/OPTIONS messages. They could be tied to old incoming calls too, however I already verified that my destructor is being called in my pjsua2 Call subclass for each incoming call, so any/all call dialogs *should* no longer exist...On Tue, Aug 22, 2017 at 1:49 AM, mscdexdotexe <mscdex@xxxxxxxxxx> wrote:Hello,I've noticed that pjsip (seen at least with 2.5.5 and 2.6) is not destroying SIP OPTIONS dialogs (at least over 100 or so still in memory), causing memory to continuously grow. I verified this by performing a `pjsua_dump(true);` after my process (a UAS/SIP trunk) has been running for some time. I am using pjsua2 FWIW. Here is an example dialog with the log level set to 9:01:24:29.729 sip_endpoint.c Processing incoming message: Request msg OPTIONS/cseq=101 (rdata0x7f8160e9fb58)01:24:29.729 pjsua_core.c .RX 372 bytes Request msg OPTIONS/cseq=101 (rdata0x7f8160e9fb58) from UDP 10.x.x.3:5070:OPTIONS sip:10.x.x.240:5070 SIP/2.0Via: SIP/2.0/UDP 10.x.x.3:5070;branch=z9hG4bK1ca35f62036d1c From: <sip:10.x.x.3>;tag=1262409931To: <sip:10.x.x.240>Date: Tue, 22 Aug 2017 05:24:29 GMTCall-ID: 2a68ea00-99b1c00d-c5b0c-3a0030a@10.x.x.3 User-Agent: Cisco-CUCM10.5CSeq: 101 OPTIONSContact: <sip:10.x.x.3:5070>Max-Forwards: 0Content-Length: 0--end msg--01:24:29.729 endpoint .Response msg 200/OPTIONS/cseq=101 (tdta0x7f8160c42e50) created01:24:29.729 sip_resolve.c .Target '10.x.x.3:5070' type=UDP resolved to '10.x.x.3:5070' type=UDP (UDP transport)01:24:29.729 pjsua_core.c .TX 655 bytes Response msg 200/OPTIONS/cseq=101 (tdta0x7f8160c42e50) to UDP 10.x.x.3:5070:SIP/2.0 200 OKVia: SIP/2.0/UDP 10.x.x.3:5070;received=10.x.x.3;branch=z9hG4bK1ca35f62036d1c Call-ID: 2a68ea00-99b1c00d-c5b0c-3a0030a@10.x.x.3 From: <sip:10.x.x.3>;tag=1262409931To: <sip:10.x.x.240>;tag=z9hG4bK1ca35f62036d1c CSeq: 101 OPTIONSAllow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONSAccept: application/sdp, application/pidf+xml, application/xpidf+xml, application/simple-message-summary, message/sipfrag;version=2.0, application/im-iscomposing+xml , text/plain Supported: replaces, 100rel, timer, norefersubAllow-Events: presence, message-summary, referContent-Length: 0--end msg--01:24:29.729 tdta0x7f8160c4 .Destroying txdata Response msg 200/OPTIONS/cseq=101 (tdta0x7f8160c42e50)Is there something I may have configured incorrectly or is this a legit bug?
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
