RTP re-invite not working

#1

I’m experiencing the following scenario, and was wondering if you could help:

  1. Asterisk source IP sends call to destination signalling IP
  2. Destination signalling IP answers call, specifying destination media IP
  3. Destination signalling IP then later sends re-invite to Asterisk source IP asking to change destination media IP
  4. Asterisk source IP accepts re-invite with 200 OK, but for some reason keeps sending RTP to original destination media IP

So basically the issue is that Asterisk doesn’t seem to be changing the media IP it sends the RTP to, in spite of the fact it’s accepting the request at the SIP level. I’ve attached a suitably redacted SIP trace of an example call to illustrate. I’m using chan_sip in Asterisk 13.23.1. I’ve looked at the directmedia setting, but it doesn’t seem to be relevant as this is about changing the destination media IP. See below for my SIP config:

[general]
language=en
useragent=iConsole
bindaddr=0.0.0.0
udpbindaddr=0.0.0.0
bindport=5060
port=5060
context=from-sip
directmedia=no
nat=force_rport,comedia
dtmfmode=rfc2833
rtptimeout=300
rtpholdtimeout=300
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allowoverlap=no
srvlookup=yes
ignoresdpversion=yes
t38pt_udptl=yes
session-timers=originate
insecure=port,invite

Thanks!

SIPtrace.txt (8.5 KB)

#2

Not sure what could be going on, but if you haven’t already try increasing the debug level in Asterisk to at least 3. It might provide some more information as to what could be happening.

Also, you say “…keeps sending RTP to original destination media IP”. How was this verified? Using a pcap or can you still hear audio on the original call?

#3

Yeah I’ve tried increasing the debug level, and tried enabling the RTP debug, but it didn’t seem to reveal anything. It was verified via pcap.

Thanks

#4

Check your rtp.conf file and see what “strictrtp” is set to. The option is enabled by default, so if it’s not found, or set to “yes” then try setting it to “no” and re-test and see if the problem still occurs.

Note If it does fix your problem I am not suggesting leaving that option turned off. That is something you’d need to decide for your environment (if it is a valid work around).

From rtp.conf.sample:

; Enable strict RTP protection. This will drop RTP packets that do not come
; from the recoginized source of the RTP stream. Strict RTP qualifies RTP
; packet stream sources before accepting them upon initial connection and
; when the connection is renegotiated (e.g., transfers and direct media).
; Initial connection and renegotiation starts a learning mode to qualify
; stream source addresses. Once Asterisk has recognized a stream it will
; allow other streams to qualify and replace the current stream for 5
; seconds after starting learning mode. Once learning mode completes the
; current stream is locked in and cannot change until the next
; renegotiation.
; Valid options are “no” to disable strictrtp, “yes” to enable strictrtp,
; and “seqno”, which does the same thing as strictrtp=yes, but only checks
; to make sure the sequence number is correct rather than checking the time
; interval as well.
; This option is enabled by default.
; strictrtp=yes

#5

Thanks for the helpful suggestion, however I’ve now tried both “seqno” and “no” and unfortunately they didn’t fix the issue. Do you have any other ideas?