Hi, now i start to better understand. I am not using STUN or ICE and in my case clients are in 2 situations: a) The client has a private ip address between a NAT Port address transalation b) The client has a public ip address but that address is firewalled (3G operator that provide a public IP address but does not let incoming connection to go trough). In that scenario i got one-way audio with only one "Auto changing port from ..." messages from FS debug log. Is there a way to force the FS not to look at the IP inside the SDP header provisioned by the SIP UA, considering the IP address always "buggy", so always not providing the right IP address configuration ? Fabio On 23/03/10 17.51, Anthony Minessale wrote:
That message is a symptom of the UA lying in it's sdp. it says one ip in the sdp but means another.
We start by sending all the media to the ip specified in the SDP because that is the only IP we know. Then there is a small window at the beginning of the call where we assume a packet sent to us where we specified in our SDP may be a packet from a mis-configured UA, so we will change our destination to that ip:port to defeat the bug in the client.
in order to engage this fix the client has to send us several packets so we can prove it's correct to change our target towards them.
On Tue, Mar 23, 2010 at 11:39 AM, Fabio Pietrosanti (naif) <lists@infosecurity.ch <mailto:lists@infosecurity.ch>> wrote:
I am having a similar problem with SIP UA based on PJSIP.
My main issue relate with sometimes having one-way audio between two peers. Exactly the same peers sometimes works, sometime does not work.
What i see is that when everything works are two statement in debug log: [INFO] switch_rtp.c:2005 Auto Changing port from ... [INFO] switch_rtp.c:2005 Auto Changing port from ...
When things does not work (one-way audio) i just see 1 line: [INFO] switch_rtp.c:2005 Auto Changing port from ...
For all calls i am using inbound-proxy-media=true .
Is the same issue you see/encounter?
Fabio
On 23/03/10 17.26, Madovsky wrote: > thanks for your answer Jason. > yes the problem is yet there. before > to submit a bug I want to be sure it's a mistake I did. > so when I set inbound-bypass-media to true, the problem disappear. > it's for sure a media problem. > A phone with a public IP ( I tested on 6 PCs) registers well, but make a rtp > timeout > A phone behind a firewall (tested on 6 PCs too) registers well and doesn't > make rtp timeout. > I stopped all IP rules like iptables etc... without success. > I'd like to understand > > Thanks >
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org