All,
We have a vendor which insists that the standards don't forbid this, so they won't change the behavior, but it simply defies the intent of the RFC in my opinion. SIP dialogs set up two RTP streams between (for all intents) two endpoints and a media server (which mixes the audio and sends to a "conference-in" recording server, but that's not relevant unless we dig into the RTP standard). Early in the call, in order to play a tone/message to one of the endpoints, the media server plays the tone Endpoint A while simultaneously putting RTP Stream B (to Endpoint B) in a loopback state (by changing the destination IP of the stream to itself) so no audio is played to Endpoint B, and after 1s or so re-point RTP stream to Endpoint B (by changing back the destination IP). The effect is this: Monitoring and reporting tools see the initial RTP packets with consecutive sequence numbers, which disappear for ~1s, then reappear with incremented sequence numbers. thus appearing to the monitoring/reporting tools as 1s of packet loss. I'm having difficulty providing solid RFC statements which tell this vendor that they're doing something (changing the destination IP address during the call) which violates the entire point of the RTP sequence number (which is to identify packet loss), and then vendor is being obtuse. Can anyone provide an argument which can be used here? Nathan
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
