Isn't PJSUA really the SIP application that sits on top of the PJ-SIP stack, so wouldn't it be a relevant feature for them to implement? They already handle STUN, ICE, etc so it seems like it's not that far away from handling this case. In my case I just need a new INVITE to go out with the correct new external IP address (i.e. re-STUN) and then those ports to be opened properly on the outside of my new NAT router. I can get this to work with mjSIP fairly easily, but since mjSIP doesn't do media handling I thought PJSIP would be a better all around solution. How did you handle this with your application? Thanks! > From: " R?gis Montoya " <r3gis.3r@gmail.com> > To: pjsip list <pjsip@lists.pjsip.org> > Subject: Re: [pjsip] Proper way to handle Ip address changes in > Android > Message-ID: <5033B83A.3070408@gmail.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hi Shaun, > > From my experience on CSipSimple it's not something that is relevant of > the sip stack. > Besides, it's not simple to support on android and may depend on your > approach on that. Depending on whether you'd like to support VPN > connection /for example/ approach will be different. It will also be > different depending on what android version you'd like to support. > You can get inspired on what's done on Android stock SIP application... > BTW, you'll see it's also not responsibility of the sip stack but of the > sip application to decide whether to restart or not the sip stack in the > implementation from Google too... so I think that's not a bad idea ;). > > Best regards, > R?gis > > On 21/08/2012 18:24, Shaun Clark wrote: > > When the Android app goes between wifi and 3g the call does not > > automatically switch, I can call 'n' which re-does the NAT, but then > > looking at this page: http://trac.pjsip.org/repos/wiki/IPAddressChange > > none of these approaches seem to work. Since mobile phones often > > switch back and forth between wifi and 3g/mobile this seems like a > > great feature to build into pjsip. Is there a way to easily handle > > this now on Android? Thanks! > > > > Shaun > > > > > > _______________________________________________ > > Visit our blog: http://blog.pjsip.org > > > > pjsip mailing list > > pjsip@lists.pjsip.org > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >

Hi, Of apjsua maybe, not of pjsua. apjsua like other platform sample it is a sample. None of other supported platform handles network changes inside the stack. Maybe if one day there is a module to handle network changes cross platform an implementation for android could take place. In my opinion, it's really not easy to handle on android. Just an example to give you an idea : Android 4.0 doesn't notify anymore for VPN changes. It does between 2.1 and 2.3 through a private API. Android 1.6 and 2.2 doesn't broadcast the mobile data network changes at the same time. It's more frequent on one than on the other. Add to that new android version that are able to support tethering, ethernet connection etc... In CSipSimple I adopted globally the approach of the stock android SIP app developped by google that is integrated in android source code. Read it, it's very instructive. And again, you'll see, it's not the sip stack that does that ! It's the application. The approach in my case is slightly tweaked for several reason : - it is able to support vpn changes by polling the network route files of unix file system. It's an user setting to choose polling time of that. - it has not same policy while you are in call and while not. When not in call it restart the stack, when in call it does nothing and most of the time other stuff like stun and the rtp address changes does the trick. Last point very important that could convince you. In CSipSimple, user can configure that the application doesn't run depending on the network we are connected to. This would be impossible with an approach where things are managed by the stack (or would be messy). There is also different settings dependings on network (for example codec order). So definitely a good thing that networks changes are managed by the application. I'm not telling some entry points to notify the stack about networks changes are not missing in pjsua (and that the stack should update everything properly regarding the fact it changes). I'm telling that what should monitor the network is not pjsua. It could be a dedicated library, some hand made things depending on application needs etc. On 21/08/2012 18:46, Shaun Clark wrote: > Isn't PJSUA really the SIP application that sits on top of the PJ-SIP > stack, so wouldn't it be a relevant feature for them to implement? > They already handle STUN, ICE, etc so it seems like it's not that far > away from handling this case. > > In my case I just need a new INVITE to go out with the correct new > external IP address (i.e. re-STUN) and then those ports to be opened > properly on the outside of my new NAT router. I can get this to work > with mjSIP fairly easily, but since mjSIP doesn't do media handling I > thought PJSIP would be a better all around solution. > > How did you handle this with your application? > > Thanks! > > > From: " R?gis Montoya " <r3gis.3r@gmail.com> > > To: pjsip list <pjsip@lists.pjsip.org> > > Subject: Re: [pjsip] Proper way to handle Ip address changes in > > Android > > Message-ID: <5033B83A.3070408@gmail.com> > > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > > Hi Shaun, > > > > From my experience on CSipSimple it's not something that is relevant of > > the sip stack. > > Besides, it's not simple to support on android and may depend on your > > approach on that. Depending on whether you'd like to support VPN > > connection /for example/ approach will be different. It will also be > > different depending on what android version you'd like to support. > > You can get inspired on what's done on Android stock SIP application... > > BTW, you'll see it's also not responsibility of the sip stack but of > the > > sip application to decide whether to restart or not the sip stack in > the > > implementation from Google too... so I think that's not a bad idea ;). > > > > Best regards, > > R?gis > > > > On 21/08/2012 18:24, Shaun Clark wrote: > > > When the Android app goes between wifi and 3g the call does not > > > automatically switch, I can call 'n' which re-does the NAT, but then > > > looking at this page: > http://trac.pjsip.org/repos/wiki/IPAddressChange > > > none of these approaches seem to work. Since mobile phones often > > > switch back and forth between wifi and 3g/mobile this seems like a > > > great feature to build into pjsip. Is there a way to easily handle > > > this now on Android? Thanks! > > > > > > Shaun > > > > > > > > > _______________________________________________ > > > Visit our blog: http://blog.pjsip.org > > > > > > pjsip mailing list > > > pjsip@lists.pjsip.org > > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > >

Hi All, First I know that the the android support of Pjsip only supports Audio. * Audio works fine. * I have enabled the video support was able to get the video call running successfully with some hacks * The major issue I noted was for the video rendering The issue is as follows * The video call starts with resolution of 720x480 * After the sip media negotiation and when the frame is decode, I get a decoding format change indication the new resolution is 640x480 * At this instant in the rendering callback in file vid_port.c , in function client_port_event_cb(), pjmedia_vid_port_stop(vp) is called. * In pjmedia_vid_port_stop(vp) function, we stop the clock pjmedia_clock_stop(vp->clock); * Inside pjmedia_clock_stop(vp->clock) , in file clock_thread.c * pj_thread_join(clock->thread) is called, this function never returns, its just hangs due to which the pjmedia_vid_port_start() for rending is never called * Hence the video renedring thread never starts. As a hack/work around I did not call the pjmedia_clock_stop(vp) in pjmedia_vid_port_stop(vp) function, by doing this everything works fine. I am not sure whats the issue here and why pj_thread_join((clock->thread) is stuck I also noted that some concurrency issue is fixed and all this code was added in ticket http://trac.pjsip.org/repos/ticket/1394 I really appreciate if some could help me to fix this or analyze if for android anything needs to be done. Thanks and regards, Deepak