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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20160114/097a464c/attachment.html>
