Matthew, do they really stay active after a complete cancel? Or is that just because you're using the wrong SIPp scenario and the pjsip breaks down the call first after lack of activity after the 32 seconds? I couldn't tell from your responses whether your server scenario was properly adjusted to handling the cancel. If not, try this scenario: https://github.com/ossobv/sipp-scenarios/blob/master/out-in/iinv-o180-icancel.xml It expects an INVITE (i), sends 180 (o) and expects a CANCEL (i); to which it properly replies with a 200, and a 487 to the INVITE. (The scenario's may require a recent (master) version of sipp.) Cheers, Walter Doekes OSSO B.V. On 14-01-16 23:47, Matthew Williams wrote: > pjsip has a max_calls configuration (and a corresponding constant which > sets a hard limit in the c headers). I had this set to 512, which was > being hit very quickly since in this particular scenario calls are > staying "active" for 32s when I was expecting them to only remain active > for < 1s due to the immediate CANCEL. It was really all caused by a > misunderstanding of the RFC and not with the application or signalling > per se. > > On Thu, Jan 14, 2016 at 5:36 PM, Carlos Ruiz D?az > <carlos.ruizdiaz at gmail.com <mailto:carlos.ruizdiaz at gmail.com>> wrote: > > Not sure if I understand what you mean with increasing the active > calls limit. > > The solution is these cases is to figure out what went wrong with > the signaling, and fixing it in the SIP level. > > Looks like you have identified the problem and the potential > solution. Make sure to update the thread with your results :). > > Regards, > Carlos > > On Thu, Jan 14, 2016 at 4:28 PM, Matthew Williams > <mgwilliams at gmail.com <mailto:mgwilliams at gmail.com>> wrote: > > Carlos, > > If I'm reading > http://tools.ietf.org/html/rfc3261#section-17.1.1.2 correctly, > then sipp & pjsip are both behaving as expected, and the > solution is to just have a higher limit on active calls. > > I will certainly be testing with some other UAs, but sipp is > convenient for load testing & developing against random scenarios. > > On Thu, Jan 14, 2016 at 5:23 PM, Carlos Ruiz D?az > <carlos.ruizdiaz at gmail.com <mailto:carlos.ruizdiaz at gmail.com>> > wrote: > > Don't use sipp. Since every scenario in SIPP is actually > programmed by you, there's a chance you are not implementing > the requests/replies properly. E.g.: incorrect or absent > tags, incorrect Vias, Routes or Record-Routes, incorrect > CSeq, etc. > > Use a B2BUA as you UAS. Use Asterisk or FreeSwitch to make > sure the signaling is properly implemented. > > Sniff the traffic with Wireshark or ngrep if using a B2BUA > is not a option. I'm sure there's something wrong with the > protocol. > > > On Thu, Jan 14, 2016 at 4:14 PM, Joel Dodson > <jdodson at acm.org <mailto:jdodson at acm.org>> wrote: > > Hi Matthew, > > python/pjsua2 might not be the best choice for writing a > SIP server. Several years ago, on PJSIP 0.8 to 1.0, I > wrote a signaling and media gateway. The advice then > was to use the lower level libraries (PJSIP and PJMEDIA > is what I recall using). There are still some nice > abstractions and state machines at that level, but you > have more flexibility with the number calls you need to > support. Now I'm working with servers externally so > using the python bindings is working very well for me. > > I suspect, as Carlos mentioned, you're running into > issues with the protocol. If you try to cancel a call > before being answered (sending CANCEL because you > haven't received a 200 OK yet for the INVITE), the call > object is probably intentionally kept around to deal > with any 200 OKs that might be coming in for the > original INVITE. When you call hangup on the call > object it probably results in a CANCEL or a BYE > depending on the state of the dialog. Prior to > confirmed, it should send a CANCEL. It's been a long > time since I've read any SIP RFCs, or been in the PJSIP > internals, so I could be off a bit. > > hope that helps > > Joel > > > On Thu, Jan 14, 2016 at 2:03 PM, Carlos Ruiz D?az > <carlos.ruizdiaz at gmail.com > <mailto:carlos.ruizdiaz at gmail.com>> wrote: > > Looks like your problem isn't pjsip related but SIP > related. If your 30 seconds are actually exactly 32 > seconds, then I'm correct. > > Try to make your scenario work with CSIPSimple > (based on pjsip) on Android. > > Setup on it your SIP credentials, place the call and > see if it works. If it does, then you have a problem > with your code, if it doesn't, then you have a > problem with your SIP server. > > On Thu, Jan 14, 2016 at 3:57 PM, Matthew Williams > <mgwilliams at gmail.com <mailto:mgwilliams at gmail.com>> > wrote: > > Is there anyone on this list with an in-depth > understanding of the entire stack that would be > interested in doing some paid consulting? > > I have made considerable progress in getting an > app running using the swig/python bindings for > pjsua2. However, due to the limited > documentation, it is slow going -- for example, > it took quite some time to track down the cause > of segfaults to the Call object being lost from > focus. > > My current issue is related to calls that are > cancelled. It appears that if hangup is called > prior to the call entering the confirmed state, > the disconnected state is only entered some 30 > seconds later. Since I am writing a server > application, this quickly eats up call limits. > > Please feel free to reply privately. > > Thanks! > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > -- > Carlos > http://caruizdiaz.com > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > -- > Carlos > http://caruizdiaz.com > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > -- > Carlos > http://caruizdiaz.com > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
