Hello Iñaki,
 
did you fixed your issue? I'll also connect an OmniPCX pbx which maintain the session
after forward / transfer and would be interested in a working config example for the
SR/RTPproxy part. OmniPCX SIP config is clear as it's my daily business ;-)
 
thanks in advance,
Andreas

2010/2/26 Iñaki Baz Castillo <ibc@aliax.net>
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
> On 02/26/2010 03:09 PM, Iñaki Baz Castillo wrote:
> > El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
> >> Do you re-engage rtpproxy for re-INVITEs?
> >
> > Yes, the client is behind NAT so I must use RtpProxy for initial INVITE.
> > Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive
> > RTP in already working ports but from a different source, so RtpProxy
> > would reject/ignore such RTP traffic.
> >
> >> Also, have you played with
> >> force rtp proxy flags to trust public addresses?
> >
> > But that wouldn't solve the problem, am I wrong?
>
> there is a deadlock when chaining two rtpproxy. In learning mode
> rtpproxy waits for the other side to send first packet to know the ip
> and port. iirc it is r flag to avoid this.

Interesting, I'll try it and will comment the result.

Thanks.


--
Iñaki Baz Castillo <ibc@aliax.net>

_______________________________________________