[Home]

Summary:ASTERISK-24127: chan_sip option rtpkeepalive results in comfort noise packets being sent despite flowing RTP - resulting in audible interruptions to audio
Reporter:alexr1 (alexr1)Labels:
Date Opened:2014-07-26 07:25:42Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Resources/res_rtp_asterisk
Versions:11.11.0 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:I was experiencing minor audio clipping/interruptions and when I did a packet capture I found an RTP Comfort Noise packet corresponding with each interruption (PT=comfort noise). An easy fix is to disable rtpkeepalive.

In sip.conf, rtpkeepalive specifies the number of seconds of no rtp activity before sending a comfort noise rtp packet as a keep alive. In some cases, Asterisk sends one in the middle of rtp streams (It seems to send it to both parties simultaneously, too).

directmedia=no, so all rtp traffic is being handled by both asterisk servers.

Interruptions every 10 seconds:
AST11 Playing MOH <alaw> AST11 <alaw> SIP Phone

No Interruptions when transcoding takes place:
AST11 Playing MOH <alaw> AST11 <ulaw> SIP Phone
AST11 Playing MOH <ulaw> AST11 <alaw> SIP Phone

Unfortunately I don't have time to help further isolate the issue on our production system - mainly posting this so that someone else can find it if they're looking for a solution!
Comments:By: Rusty Newton (rnewton) 2014-07-28 09:36:21.957-0500

Thanks for the note. If I can't reproduce this easily I'll close it out as Cannot Reproduce since you said you can't help isolate it any further.

Can you provide any other configuration or files that may relate to reproduction of the issue? Perhaps the configuration of the SIP peers involved and your rtp.conf ?
By: alexr1 (alexr1) 2014-08-05 09:22:48.724-0500

Both servers have:

{noformat}
; RTP Configuration
[general]
;
; RTP start and RTP end configure start and end addresses
;
rtpstart=10000
rtpend=20000
{noformat}

Both using realtime on separate tables, and the peer definitions are:

First server:

{noformat}
[general]
context = from-sip-external ; Send unknown SIP callers to this context
realm = XXX.XXX.XXX
port = 5060           ; Port to bind to (SIP is 5060)
bindaddr = XXX.XXX.XXX.XXX    ; Address to bind to (all addresses on machine)
srvlookup=no
dtmfmode=rfc2833
relaxdtmf=no
rfc2833compensate=yes
disallow=all
allow=g722
allow=g729
allow=alaw
allow=ulaw
callerid=Anonymous
rtpkeepalive=10
rtptimeout=60
progressinband=yes
rtsavesysname=yes
allowsubscribe=no
allowtransfer=no
tcpenable=yes
tcpbindaddr=XXX.XXX.XXX.XXX

t38pt_udptl=yes,redundancy,maxdatagram=400
t38pt_rtp=no
t38pt_tcp=no

rtcachefriends=yes
rtupdate=yes

[XXXXPBX]
type=friend
qualify=yes
nat=no
host=XXX.XXX.XXX.XXX
dtmfmode=rfc2833
context=from-internal-pbx
directmedia=no
canreinvite=no

{noformat}



Second Server:

{noformat}
[general]
context = from-sip-external ; Send unknown SIP callers to this context
realm = XXX.XXX.XXX
port = 5060           ; Port to bind to (SIP is 5060)
bindaddr = XXX.XXX.XXX.XXX    ; Address to bind to (all addresses on machine)
srvlookup=no
dtmfmode=rfc2833
relaxdtmf=no
rfc2833compensate=yes
disallow=all
allow=g729
allow=ulaw
allow=alaw
callerid=Anonymous
rtpkeepalive=10
rtptimeout=60
progressinband=yes
sendrpid=yes
videosupport=yes

;FOR BLF
rtcachefriends=yes
rtupdate=yes

notifyringing=yes
allowsubscribe=yes
callcounter=yes

[XXXXtel]
type=friend
insecure=very
host=XXX.XXX.XXX.XXX
fromuser=XXXXPBX
fromdomain=XXX.XXX.XXX.XXX
dtmfmode=rfc2833
disallow=all
context=pbx-incoming
canreinvite=no
directmedia=no
allow=ulaw
allow=alaw
allow=g729
allow=g722

{noformat}

Hold music was wave, (although a wav16 version was also present and it seems Asterisk sometimes plays the 16hkz file at 8khz but that's another issue).

The only change I made to work around the issue was to comment out the rtpkeepalive.
By: Rusty Newton (rnewton) 2014-08-07 18:08:52.210-0500

So, using the milliwatt test and your configs I can confirm that the behavior your describe is accurate.

What I did was call between the two servers, from a phone on one side, to a milliwatt test on the other and observe the audio in relation to the RTP stream (using RTP debug). Both ends, with rtpkeepalive enabled will send out keep alive packets even if RTP is flowing constantly. This results in the other side getting an interruption in audio.

Though, I think it may be expected behavior. That is, I believe rtpkeepalive is expected to send the comfort noise packets regardless of what is happening with the RTP stream. If the far end device interprets them as noise and plays them then that is expected.

I'll check with some Asterisk developers to determine expected behavior and then we can clarify in the documentation if necessary.
By: Rusty Newton (rnewton) 2014-08-08 09:46:10.440-0500

[~jcolp] looked at the code and apparently it does appear that rtpkeepalive should only be sending out a keep alive if there is a gap in the RTP stream that exceeds the rtpkeepalive value.

In this case, it looks like rtpkeepalive is just sending out keep alive packets regardless of what is happening stream.
By: Rusty Newton (rnewton) 2014-08-08 09:49:57.089-0500

[~alexr1] Thanks for the report and configs!
By: alexr1 (alexr1) 2014-08-08 23:59:37.923-0500

No problem - happy to help where I can!

By the way - I did not 'hear' the keep alive packets when transcoding is going on (between Server 2 and handset) - but I never did a packet capture to confirm what was happening. So maybe it only happens when P2P Bridging?
By: zvision (zvision) 2017-04-21 12:04:09.512-0500

I have just faced the same problem. CN packets get sent even if RTP is flowing when rtpkeepalive is set.
In my sample setup there are 2 Asterisk servers calls go through, one mostly performs RTP P2P bridging,
while the other one performs full RTP handling. For each call, the one in P2P mode sends unneccessary
CN packets (they also originate with different SSRC and RTP timestamp 0, which messes up the main RTP
stream on the other asterisk server, generating a new SSRC each time CN packets is received).

Here is the situation:
Server 1 (P2P bridging after a call is answered) - output stream to Server 2:
Main RTP stream has SSRC=1 and monotonic timestamps
CN packets every 30 seconds have SSRC=2 and timestamps = 0

Server 2 (forwarding calls further in full bridging mode) - output stream:
Main RTP stream is split into 30 seconds long parts with different SSR, each lasting 30 seconds.

Quick look at the chan_sip,c sources may suggest, that dialog->lastrtptx
is not updated correctly in P2P bridging mode, so checks inside check_rtp_timeout always trigger
CN generation. Another note is that my 30 seconds keepalives intervals start counting on SIP 200 OK
which is the exact moment RTP enters P2P bridging mode.
By: zvision (zvision) 2017-04-21 12:19:19.386-0500

Further investigation seems to confirm the problem with the dialog->lastrtptx not being updated
in P2P bridging mode, as SIP channel .write (sip_write) call is skipped in such scenarios.

In sources, I found someone's comment about moving lastrtptx to the RTP instance structure
being good idea...
By: zvision (zvision) 2017-04-21 12:55:01.531-0500

In parallel, I found that SSRC mess is caused by P2P bridging not maintaining SSRC across the bridge,
so after 200 OK is sent, SSRC gets simply forwarded between RTP instances, and Asterisk generated
CN packets may hit a scenario, where no SSRC has been set on an RTP instance.

For example, if RTP is being sent after 200 OK it gets into P2P mode immediatelly, so its RTP instance
has no rxssrc and lastts fields set, that why CN packets may have its own SSRC and timestamp = 0 each.
Only the lastseq gets updated.