Stefan Sayer <[email protected]> wrote: > as we are (currently) handling RTP relay in user space, we can implement the > following solutions > - stay in 'passive' mode, i.e. switch destination address any time RTP is > received from a different port > - stay in 'passive' mode for e.g. 1 second after call is established, which > should be enough to get over 'leaked' RTP, and still does not mean we need > to compare addresses every time a packet is received
Thanks for your time to answer. Do you think favoring the SDP advertised mediastream is unnecessary in the case where multiple streams are received, but no parallel forks exist? I would assume that (in the reported mediaproxy case) audio clipping could be avoided if the stream advertised in SDP is preferred over others. You mention that RTP is /currently/ handled in user space and also on the roadmap there is item "relay mode without decoding RTP for b2bua". Is that something where existing rtpproxy or mediaproxy nodes could be utilized? Would it be feasible for SEMS B2BUA to implement rtpproxy or mediaproxy protocol? And BTW: my activity comes from pure curiosity, I am not experiencing any ghost mediastreams. -- Mikko _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
