24 Apr
2010
24 Apr
'10
11:49 a.m.
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(a)aliax.net>
El Viernes, 26 de Febrero de 2010, Daniel-Constantin
Mierla escribió:
Interesting, I'll try it and will comment the result.
Thanks.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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.
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. Also, have you played with
force rtp proxy flags to trust public addresses?
But that wouldn't solve the problem, am I wrong?