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

[Kevin P. Fleming]

On 06/18/2012 02:02 PM, Nathan Shadle wrote:
> 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.

This really should be on asterisk-users, not asterisk-biz, but we can 
handle it here too.

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

What does 'changing the destination IP of the stream' mean? Is this some 
internal action happening in the media server, or is there some SIP 
signaling occurring with Endpoint B?

When the media stream restarts, is there a gap in the RTP sequence 
number/timestamps, or was there just a gap in time and the sequence 
numbers/timestamps continue from where they stopped?

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

I don't believe you'll find anything in any RFC that mandates that an 
RTP stream's sender is obligated to continuously send RTP frames. It 
would certainly make a lot more sense for the media server to switch the 
media stream to 'inactive' or 'recvonly' via SIP signaling, but in spite 
of that, the RTP implementations in Endpoint B and the 
monitoring/reporting tools should be able to tolerate this behavior.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org