linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Using oRTP to send supplemental data besides t


From: Steve Strobel
Subject: Re: [Linphone-developers] Using oRTP to send supplemental data besides the audio
Date: Thu, 18 Dec 2008 14:14:42 -0700


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.

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? 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?

Thanks
Vadim

Thanks for the reply and your insights,

Steve



---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:address@hidden





reply via email to

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