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.

1 Like

As I was busy the last days, I wasn’t able to share more details so far.
So, here we go - attaching files is prohibited for new users. So my sharing possibilities are limited.

The configuration is set manually by me. So far I am not aware that autoprovisioning is possible nor how to configure it. So far I only found mentioned manual change for the phone password and necessary information for the server from 1und1.

Sharing your highlighted line on my site looks like this:
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bK851604180;rport

For the phrase Not Allowed there is only one line present:
TALK<4+warnin> 821.299.699:Not allow trans directly[0]

But this also appear once after a phone restart with the possibility to take calls.
TALK<4+warnin> 037.356.995:Not allow trans directly[0]

Any ideas available?

Get something like Visual Syslog Server for Windows.
Get the admin manual.
Yealink+W60P+DECT+IP+Phone+Administrator+Guide

Search for the following:
Syslog can be configured using the following methods
page 432 (document not pdf)
image

When you get a good capture of the error just post the log.

I am able to attach pictures, but no files like zip…
Well, used [WeTransfer] for the file, included in the zip are two logs - they are named for the situations I created them.

\m/0.o\m/

The file:

2_deviceLOG_restart_incomingOK_outgoingOK (OK/OK)
has one username:
Rufnummer3 sip:49Telefonnummer@
Works!!!
SUBSCRIBE missing
NOTIFY missing

The file
1_DeviceLOG_IncomingError_OutgoingOK (BAD/OK)
has 3 username
Rufnummer3 sip:49Telefonnummer@
Rufnummer4 sip:49Telefonnummer@
Rufnummer6 sip:49Telefonnummer@
Fails!
has SUSCRIBE
has NOTIFY
:fire:
ll great information but mostly useless to trouble shoot your issue remotely…

Cant compare SUSCRIBE and NOTIFY for ERROR with provided logs. Log OK/OK does not have that information, BAD/OK does.
username3,4,5 in BAD/OK ,ONLY 3 in OK/OK

I’m not trying to be mean :smiley: Required information is missing.:man_shrugging:

How I would gather 1st log.
1 Setup syslog server
2. Configure device to send logs to syslog server.
3. Power off device.
4 Ensure no GUI WebUI access of device during testing
5. Contact Vendor
6. Request Tech Support\

  • Request a L2+ Tier tech for LIVE TROUBLE SHOOTING,
  • Prepare the Tech Support Agent for a LIVE SIP CAPTURE.
  • Power on device.
  • Place 1st inbound call.
  • Answer call on device
  • Place 2nd inbound call
  • Put 1st on hold Answer 2nd call.
  • Join calls.
  • Hang up
  • Get SIP trace from tech via email or similar.
  • Say Thank you!!.

7 Go have a 1++ beers, mumble about how this is stupid and this sh!t should just fuqn work!!

Hurrah!!
You have a clean log of a device contacting VENDOR and OK INCOMMING call, another incoming call, 1 call on hold and then 2 calls joined together and a hang-up

Thad’s only half of the information needed to remotely understand WTF is going on (3 usernames :eyes:?)

.
You estimated 12 hours before error?

  • Reboot device so that error will occur approximately 12 hours later and convenient for you to trouble shoot,

  • Make inbound calls until ERROR occurs about an hour before expected time.

  • Clean up the beer you just spilled getting excited about being right regarding the 12 hour thing

  • Place new syslog with other 2 files

IVE BEEN CALLING FOR 4 HOURS AFTER IT USUALLY HAPPENS AND IT STILL WORKS!!

Sweet!
That tells us that inbound calls do something (reset a timer somewhere) that keeps it working and IDLE makes it break.

Drink the last beer from yesterday leave and, get more on the way home…It’s about 12 hours until you get any more data.

With device in FAILED INBOUND ERROR refer to beginning of this post and how to get a log from VENDOR of failed inbound call while you get a log file from your side.

You should now have the following log files (more is fine)

Device power on and inbound test.
Vendor log from power on and inbound test
Inbound BAD your files
Inbound Bad VENDOR files.

problem will be in that data and you, I or the vendor or a savior will find it.

~frustro

Hi frustro,

thanks for your thoughts!
Tried them and created some new log files. File names includes some hints about the call situation.
Could you please have a second look?

Thanks