[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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]