with tshark I get this while I send audio :
 

121.702216 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 5149 Destination port: netsupport
121.715222 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 28922 Destination port: 50644
121.735275 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 28922 Destination port: 50644
121.755342 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 28922 Destination port: 50644
121.775356 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 28922 Destination port: 50644
121.795370 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 28922 Destination port: 50644
121.815371 pu.bl.ic.ip1 -> pu.bl.ic.ip2 UDP Source port: 28922 Destination port: 50644
121.819114 Silicom_0b:00:c3 -> Silicom_0b:00:c3 LLC I, N(R)=0, N(S)=0; DSAP NULL LSAP Individual, SSAP NULL LSAP Command
121.819132 Silicom_0b:00:c3 -> Silicom_0b:00:c3 LLC I, N(R)=0, N(S)=0; DSAP NULL LSAP Individual, SSAP NULL LSAP Command
121.819136 Silicom_0b:00:c3 -> Silicom_0b:00:c3 LLC I, N(R)=0, N(S)=0; DSAP NULL LSAP Individual, SSAP NULL LSAP Command

and indeed, no UDP signal if I stop the audio.

 

----- Original Message -----
From: Anthony Minessale
To: freeswitch-users@lists.freeswitch.org
Sent: Tuesday, March 23, 2010 1:52 PM
Subject: Re: [Freeswitch-users] rtp timeout yet

vad means voice activity detection meaning when you do not speak it does not send rtp
you can easily test that by running tshark on your shell and see if the packets stop flowing when you don't talk.

rtp-timeout-sec is how many sec to tolerate no rtp (it should be a very high value because it's not madatory to send rtp and session timers is a better way to make sure a call is still up)

rtp-hold-timeout-sec is an alternate most likely even higher value to use while the call is in a held state assuming you know there will be no audio during this time it's more acceptable to have a higher number than the regular timeout.



On Tue, Mar 23, 2010 at 12:33 PM, Madovsky <infos@madovsky.org> wrote:
No it doesnt' seem to use vad, unless you can call vad to another standard name....
----- Original Message -----
Sent: Tuesday, March 23, 2010 1:09 PM
Subject: Re: [Freeswitch-users] rtp timeout yet

your client probably has vad enabled which is a feature that stops the rtp when you are not talking.
one thing you can do is disable or increase the duration of that rtp timeout on your sip profile settings.




On Tue, Mar 23, 2010 at 11:58 AM, Madovsky <infos@madovsky.org> wrote:
Holly sh....! , I found the problem !
I didn't know that the fact I don't plug a mic on the legA and talk in it
can causes a rtp timeout !!!!
so I have a question : what's happened if in a conversation  the legB talks
talks and talks
but legA listens and don't say anything longer as the rtp timeout ? :D
I tried it, and indeed, there's an rtp timeout everytime I stop to talk.




----- Original Message -----
From: "Madovsky" <infos@madovsky.org>
Sent: Tuesday, March 23, 2010 12:26 PM
Subject: Re: [Freeswitch-users] rtp timeout yet


> 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
>
>
>
> ----- Original Message -----
> From: "Jason White" <jason@jasonjgw.net>
> To: <freeswitch-users@lists.freeswitch.org>
> Sent: Tuesday, March 23, 2010 4:32 AM
> Subject: Re: [Freeswitch-users] rtp timeout yet
>
>
>> Madovsky <infos@madovsky.org> wrote:
>>> to be sure I'm silly I downgraded from trunk 17001
>>> and rtp timeout disappeared.
>>
>> Try the latest trunk. If the problem still occurs, capture SIP traces and
>> submit a bug report, making sure the configurations are identical.
>>
>>
>> _______________________________________________



--
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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@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

_______________________________________________
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




--
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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@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