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:42 | Date Closed: | |
Priority: | Minor | Regression? | |
Status: | Open/New | Components: | 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. |