On 06/06/2013 09:27 AM, Khoa Pham wrote: > @Andy: thanks for your reply > > 1. What if the 2 messages/DTMFs come at the same time? How do I know who > wants to talk? > 2. What is the message/DTMF is lost, and he (the one sending the > message/DTMF) talks, because he assumes his message/DTMF has reached the > destinations > 3. Do we need a center server for push to talk ? > > > Hello! Concurrency should be no problem if you serialize the events. The first request that makes it to the business logic then wins. With the PJ callbacks you can see on which call/stream the event has been received. What exactly is your use-case? I implemented PTT because I needed to (un-)key a radio device. If multiple clients press PTT at the same time, the first request that reaches the application will be granted, all other requests will be denied. The next thing I did was to implement a PTT timeout (kind of "max speak time") after which PTT will be released automatically if no PTT-OFF request has been received in the meantime. I also implemented an audio packet timeout, that is: If I don't receive RTP packets from the PTT holder for a given time, I release PTT. With SIP MESSAGE (and depending on your setup) you should get a 408 response code (request timeout) if the message couldn't be delivered (in which case the SIP call should also fail and be hung up). I guess SIP MESSAGE can be regarded as "reliable" since the SIP stack retries to deliver the message if no response is received from the remote peer. Hope this helps; Regards
