[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] Using oRTP to send supplemental data besides t
From: |
Vadim Lebedev |
Subject: |
Re: [Linphone-developers] Using oRTP to send supplemental data besides the audio |
Date: |
Thu, 18 Dec 2008 22:53:10 +0100 |
Steve
Le 18 déc. 08 à 22:14, Steve Strobel a écrit :
Steve Strobel wrote:
I am using oRTP to send G.711u audio ... There is a small amount
of other data...that I also need to pass between those embedded
devices. I can think of at least three options for doing that...
At 09:55 AM 12/18/2008, Vadim Lebedev <address@hidden> wrote:
IMO it depends on the amount of additional data you want to send:
If it 3-4 bytes each time i'd use existing rtp session and would
send it as DTMFs
Do you mean by encoding each nibble of data I want to send as one
DTMF digit? Or do you mean using the same basic mechanism that is
used for sending DTMF, but sending a different type of data
(preferably in bigger chunks than a nibble :)? Is the mechanism
used for DTMF extensible for sending other types of data? I
obviously need to do more research about that. I wouldn't mind
having to add a non-standard extension to make it work, as long as
standard RTP endpoints would just discard the supplemental data.
Web browsers are required to ignore HTML tags they don't
understand; I was hoping for something similar in this case.
I mean encode nibble data.
Otherwise i would create a separate session, with jitter buffer
deactivated and using 16 PCM as payload type.
I can make that work, but it seems like a terrible hack. Especially
using PCM (or any other standard audio type) as the payload type,
suggesting that the payload is audio when it isn't.
If I used just the one RTP session and sent some packets with the G.
711u payload type and other packets as a different (maybe non-audio)
type, would a standard RTP endpoint ignore the non-audio packets and
continue to process the G.711u packets, or would it puke on the non-
audio packets?
There is no such thing as standard RTP endpoint.
There are RTP stacks which will ignore unknown payloads,
but there are others which will die horrible death on unknown payload.
If it would just ignore them, I could extend oRTP to de-multiplex
the streams based on their payload types. On the other hand, that
might be just as much work as setting up two RTP sessions.
You however need to be aware that in this case the data could be
lost.
I understand that RTP packets sent via UDP will not be resent if
lost. I can live with that. Are you suggesting, though, that
sending the data as DTMF would be any different?
well oRTP at least retransmit DTMF signals several times so that the
chances of loss are minimized.
Btw, if you setup a sparet oRtp session for your data using PCM as
payload you should be ewavre that first dozen of packet risk to not to
be delivered.
Rtp need some initial amount of packets to be sure that incoming data
constitute a valid RTP stream
Thanks
Vadim