Existing RTP stream + changing client IP

Asterisk Asterisk SIP
1

Hi guys,

I’m currently trying to make it so existing calls don’t break when mobile clients change their IP address (for example when roaming from Wifi to cellular or vice versa).

I’m running Asterisk 16 with the Groundwire app for Android. When getting back into Wifi range, I can still hear the other side, but they can’t hear me anymore.

Is this even possible? Can you give me general tips on what to look for, on the Asterisk-side of things?

2

A re-INVITE would likely need to be done from the client so that strict RTP protection occurs again, or else strict RTP disabled[1].

[1] asterisk/configs/samples/rtp.conf.sample at master · asterisk/asterisk · GitHub

3

Thank you for the quick reply!

I just tried setting strictrtp=no for a test: Now, after switching from cellular to wifi while a call is up, the caller can hear me, but I can’t hear the caller. This is with

rewrite_contact=yes
rtp_symmetric=yes

Let me know if there is anything else I can try. Otherwise I will contact the client’s developer.

4

Show an actual RTP trace using “rtp set debug on”.

5

Thank you, done.

Same setup as before: Call starts on cellular, I activate wifi during the call. When I activate wifi the following happens:

  • The mobile device can’t be heard by the PSTN side anymore, while the PSTN side is still heard by the mobile device.
  • Asterisk keeps sending to the pre-wifi IP address of the mobile device: Sent RTP packet to <cellular mobile device IP>
  • There’s no more Got RTP packet from <mobile device> lines, only Got RTP packet from <PSTN trunk>
  • The app re-registers, so the endpoint’s contact’s address is now the wifi’s public IP.

There’s an option in the app that manages when to switch networks which was set to If Needed for the above test. I changed it to Always for another test:

  • Most of the times, in this szenario everything works!
  • Asterisk receives and sends RTP packets from and to the wifi’s public address of the mobile device.
  • In 1 out of 5 calls, the issue is the other way round, though: The mobile device now can be heard by the PSTN side, but the PSTN side can’t be heard by the mobile device. Even though the packets are sent to the correct (wifi) IP and the port that the packets (that PSTN can hear) are sent from.

So it seems like there could be a solution here. What could cause the issue to be random like that with the new setting? Probably an issue with the app or the wifi, I guess? What could I try here?

6

I don’t know what the client is doing, so I can’t comment on that. If Asterisk doesn’t receive RTP though, it won’t latch on to the new source and send media there though.

7

This has no effect on existing calls. That is controlled by the Contact address in the INVITE or response. I seem to remember that SIP doesn’t permit the latter to change during a session. You would have to do a REFER, for that.

8

@david551 A re-INVITE can update the Contact, changing its target URI. This is covered in section 12.2.1.1 of RFC3261:

   A UAC SHOULD include a Contact header field in any target refresh
   requests within a dialog, and unless there is a need to change it,
   the URI SHOULD be the same as used in previous requests within the
   dialog.  If the "secure" flag is true, that URI MUST be a SIPS URI.
   As discussed in Section 12.2.2, a Contact header field in a target
   refresh request updates the remote target URI.  This allows a UA to
   provide a new contact address, should its address change during the
   duration of the dialog.
9

Thanks.

10

Thank you guys for all your input. The next thing I will do as soon as I can is a trace on the wifi network. That way I can see if the network’s firewall / router is blocking the packages from reaching the client or the client itself (Android or the app) is handling them in a bad way.

Either way it seems Asterisk is doing everything correctly by sending and receiving to and from the correct IP :slight_smile: