Re: [Turnserver-devel] Allocate Requests are timed out in TCP mode

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

OK. That means implementation is correct. When calls reach 30-40 on client
I start getting Timeout to Allocate requests. I am able to connect to Turn
port though (I used Telnet to that port and it connected without delay).
At  this point no new allocation is success all time out . It keeps timing
out even if existing realy stop (As calls are disconnected) untill only few
active relays are there ..then after around 10 mins again allocation is
successful.

Is there any User memory limitation may be there?

Regards

John

On Tue, Dec 4, 2012 at 12:34 AM, Sebastien Vincent <se...@ji...> wrote:

>  Hi,
>
> See inline.
>
> Le 30/11/2012 23:17, John Nash a écrit :
>
> Dear Seb,
>
> Did you get time to go over my mail?
>
> John
>
> On Sat, Nov 24, 2012 at 8:24 PM, John Nash <joh...@gm...> wrote:
>
>> Hello Sebastien,
>>
>> Thank you for the reply. I am not much of a programmer but I am trying
>> learn your code and will see if anything I can do to improve. But for this
>> issue I am not too sure if it is because of some problem in the code (I
>> could see one thread where Bill Clark tested it with test client in this
>> post<http://sourceforge.net/mailarchive/forum.php?thread_name=4F679171.5090700%40jitsi.org&forum_name=turnserver-devel>).
>> I will share some of the details before you invest time in code. Perhaps
>> this could be implementation issue or issue in client.
>>
>> I am using pjsip as SIP client and it has a Turn-client module.  As i
>> explained in previous mail my desired network is...
>>
>> Turn Client <------------------>TCP Control
>> Messages<--------------->Turnserver
>> Turn Client<-------------------->TCP Relay Data<----------------------->
>> TurnServer<-------------->UDP Relay to Peer<------------>UDP Based RTP
>> Server
>>
>> I expect that STUN control requests will go to turnserver TCP port 5743
>> and turnserver will respond back with relay IP and port. I assumed it will
>> provide us 1 TCP IP:port and 1 UDP IP:port where End peer will be informed
>> with UDP IP:port so that it can send UDP data to turn server. While the TCP
>> IP:port will be used by Turn client to relay RTP data over TCP to
>> turnserver which in turn will relay to end RTP Server over UDP.
>>
>
> No, TURN will allow you to allocate one IP:port (by allocate request of
> course) for the remote peer only.
>
>
>
>> But when I test, I see different flow ....
>>
>> 1- Client send Allocation requests on control socket 5743 (Allocation
>> Request
>> STUN Allocate request
>>  Hdr: length=128, magic=2112a442, tsx_id=000012442cd672ae00294825
>>  Attributes:
>>   REQUESTED-TRANSPORT: length=4, value=285212672 (0x11000000)
>>   SOFTWARE: length=12, value="pjnath-2.0.1"
>>   USERNAME: length=5, value="Test"
>>   REALM: length=10, value="domain.org"
>>   NONCE: length=48,
>> value="50b0e8610000000081e88b59fb4a98fb6595134f97372287"
>>   MESSAGE-INTEGRITY: length=20,
>> data=4f3282e29c6681f1a284d3bdb9e0b43cf86d8d65
>>
>> 2- Receives two back to back Allocation success responses
>> --- begin STUN message ---
>> STUN Allocate success response
>>  Hdr: length=84, magic=2112a442, tsx_id=000012442cd672ae00294825
>>  Attributes:
>>   XOR-RELAYED-ADDRESS: length=8, IPv4 addr=31.193.168.4:21193
>>   LIFETIME: length=4, value=1800 (0x708)
>>   XOR-MAPPED-ADDRESS: length=8, IPv4 addr=117.199.208.17:3971
>>   SOFTWARE: length=14, value="TurnServer 0.7"
>>   MESSAGE-INTEGRITY: length=20,
>> data=ff7ceb2f630845d012532703302e1eface20159e
>>   FINGERPRINT: length=4, value=3828074744 (0xe42bc8f8)
>> --- end of STUN message ---
>> and
>> --- begin STUN message ---
>> STUN Allocate success response
>>  Hdr: length=84, magic=2112a442, tsx_id=0000124469525f9000294826
>>  Attributes:
>>   XOR-RELAYED-ADDRESS: length=8, IPv4 addr=31.193.168.4:22073
>>   LIFETIME: length=4, value=1800 (0x708)
>>   XOR-MAPPED-ADDRESS: length=8, IPv4 addr=117.199.208.17:3974
>>   SOFTWARE: length=14, value="TurnServer 0.7"
>>   MESSAGE-INTEGRITY: length=20,
>> data=a82fc0fa21120e26cd65eaedb93d40710f28eb75
>>   FINGERPRINT: length=4, value=804869213 (0x2ff9545d)
>> --- end of STUN message ---
>>
>> 3- My Turn client sends a permission request to Turnserver to allow End
>> RTP Server to send data to one of the allocated ports above and gets a
>> success response.
>>
>> 4- Clients starts relaying RTP data to TCP control socket 5743 !!!...I
>> expected client to use one allocated by turnserver.
>>
>
> No client will always send to the Turnserver listen port (either via Send
> message or channel). The allocated IP:port is only used to inform remote
> peer of the allocated address so that it can send packet to the client.
>
>
>  So if i have 30-40 relays each and everyone is trying to relay to TCP
>> port 5743.
>>
>
> Yes, is it chocking ? A webserver sends packets to all of its clients with
> source port 80/443.
>
> Regards,
> --
> Seb
>
>
>
>>
>> Regards
>>
>> John
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Nov 23, 2012 at 11:29 AM, Sebastien Vincent <se...@ji...>wrote:
>>
>>>  Hi John,
>>>
>>> Sorry for delay.
>>>
>>> So if you have 40 to 50 active relays it means you have 80 to 100 opened
>>> sockets (UDP and TCP) and, I think, there is a lot of traffic, right ?. Can
>>> you see if CPU usage of turnserver process is "normal" and check also your
>>> bandwidth of your network cards. BTW On which machine/hardware do you run
>>> turnserver ?
>>>
>>> It could also be that the socket event loop has problem to scale. I
>>> quickly check and I see we can optimize it:
>>> - a little bit with tuning select() loop (I can see this maybe this
>>> week-end);
>>> - provides a socket event loop abstraction which uses the best API to
>>> use (epoll for Linux, kqueue for *BSD, select() for others, ...) either by
>>> coding it directly or uses libevent (it requires more work and I don't know
>>> if I will have the time in the following months).
>>>
>>> Regards,
>>> --
>>> Seb
>>>
>>> Le 21/11/2012 13:19, John Nash a écrit :
>>>
>>>
>>> I am using turnserver ver 0.7 in TCP mode. SIP Clients are communicating
>>> with turnserver over TCP for all STUN and TURN Relay messages while
>>> communication with peer is being done over UDP.
>>>
>>> It works fine till approximately 40-50 active turn relays (Active calls)
>>> but after that we start getting "timeout" for "Allocate Requests" and again
>>> we start getting responses after approx 10 min of idle time. On turn server
>>> log i do not see any unusual message like error or something related to any
>>> issue.
>>>
>>> My ulimit is set as 999999 and i compiled with ./configure
>>> --enable-fdsetsize=999999 option. I am using a single user for all my Turn
>>> clients . I have following options set in the config file
>>> ## Max relay per username.
>>> max_relay_per_username = 9950000
>>>
>>> ## Allocation lifetime.
>>> allocation_lifetime = 1800
>>>
>>> ## Allocation bandwidth limitation (in KBytes/s).
>>> ## 0 value means bandwidth quota disabled.
>>> bandwidth_per_allocation = 1024
>>>
>>> ## Restricted user bandwidth (in KBytes/s).
>>> ## 0 value means bandwidth limitation disabled.
>>> restricted_bandwidth = 1024
>>>
>>>
>>> Apart from that everything is default. What might case this strange
>>> issue?
>>>
>>> One more information I would like to add is...My turn client is sending
>>> turn relay data to Server TCP port 5743 (Which is the Turn TCP listen port)
>>> But should my client not send relay data (RTP) to the port which I got from
>>> Allocation Success Response??..am doing something very wrong?
>>>
>>> tcp_port = 5743
>>>
>>> Regards
>>>
>>> John
>>>
>>>
>>>
>>>  ------------------------------------------------------------------------------
>>> Monitor your physical, virtual and cloud infrastructure from a single
>>> web console. Get in-depth insight into apps, servers, databases, vmware,
>>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>>> Pricing starts from $795 for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov
>>>
>>>
>>>
>>> _______________________________________________
>>> Turnserver-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>>>
>>>
>>>
>>
>
>