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

[Nathan Shadle]

Thanks. I will post this type on asterisk-users in the future.

'changing the destination IP of the stream' is indeed some internal behavior
of the media server. There is no SIP signaling associated with this stream
redirection.

There is indeed a gap in the RTP sequence numbering, which is affecting the
monitoring/reporting tools (they believe there is packet loss, and thus
drastically reduced MOS scores, etc). Since we use u-law and 20ms
packetization period, there's about 50 packets/second, and thus the gap in
RTP sequence numbers in the RTP headers show about a 50-sequence-number gap.

I definitely agree that it would be more appropriate to put the endpoint in
inactive or recvonly, but don't agree that the monitoring tools should be
able to "tolerate" this. They are doing their job reporting missing packets
when they see an RTP sequence number gap. The only purpose for this sequence
number is specifically to order and detect packets that are missing or
out-of-ordered, no?

Nathan

-----Original Message-----
From: asterisk-biz-bounces at lists.digium.com
[mailto:asterisk-biz-bounces at lists.digium.com] On Behalf Of Kevin P. Fleming
Sent: Monday, June 18, 2012 4:23 PM
To: asterisk-biz at lists.digium.com
Subject: Re: [asterisk-biz] SIP RFC argument needed to refute vendor
equipment behavior

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

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