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 > 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> > 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> 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> 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> 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> 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 >>>>>> 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 >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Carlos >>> http://caruizdiaz.com >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> _______________________________________________ >> 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 >> >> > > > -- > Carlos > http://caruizdiaz.com > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20160114/1f50962f/attachment.html>
