Hi Walter, That was exactly it - I was not replying with the 487 after receiving the CANCEL. Thanks! Matthew On Fri, Jan 15, 2016 at 4:48 PM, Walter Doekes <walter+pjsip at wjd.nu> wrote: > 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 > > > > > _______________________________________________ > 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/20160115/8637c4cc/attachment.html>
