SIP: IP-Phone Without Incoming Calls After Reestablished Internet Connection

Hello.

Here I have a Yealink W60P ip phone, with a fix internal IP, behind an IPFire with latest version. But I have to restart it to talk to the world.

The situation is like this:
The Phone uses telephone numbers from 1&1.
After 24 hours the firewall authenticates again at the provider.
Then outgoing calls are possible, the configured telephone numbers/lines of the ip phone are registered and outgoing calls let the recipient’s device ring. But incoming calls are not possible.

Phone log result:
In the phone’s log it is mentioned that keep-alive packets are being rejected with “405 Nicht erlaubter Request-Typ”.

Situation:
So I restart the phone manually and calls are possible again for the rest of the time since the next povider login.
The phone uses the stun server of the provider.
So far, Yealink has no idea, either.

The use of ip address forwarding from the provider to the phone shouldn’t be necessary from what I am aware so far.
Besides this, 1&1 has a server pool behind stun.1und1.de.

Question:
So, does somebody has an idea how to use the phone for calls without a restart the device and use IPFire as a Firewall?

Thanks for any hints.

Hi,

welcome to the IPFire community. :slight_smile:

The use of ip address forwarding from the provider to the phone shouldn’t be necessary from what I am aware so far.
Besides this, 1&1 has a server pool behind stun.1und1.de.

Personally, I have used VoIP equipment with 1&1 behind an IPFire machine a few years ago.

Back then, 1&1 did VoIP in an - um - non-optimal fashion. For example, they had a bunch (about 20 IPv4 addresses) of SIP loadbalancers scattered across different networks - of which some apparently were not exclusively reserved for 1&1 infrastructure.

While your VoIP phone picked one of these IP addresses randomly, SIP traffic for incoming calls sometimes came back from a different IP address, rendering connection tracking completely unusable. In the end, I had to manually dig through the PTRs of their networks, searching for potential SIP servers, creating a firewall group for them, and forward incoming SIP traffic from that group to my VoIP phone.

(Note: Please do not expose the SIP ports of your equipment to the internet in general. You will see a lot of attacks and fake/spam calls then.)

However, a STUN server neither worked nor was necessary back then.

While I am not familiar with Yealink devices, the following aspects might be of help:

  1. Enable “symmetric RTP”, so incoming and outgoing RTP streams will use the same port.
  2. If possible, enable SRTP and SIP over TLS (presumed 1&1 support both, which they didn’t a few years ago) to avoid connection tracking oddities.
  3. If your VoIP provider only has one IP (loadbalancer) address, or sticks to the server you use, keep-alive should be sufficient to make things work.

Sorry for not being able to provide you with a “step by step” guide.

Thanks, and best regards,
Peter Müller

Hi Peter,

thanks for sharing your thoughts!

Although I am not new, I had to create a new account and am still in use the former red IPFire appliance, now with a slightly different inner hardware.

Was in contact with the provider and they would prefer looking into the FritzBox settings, which isn’t available, and going into the configuration for a seperate ip phone it is not their, let me call it, business.
Which I absolutely can understand for a private line.

Relating STUN: Without the stun server the device wouldn’t connect.
The configuration is well explained here. With a Fritzbox the telephone connection was working with a phone via the old telephone connection attached to the router and without the IPFire.

Relating your points:

  1. Will have a remote session with Yealink digging deeper into the cause for the incoming connection issues.
  2. SRTP is not available at 1und1 as, they told this via phone, SIP is already encrypted.
  3. Keep Alive with different settings where checked without any difference. After re-login via IPFIre at the provider, the IP phone reconnects, outgoing calls are possible, but no incoming ones - which is kinda weird. Incoming voice is also missing because of this.
    Probalby connecting with a Starface appliance could solve some things, but why using more Software to solve this?..

Played with some firewall rules for incoming connections for the stun.1und1.de without success so far.
Need to check with IPs 212.227.124.129 und 212.227.124.130, the SIP servers on the provider side.
But with stun this shouldn’t be necessary, too.

Will look forward in any way.

Is the phone manually configured or set for AutoProvision?

1st I would Verify your Mailbox/MWI settings or just disable it and use the Vmail to Email feature for testing.

Session timer. is it UAS or UAC? (client or server initiated) That’s a setting the evaded me for awhile, ask your provider or check a SIP trace.

Can you sanitize a config and or a SIP trace and share? That would be helpful, an old 10/100 hub (not a switch) capture with Wireshark or a RSPAN of the switchport during the issue would be fantastic if a SIP trace from your vendor is not available.

I would look for something similar to THE BOLD TEXT to troubleshoot further.

(Method: REGISTER)
[Jan 31 23:30:24] NOTICE[2423]: chan_sip.c:12776 handle_response_register: Outbound Registration: Expiry for sip.my_provider.com is 240 sec (Scheduling reregistration in 225 s)
Scheduling destruction of SIP dialog '2510cde35a754348209ebfbf31b9080d@YYY.YYY.YYY.YYY’ in 32000 ms (Method: NOTIFY)
Reliably Transmitting (NAT) to xxx.xxx.xxx.xxx:5060 :
NOTIFY sip:my_user_name@sip.my_provider.com SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bK178dc667;rport
From: “asterisk” sip:my_user_name@YYY.YYY.YYY.YYY;tag=as75943980
To: sip:my_user_name@sip.my_provider.com
Contact: sip:my_user_name@YYY.YYY.YYY.YYY
Call-ID: 2510cde35a754348209ebfbf31b9080d@YYY.YYY.YYY.YYY
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 89

Messages-Waiting: no
Message-Account: sip:9850@YYY.YYY.YYY.YYY
Voice-Message: 0/0 (0/0)

<— SIP read from xxx.xxx.xxx.xxx:5060 —>
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bK178dc667

From: “asterisk” sip:my_user_name@YYY.YYY.YYY.YYY;tag=as75943980
To: sip:my_user_name@sip.my_provider.com;tag=fegss
Call-ID: 2510cde35a754348209ebfbf31b9080d@YYY.YYY.YYY.YYY
CSeq: 102 NOTIFY
Server: My_provider UAS v110.08
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Contact: sip:xxx.xxx.xxx.xxx
Accept: application/sdp
Content-Length: 0

– Got SIP response 405 “Method Not Allowed” back from [xxx.xxx.xxx.xxx](http://xxx.xxx.xxx.xxx/) Really destroying SIP dialog '2510cde35a754348209ebfbf31b9080d@YYY.YYY.YYY.YYY’ Method: NOTIFY Really destroying SIP dialog ‘68266b317da0600c2dcde741755ede74@127.0.0.2’ Method: REGISTER

Have you tried all 3 settings here?
Accounts → Advanced → Keep Alive Type:
0-Dsiabled
1-Default: the phone sends UDP packets to the server.
2-Option: the phone sends SIP OPTION packets to the server.
3-Notify: the phone sends SIP NOTIFY packets to the server.

Worst case you can send syslog messages from the phone to IPFire and then have monit run a script with one of the following that works for your device

curl http:// phoneIPAddress>/servlet?key=Reboot
curl http:// phoneIPAddress>/cgi-bin/ConfigManApp.com?key=Reboot
curl http:// phoneIPAddress>/cgi-bin/cgiServer.exx?key=Reboot
curl http:// phoneIPAddress>/servlet?key=AutoP
curl http:// phoneIPAddress>/cgi-bin/ConfigManApp.com?key=AutoP
curl http:// phoneIPAddress>/cgi-bin/cgiServer.exx?key=AutoP

~frustro

@pmueller regarding the calls coming from different locations that is still quite common. Often a “value” SIP provider will start or accept the INVITE leading to the 183 then the 200 and when the session is connected will issue a REINVITE directly to the e164 SIP URI and let the endpoints negotiate the RTP stream while exiting the call entirely sometimes even if it terminates at the PSTN via an IAD, PRI or ATA. Billing is then handled by the SS7 signaling provider for the DID origination and termination.