1 - I'm trying to close the UDP transport in the on_reg_state callback

    PJ_ASSERT_RETURN(pj_atomic_get(tp->ref_cnt) == 0, PJSIP_EBUSY);

1.2 - If I try to pass PJ_FALSE, then the UDP transport is smoothly

Hello, My idea is basically pass the SIP traffic through a TURN server to overcome some firewall limitations. I'm using PJSUA, registering an UDP transport using pjsua_transport_create as usual, and, when I discover a timeout 408 during the first REGISTER, my idea was to close the previously created UDP transport and register a new one. I've implemented a sip_transport_turn.c based on the sip_transport_udp.c, and during the initialization it sends an allocate request to TURN to listen to SIP packets. In the on_rx_data callback, I am checking if this is the first time I am sending packets to this destination, and, if so, I'm using the pj_turn_sock_set_perm to add permission to send data. Everything is great in theory, but I am facing a lot of problems in PJSUA code (I'm using PJSIP 2.0): 1 - I'm trying to close the UDP transport in the on_reg_state callback from pjsua_acc, using the function pjsua_transport_close; 1.1 - If I try to pass PJ_TRUE to force the destruction of the UDP transport, there is an assertion error being thrown in pjsip_transport_destroy: PJ_ASSERT_RETURN(pj_atomic_get(tp->ref_cnt) == 0, PJSIP_EBUSY); 1.2 - If I try to pass PJ_FALSE, then the UDP transport is smoothly destroyed after a while, but in this case PJSUA maintains an invalid pointer in pjsua_var structure (specifically in tpdata member). As there is no examples of real use case scenarios using PJNATH and SIP together, I'm clueless. Regards, Guilherme Balena Versiani.

 1 - I'm trying to close the UDP transport in the on_reg_state callback

     PJ_ASSERT_RETURN(pj_atomic_get(tp->ref_cnt) == 0, PJSIP_EBUSY);

 1.2 - If I try to pass PJ_FALSE, then the UDP transport is smoothly

On Thu, Jun 7, 2012 at 2:38 AM, Guilherme Balena Versiani <guibv@nymgo.com>wrote: > Hello, > > > My idea is basically pass the SIP traffic through a TURN server to > overcome some firewall limitations. > > I'm using PJSUA, registering an UDP transport using pjsua_transport_create > as usual, and, when I discover a timeout 408 during the first REGISTER, my > idea was to close the previously created UDP transport and register a new > one. I've implemented a sip_transport_turn.c based on the > sip_transport_udp.c, and during the initialization it sends an allocate > request to TURN to listen to SIP packets. In the on_rx_data callback, I am > checking if this is the first time I am sending packets to this > destination, and, if so, I'm using the pj_turn_sock_set_perm to add > permission to send data. > > Everything is great in theory, but I am facing a lot of problems in PJSUA > code (I'm using PJSIP 2.0): > > 1 - I'm trying to close the UDP transport in the on_reg_state callback > from pjsua_acc, using the function pjsua_transport_close; > 1.1 - If I try to pass PJ_TRUE to force the destruction of the UDP > transport, there is an assertion error being thrown > in pjsip_transport_destroy: > > PJ_ASSERT_RETURN(pj_atomic_get(tp->ref_cnt) == 0, PJSIP_EBUSY); > > Just to clarify, you are trying to close UDP SIP transport, not your TURN UDP SIP transport, right? The force=TRUE option, I'm afraid is not working. You should use FALSE and let pjsip destroy the transport once the reference counter is zero. > 1.2 - If I try to pass PJ_FALSE, then the UDP transport is smoothly > destroyed after a while, but in this case PJSUA maintains an invalid > pointer in pjsua_var structure (specifically in tpdata member). > > This shouldn't happen unless the transport is destroyed prematurely. Best regards Benny As there is no examples of real use case scenarios using PJNATH and SIP > together, I'm clueless. > > > Regards, > Guilherme Balena Versiani. > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >

 1 - I'm trying to close the UDP transport in the on_reg_state

     PJ_ASSERT_RETURN(pj_atomic_get(tp->ref_cnt) == 0, PJSIP_EBUSY);

 1.2 - If I try to pass PJ_FALSE, then the UDP transport is smoothly

Hello Benny, As I don't have much time to be checking the PJSIP code to make a patch, I've used another approach: -- Instead of having two transports, disconnect UDP and then connect the TURN one, I've created an "special" TURN transport that contains a UDP transport inside. This is like "inheriting" the UDP transport, in some way. -- It has an additional function, and by calling it I open the TURN and this special transport redirects the SIP traffic through the TURN server. I think this would be a "safer" way, as it is not usual for PJSIP applications to be registering/unregistering transports during the normal execution of the program. Regards, Guilherme Balena Versiani. On Wed, Jun 6, 2012 at 11:48 PM, Benny Prijono <bennylp@teluu.com> wrote: > On Thu, Jun 7, 2012 at 2:38 AM, Guilherme Balena Versiani <guibv@nymgo.com > > wrote: > >> Hello, >> >> >> My idea is basically pass the SIP traffic through a TURN server to >> overcome some firewall limitations. >> >> I'm using PJSUA, registering an UDP transport >> using pjsua_transport_create as usual, and, when I discover a timeout 408 >> during the first REGISTER, my idea was to close the previously created UDP >> transport and register a new one. I've implemented a sip_transport_turn.c >> based on the sip_transport_udp.c, and during the initialization it sends an >> allocate request to TURN to listen to SIP packets. In the on_rx_data >> callback, I am checking if this is the first time I am sending packets to >> this destination, and, if so, I'm using the pj_turn_sock_set_perm to add >> permission to send data. >> >> Everything is great in theory, but I am facing a lot of problems in PJSUA >> code (I'm using PJSIP 2.0): >> >> 1 - I'm trying to close the UDP transport in the on_reg_state >> callback from pjsua_acc, using the function pjsua_transport_close; >> 1.1 - If I try to pass PJ_TRUE to force the destruction of the UDP >> transport, there is an assertion error being thrown >> in pjsip_transport_destroy: >> >> PJ_ASSERT_RETURN(pj_atomic_get(tp->ref_cnt) == 0, PJSIP_EBUSY); >> >> > Just to clarify, you are trying to close UDP SIP transport, not your TURN > UDP SIP transport, right? The force=TRUE option, I'm afraid is not working. > You should use FALSE and let pjsip destroy the transport once the reference > counter is zero. > > >> 1.2 - If I try to pass PJ_FALSE, then the UDP transport is smoothly >> destroyed after a while, but in this case PJSUA maintains an invalid >> pointer in pjsua_var structure (specifically in tpdata member). >> >> > This shouldn't happen unless the transport is destroyed prematurely. > > Best regards > Benny > > > As there is no examples of real use case scenarios using PJNATH and SIP >> together, I'm clueless. >> >> >> Regards, >> Guilherme Balena Versiani. >> >> _______________________________________________ >> 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 > >

On Thu, Jun 7, 2012 at 9:55 AM, Guilherme Balena Versiani <guibv@nymgo.com>wrote: > Hello Benny, > > As I don't have much time to be checking the PJSIP code to make a patch, > I've used another approach: > > -- Instead of having two transports, disconnect UDP and then connect the > TURN one, I've created an "special" TURN transport that contains a UDP > transport inside. This is like "inheriting" the UDP transport, in some way. > -- It has an additional function, and by calling it I open the TURN and > this special transport redirects the SIP traffic through the TURN server. > > I think this would be a "safer" way, as it is not usual for PJSIP > applications to be registering/unregistering transports during the normal > execution of the program. > > Okay. I'm curious though, why do you need to use TURN to get pass firewall? Can't you just hide it with TLS and some non-standard port? Cheers Benny

No, my application should be aimed to run even under hard network conditions. There are some network conditions which I need to multiplex both audio and signalling in the same channel, and I will use TURN in these cases. Regards, Guilherme Balena Versiani. Em 07/06/2012 05:55, "Benny Prijono" <bennylp@teluu.com> escreveu: > On Thu, Jun 7, 2012 at 9:55 AM, Guilherme Balena Versiani <guibv@nymgo.com > > wrote: > >> Hello Benny, >> >> As I don't have much time to be checking the PJSIP code to make a patch, >> I've used another approach: >> >> -- Instead of having two transports, disconnect UDP and then connect the >> TURN one, I've created an "special" TURN transport that contains a UDP >> transport inside. This is like "inheriting" the UDP transport, in some way. >> -- It has an additional function, and by calling it I open the TURN and >> this special transport redirects the SIP traffic through the TURN server. >> >> I think this would be a "safer" way, as it is not usual for PJSIP >> applications to be registering/unregistering transports during the normal >> execution of the program. >> >> > Okay. I'm curious though, why do you need to use TURN to get pass > firewall? Can't you just hide it with TLS and some non-standard port? > > Cheers > 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 > >

On Jun 7, 2012, at 3:10 PM, Guilherme Balena Versiani wrote: > No, my application should be aimed to run even under hard network conditions. > > There are some network conditions which I need to multiplex both audio and signalling in the same channel, and I will use TURN in these cases. > In that case you might be trying to use the wrong protocol. My 2 cents. -- Saúl Ibarra Corretgé AG Projects

Long story short, you are wrong. My 2 cents back. Em 07/06/2012 10:17, "Saúl Ibarra Corretgé" <saul@ag-projects.com> escreveu: > > On Jun 7, 2012, at 3:10 PM, Guilherme Balena Versiani wrote: > > > No, my application should be aimed to run even under hard network > conditions. > > > > There are some network conditions which I need to multiplex both audio > and signalling in the same channel, and I will use TURN in these cases. > > > > In that case you might be trying to use the wrong protocol. My 2 cents. > > -- > Saúl Ibarra Corretgé > AG Projects > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >