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...
The more I think about this idea, the more I like it. I could
provide a "compatibility mode" for use with other RTP devices. But
on our devices, it might be fairly easy to implement and should
require no changes to oRTP.
When sending data, I would first have to call
rtp_session_set_send_payload_type(), then restore it before sending
audio again.
On the receiving end, the docs on
rtp_session_set_send_payload_type() say, "For payload type in
incoming packets, the application can be informed by registering for
the "payload_type_changed" signal, so that it can make the necessary
changes on the downstream decoder that deals with the payload of the
packets." My "downstream decoder" could use that signal to switch
whether the received data was handled as audio or data, effectively
demultiplexing it. Does anyone see a problem with that method?
Thanks for any input,
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