I’m experiencing the following scenario, and was wondering if you could help:
Asterisk source IP sends call to destination signalling IP
Destination signalling IP answers call, specifying destination media IP
Destination signalling IP then later sends re-invite to Asterisk source IP asking to change destination media IP
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:
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?
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
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?
Looks like there are some verbose log statements also in the rtp code. You could try turning up both verbose and debug to at least 5. You should then at least see something about RTP learning or the target address being switched, etc…
After negotiation does the other end start sending RTP? Asterisk won’t “learn” if no packets are being sent.
If it’s not already try narrowing the scope of the test into its most basic form. For instance make sure there is no nat involved to rule out those types of problems, etc…
Lastly you could try a similar setup using the pjsip channel driver to see if the problem is strictly chan_sip related.