VoIP Mailing List Archives

[siniypin at gmail.com]

I am a bit confused with what's going on in a following scenario.

I have a public FS server with a public conference, that clients are connecting to with my softphone. All of this softphones have STUN option enabled and working, effectively resolving client's public IP address. They also have ICE enabled (but I guess it's not relevant here, since FS doesn't do ICE). Also, media trafic is secured with SRTP.

The problem is when one client connects from port-restricted NAT into a conference he can hear sound for some time and he can be heard by other participants, but after awhile sound is gone and neither he hear anything nor he can be heard.
Where is the problem? Is it NAT, closing RTP port after some silence period from client? I tried to start conference with waste flag, but without success eventually.

The very same person can be contacted through this FS with direct call (being established in proxy_media mode) without any problems, but this is where ICE stuff starts doing its' "magic", I guess.

Maybe I should try the same with SRTP disabled? Any help would be apreciated!

Best regards, Robert.

[jason at jasonjgw.net]

RobertT <siniypin@gmail.com> wrote:

[siniypin at gmail.com]

Are there ways to escape this timeouts exchanging RTP with FS? Why didn't waste flag help? Maybe I should "flood" channel in both directions? Will CNG on a client side be a good descision? =)

[kadantsev.d at gmail.com]

ты в�е еще наблюдаешь �ту проблему?
� думал она уже решена...

�ни вей, � уже приехал и �делаю �коро воторой IP нам дл� �об�твенного STUN-�ервера.
--
Best regards,
Dmitry Kadantsev

http://www.doxwox.com - Best web meeting and online collaboration tool.


On Tue, Sep 29, 2009 at 10:32 AM, RobertT <siniypin@gmail.com (siniypin@gmail.com)> wrote:

[siniypin at gmail.com]

× ÔÏÍ ÔÏ ×ÓÅ É ÄÅÌÏ ÞÔÏ Ó ÔÏÂÏÊ ÍÙ ÜÔÕ ÐÒÏÂÌÅÍÕ ×ÒÏÄÅ ËÁË ÒÅÛÉÌÉ, Á Õ àÒÙ ÅÅ ÎÉËÏÇÄÁ ÎÅ ÂÙÌÏ. É ÔÕÔ ÎÁ ÔÅÂÅ...

[mike at jerris.com]

Most likely the client NAT is cutting off the translation due to no
traffic. This could be because the client is not sending any traffic,
regardless of settings you set on FreeSWITCH. Try disabling all vad
and dtx on your soft phone to see if this helps. Also, your email
seems to indicate that you have solved the problem for yourself and
others have not had the problem. Is anyone still experiencing this
issue?

Mike



_______________________________________________
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

[siniypin at gmail.com]

I am still experiencing problem with lost media in conference on a client behind NAT.
This is what I've done - disabled VAD on a NATed client and asked my friend to produce lots of animal sounds in order to keep channel busy. But at the end of minute sounds of wild nature disapeared again. We reproduced that without security with tcp SIP transport and got the same result.
Then I started to dig into SIP trace and this is what I found.
This client (behind NAT) recieve subsequent INVITE message from FS which seem to destroy dialog and causes client app to close media stream after a session being established normally. I performed the same call from box with public ip and saw no subsequent INVITE's from FS. How come FS sends an INVITE message to already connected client? Is it OK? Should client handle this normally?

Below is client's SIP trace:

INVITE sip:1.conference.dw@74.208.167.44:5081;transport=TLS SIP/2.0    
...
User-Agent: DoxWox SIP user agent    
..

SIP/2.0 100 Trying    
..
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-14953M    
..

SIP/2.0 407 Proxy Authentication Required    
..
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-14953M    
..

ACK sip:1.conference.dw@74.208.167.44:5081;transport=TLS SIP/2.0    
..

SIP/2.0 100 Trying    
..
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-14953M    
..

SIP/2.0 183 Session Progress    
..
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-14953M    
..

SIP/2.0 200 OK    
..
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-14953M    
..

ACK sip:1.conference.dw@74.208.167.44:5081;transport=tls SIP/2.0    
..

Finally, this message cause media stream closing
INVITE sip:1001@87.184.52.45:64183;transport=tls SIP/2.0    
Via: SIP/2.0/TLS 74.208.167.44:5081;branch=z9hG4bK8269NDyXQNjyH    
Max-Forwards: 70    
From: <sip:1.conference.dw@74.208.167.44 ([email]sip%3A1.conference.dw@74.208.167.44[/email])>;tag=vQH234QtN2U8Q    
To: <sip:1001@74.208.167.44 ([email]sip%3A1001@74.208.167.44[/email])>;tag=3a231ba86c894ceca81d5021b68d3b6c    
Call-ID: 37edc38329f64fe98c36cc0a6ddcbd9d    
CSeq: 121093810 INVITE    
Contact: <sip:1.conference.dw@74.208.167.44:5081;transport=tls>    
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-14953M    
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY    
Supported: timer, precondition, path, replaces    
Session-Expires: 120;refresher=uac    
Min-SE: 120    
Content-Type: application/sdp    
Content-Disposition: session    
Content-Length: 340    
v=0    
o=FreeSWITCH 1254396503 1254396504 IN IP4 74.208.167.44    
s=FreeSWITCH    
c=IN IP4 74.208.167.44    
t=0 0    
m=audio 27726 RTP/SAVP 103 101    
a=rtpmap:103 speex/16000    
a=rtpmap:101 telephone-event/8000    
a=fmtp:101 0-16    
a=silenceSupp:off - - - -    
a=ptime:20    
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:J6x2UgRVUY8GfbwjCuyyttrtnXnwwuWA9Pt+o3VW

[siniypin at gmail.com]

And here is a short piece of log from the server side:
...
nua(): refersh session after 62 seconds (in [55..65])...
send INVITE ...
rcv OK...
send ACK...
rcv BYE...

I see now that sdp for natted client has additional lines in OK response compared to client with public ip.
Session-Expires: 120;refresher=uas    
Min-SE: 120

How come that they differs? And how do I resolve this situation? Should client handle these refresher messages normally?

Best regards, Robert.

[siniypin at gmail.com]

Hi folks!

Suddenly I found this http://lists.freeswitch.org/pipermail/freeswitch-dev/2009-February/002015.html topic and that explains a lot.