Hi, For now pjsip KA mechanism for UDP sig is to send keep alive packets only on the registration stream. When pjsip make an INVITE there is not such a mechanism for control channel. - At least I didn't found one ;) -. The problem is that some users reported me that with some NAT topology, the control channel gets cut as the NAT hole is closed. In consequence, the server or remote side is not able to send the BYE to the client. As far as I can understand from the code, this problem only affect UDP cause for TCP it is managed at transport level and KA should be sent regardless the kind of control channel it is. Is there some planned enhancement about that? Or is there another way to solve this problem? For reference the initial report on CSipSimple project : http://code.google.com/p/csipsimple/issues/detail?id=1347 Best regards, Régis

Hi Regis, On Nov 10, 2011, at 10:54 AM, Régis Montoya wrote: > Hi, > > For now pjsip KA mechanism for UDP sig is to send keep alive packets only on the registration stream. When pjsip make an INVITE there is not such a mechanism for control channel. - At least I didn't found one ;) -. > > The problem is that some users reported me that with some NAT topology, the control channel gets cut as the NAT hole is closed. In consequence, the server or remote side is not able to send the BYE to the client. > > As far as I can understand from the code, this problem only affect UDP cause for TCP it is managed at transport level and KA should be sent regardless the kind of control channel it is. > Is there some planned enhancement about that? Or is there another way to solve this problem? > > For reference the initial report on CSipSimple project : http://code.google.com/p/csipsimple/issues/detail?id=1347 > Usually servers take care of this. One way to do it is by sending in-dialog OPTIONS requests in order to detect if the remote endpoint is still there. Of course, you could do it in the client as well. Regards, -- Saúl Ibarra Corretgé AG Projects

2011/11/10 Régis Montoya <r3gis.3r@gmail.com> > Hi, > > For now pjsip KA mechanism for UDP sig is to send keep alive packets only > on the registration stream. When pjsip make an INVITE there is not such a > mechanism for control channel. - At least I didn't found one ;) -. > > I think when you're behind NAT, you should always send the call via the server (i.e. not directly to callee). If you call direct, your Contact URI will be wrong if you're behind symmetric NAT. And anyway your incoming call will also come from the server, so doing it this way creates a good symmetry there between incoming and outgoing calls. At least this is the model that I've thought about when doing the KA. Benny

 Hi,

 For now pjsip KA mechanism for UDP sig is to send keep alive
 packets only on the registration stream. When pjsip make an INVITE
 there is not such a mechanism for control channel. - At least I
 didn't found one ;) -.

Ok, Thanks all for the reply. Indeed it makes sense for mainstream use cases. So I think that the feature should rather be a pjsip plugin (or an app feature) that would be able to send keep alive OPTION as Saúl said. It will be active if the call is established from a local account or an account without sip proxy. I'll try to do that on my side and I'll ask if I need help ;). Thx, Regards, Régis On 10/11/2011 12:36, Benny Prijono wrote: > 2011/11/10 Régis Montoya <r3gis.3r@gmail.com <mailto:r3gis.3r@gmail.com>> > > Hi, > > For now pjsip KA mechanism for UDP sig is to send keep alive > packets only on the registration stream. When pjsip make an INVITE > there is not such a mechanism for control channel. - At least I > didn't found one ;) -. > > > I think when you're behind NAT, you should always send the call via > the server (i.e. not directly to callee). If you call direct, your > Contact URI will be wrong if you're behind symmetric NAT. And anyway > your incoming call will also come from the server, so doing it this > way creates a good symmetry there between incoming and outgoing calls. > At least this is the model that I've thought about when doing the KA. > > Benny > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

Use a timer to send inside dialog request outside to SIP server is better than SIP server call checking. Some NAT devices still will cut mapping if only sequence packets first from outside. regards, Gang 2011/11/11 Régis Montoya <r3gis.3r@gmail.com>: > Ok, > Thanks all for the reply. > > Indeed it makes sense for mainstream use cases. > > So I think that the feature should rather be a pjsip plugin (or an app > feature) that would be able to send keep alive OPTION as Saúl said. > It will be active if the call is established from a local account or an > account without sip proxy. > I'll try to do that on my side and I'll ask if I need help ;). > > Thx, > Regards, > Régis > > > On 10/11/2011 12:36, Benny Prijono wrote: > > 2011/11/10 Régis Montoya <r3gis.3r@gmail.com> >> >> Hi, >> >> For now pjsip KA mechanism for UDP sig is to send keep alive packets only >> on the registration stream. When pjsip make an INVITE there is not such a >> mechanism for control channel. - At least I didn't found one ;) -. >> > > I think when you're behind NAT, you should always send the call via the > server (i.e. not directly to callee). If you call direct, your Contact URI > will be wrong if you're behind symmetric NAT. And anyway your incoming call > will also come from the server, so doing it this way creates a good symmetry > there between incoming and outgoing calls. At least this is the model that > I've thought about when doing the KA. > >  Benny > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >