After a long debugging session with Cedric, we managed to track down the
issue. Apparantely rtpproxy assumes that all sessions are asymetric when
using bridge mode. That's why if you are using symmetric clients, you
have to force the 's' flag, as oposted to normal scenarios.
I've updated the
Hi Razvan,
Le 26/10/2016 à 15:35, Răzvan Crainea a écrit :
Hi, Cedric!
If you double checked the PCAP and you really are missing the flow
from RTPProxy to callee, I take your word for it. Pehaps the logging
is misleading.
Now, if RTPProxy does not send any packet to the callee, this means
Hi, Cedric!
If you double checked the PCAP and you really are missing the flow from
RTPProxy to callee, I take your word for it. Pehaps the logging is
misleading.
Now, if RTPProxy does not send any packet to the callee, this means that
it doesn't get any packets from him. This means that
Hello Razvan,
Le 26/10/2016 à 13:52, Răzvan Crainea a écrit :
Hi, Cedric!
Are you sure that the flows you do not see are the ones you mentioned?
According to the logs, you do not see the RTP coming from the caller:
RTP stats: 410 in from callee, 0 in from caller
Do these stats work correctly
Hi, Cedric!
Are you sure that the flows you do not see are the ones you mentioned?
According to the logs, you do not see the RTP coming from the caller:
RTP stats: 410 in from callee, 0 in from caller
So the problem seems to be not on the private network, but on the public
one. Or there is a
I've made a new test, replacing mediaproxy "external" address by
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm trying
to do. I need to have a different address for the SIG and for the MEDIA.
Hope it helps...
Regards,
Cédric
Le
Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy (2.0.beta.20150106)
one the same server, using loopback interfaces.
--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 :
