Thanks for sharing your findings, Samuel. I've finally solved the issue. I'm not sure if we have the same issue though. In my case, it turned out that I was querying for the call status too late. I have my own event/subscriber system that I use to communicate call events to my app. What I originally did was only store the call_id in the event payload. The idea is to leave the subsystems that are interested in those events to query for the state on-demand. When the event eventually reaches its subscriber (who could be on a different thread), the call might have already been disconnected, so the call_id becomes invalid, and hence, when the state is quered, it is PJSIP_INV_STATE_NULL. Essentially, the problem is, I was querying for the call state too late. What I now do is query for the call state immediately after the pjsip callback is triggered, and I include it in the event payload. This is a much better approach anyways (and more correct). Hope this helps you. Dia On Sun, Jun 5, 2011 at 3:58 PM, Samuel Vinson <samuelv at laposte.net> wrote: > Hello, > > I continued my investigation. I made my tests with OpenSIPS 1.6.3-notls and > pjsip svn branch 1.x > > The issue appears when pjsip (iPhone) calls only. And not when the pjsip > (iPhone) receives a call. > In fact in our case we place a call with many codecs, so the message size > is bigger than 1300 bytes. And the RFC 3261 tells that we have to switch to > TCP (extract from 'sip_config.h'/'sip_util.c') > > * RFC 3261 section 18.1.1: > * If a request is within 200 bytes of the path MTU, or if it is larger > * than 1300 bytes and the path MTU is unknown, the request MUST be sent > * using an RFC 2914 [43] congestion controlled transport protocol, such > * as TCP. > > In the next messages, the server and device continue to use TCP. And in > this case the server doesn't send BYE message. > I don't know: > - whether the server has to continue using TCP, and not UDP, > - why the server doesn't send BYE message with TCP connection > > > For the moment we have several solutions > - reduce the number of codec > - use compact form (global variables > pjsip_use_compact_form/pjsip_include_allow_hdr_in_dlg/pjmedia_add_rtpmap_for_static_pt) > - increase the UDP size threshold (define PJSIP_UDP_SIZE_THRESHOLD) > - force to use UDP (define PJSIP_DONT_SWITCH_TO_TCP) > > If someone has an other idea or an opinion/advice, I'm interested. > > Regards > > Samuel > > Le 02/06/11 23:57, Samuel Vinson a ?crit : > > Hello, > > I confirm your issue, and it's present in ipjsua too. > > But it's very weird, because: > - if the iphone calls someone, and someone ends the call, the > PJSIP_INV_STATE_DISCONNECTED message is not triggered by the iPhone > - if someone calls the iphone, and someone ends the call, the BYE > message is triggered by the iPhone. > > I use the last version of svn branch 1.x. > > Regards > > Samuel > > Le 01/06/11 09:14, Dia Kharrat a ?crit : > > Hi, > > We're implementing a voip-based iphone app, and I'm facing a situation > where I'm not receiving the call state PJSIP_INV_STATE_DISCONNECTED event > when the callee disconnects the call (on a PSTN). When I tried testing out > the ipjsip sample iphone app provided in the SDK, I noticed that it receives > the disconnect event properly. So, it seems like I'm missing something in my > code. Comparing how the sample app does things did not yield anything that > stands out from how we're using pjsip. Does anyone happen to know why > PJSIP_INV_STATE_DISCONNECTED would not be triggered? I receive the other > events properly, so it's very strange. Any pointers as to where to look > would be appreciated. > > Thanks, > Dia > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing listpjsip at lists.pjsip.orghttp://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing listpjsip at lists.pjsip.orghttp://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/20110605/f9e937c5/attachment.html>
