Thank you very much for the info Benny. I think the problematic points for interoperability are 3 (should set Flow-Timer header received from server) and 4 (because server will receive less keepalives than expected and could consider the connection as failed). I'll probably try to implement then and send a patch for your consideration. I tried to use pjsip_endpt_send_raw_to_uri and got an assertion fail in os_core_unix.c Ln 1256: pj_assert(mutex->owner == pj_thread_this()); Any idea of what is the problem? G. ________________________________________ From: pjsip-bounces@xxxxxxxxxxxxxxx [pjsip-bounces at lists.pjsip.org] On Behalf Of Benny Prijono [bennylp at teluu.com] Sent: Tuesday, October 04, 2011 12:41 PM To: pjsip list Subject: Re: RFC5626 non-standard behaviour On Thu, Sep 29, 2011 at 12:57 PM, Gustavo Garcia Bernardo <ggb at tid.es> wrote: > Hi, > > I'm trying to use pjsip support of RFC5626 for TCP and I found the following inconsistencies with the standard: > > 1. PJSIP keepalives are CRLF instead of the recommended CRLFCRLF I think we do use CRLF-CRLF, it's the PJSIP_TCP_KEEP_ALIVE_DATA setting. > 2. PJSIP doesn't process the pong response from the server to decide if the connection is broken or not. That's true. I expect broken connection will be broken i.e. disconnected. > 3. keep_alive timeout for TCP is always set 90 seconds, and the value of acc.ka_interval in pjsua is only used for UDP The setting is PJSIP_TCP_KEEP_ALIVE_INTERVAL instead. For stream oriented transport, keep-alive is done at the transport level and not pjsua-lib level. > 4. Any activity on the TCP transport resets the keep_alive timer and it shouldn't True. > 5. There are no method to request sending the keepalive from the application layer (this is needed to send keepalives from an iphone app while in background) > You can use pjsip_endpt_send_raw_to_uri(), or if you have the transport pointer you can just send the keep alive data to it using PJSIP API. > Do you agree with these issues or did I misunderstand something? Are there any plans to implement it according to the spec? > We took the pragmatic approach when implementing this, and while few things may not strictly comply with the RFC, I think it should do the job. Unless there is a compatibility problem with server, I'd prefer to keep it simple this way. Thanks for the feedback! Benny > Thank you, > G. > _______________________________________________ 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 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx
