[asterisk-biz] SIP RFC argument needed to refute vendor equipment behavior

[Nathan Shadle]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-biz/attachments/20120618/6375f0ff/attachment.htm>