[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re : [Linphone-developers] The possibility of expanding the program.
From: |
Ogogon !!! |
Subject: |
Re: Re : [Linphone-developers] The possibility of expanding the program. |
Date: |
Thu, 14 Oct 2010 15:59:13 +0400 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ru; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 |
14.10.10 14:24, Aurelien Bouin wrote:
Hi,
Good afternoon, Aurelien!
It is a very very interesting feature
I hope that is not irony. (I, unfortunately, not very well feel the
nuances of the English language.)
but you are talking about sending or receiving the sound(oRTP) considering
SIP signalization(which one ? SIP MESSAGE ?)
I believe that the half-duplex control channel must be carried out not
by means of RTP, but the means of SIP.
First, the SIP has mechanisms for receiving information about the
connection when it was set, and RTP, as I recall, no. And in any case,
when connecting to the peer, we need to know it is a duplex or half
duplex. Depends on it, how we communicate with him.
Secondly, SIP, by definition, an extensible protocol connectivity and
make it add a conceptually more correct and technically simpler.
Third, if the extension of SIP commands could not be avoided, it is
hardly worth upgrading yet, and RTP. In addition, by means of SIP, we
can fully realize all the required functionality to us.
I don't think that you can do that with a plugin ... or you will have to
develop your own audio codec that could handle message + audio payload that
come from oRTP...
Here is another argument in favor of the control half-duplex channel
need to be implemented by means of SIP instead of RTP.
Now, several American companies produce equipment for the control
half-duplex radios via VoIP, but control signals to pass through it
retouched RTP, but in my opinion, it is fundamentally wrong. These
manufacturers have started to adapt to specific needs of the most
similar existing developments, in failing to follow existing standards.
I and a group of colleagues to create a solution for amateur radio.
We believe the correct observance of standards and an architectural logic.
Such a decision requires client software, and it should work as a
full-duplex, as well as for half-duplex connections.
What do you think simon ?
Excuse me, but what is simon? (Unfortunately, my English is far from
perfect.)
Aurelien
Ogogon.