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: [email protected] | SIP: [email protected] | 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
