Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal call forwarding in connection with a FRITZ!Box fails #272

Open
gerion0 opened this issue Apr 7, 2022 · 4 comments
Open

Internal call forwarding in connection with a FRITZ!Box fails #272

gerion0 opened this issue Apr 7, 2022 · 4 comments
Labels
external The source of this issue lies outside of the Twinkle codebase info needed SIP/SDP

Comments

@gerion0
Copy link

gerion0 commented Apr 7, 2022

I have connected via SIP to a FRITZ!Box (FRITZ!OS 7.29). Normal phone calls work fine, but call forwarding does not work (to another local phone, managed by the box).

Wenn clicking on "Vmtlg. (Gespräch weiterleiten)" (German locale), I got the window, if I want a direct forwarding or want to talk with the other party first.
When choosing direct forwarding, the following error came:

Leitung 1: Rufweitervermittlung erfolglos.
429 Provide Referrer Identity

When choosing to talk with the other party first, the call to the other party works, but when ending the call, the original call is not forwarded.

Is this a bug or do I have configured something wrong? I'm pretty sure that the FRITZ!Box supports call forwarding. On a normal analogue phone, it works fine. Also, there is an explicit help page for the Fritzphone for that.

@fbriere
Copy link
Collaborator

fbriere commented Apr 8, 2022

When choosing direct forwarding, the following error came:

429 Provide Referrer Identity

This means that your FRITZ!Box is requiring Twinkle to include a cryptographically-signed Referred-By token to prove its identity to the other party, as per RFC 3892. This is not supported by Twinkle, and is very unlikely to change in the near future.

(I have no idea why such a requirement would be turned on by default for a consumer box, nor if this can be disabled. I glanced at the manual for a random model (7510), but couldn't find anything.)

I did happen to find another similar report, which suggests that a transfer with consultation might still be allowed to go through. If true, this would at least provide you with an alternative solution.

When choosing to talk with the other party first, the call to the other party works, but when ending the call, the original call is not forwarded.

Did you press the Xfer (or Vmtlg) button at the end to complete the transfer? If you simply hang up, the call will be terminated without being transferred, as you experienced. (See the manual for more details.)

@fbriere fbriere closed this as completed Apr 8, 2022
@fbriere fbriere added external The source of this issue lies outside of the Twinkle codebase SIP/SDP labels Apr 8, 2022
@gerion0
Copy link
Author

gerion0 commented Apr 10, 2022

Did you press the Xfer (or Vmtlg) button at the end to complete the transfer? If you simply hang up, the call will be terminated without being transferred, as you experienced. (See the manual for more details.)

Thanks for the hint. I actually hang up (since I did the same with the analogue phone). However, pressing Xfer to complete the transfer also leads to 429 Provide Referrer Identity.

(I have no idea why such a requirement would be turned on by default for a consumer box, nor if this can be disabled. I glanced at the manual for a random model (7510), but couldn't find anything.)

At least in the Webinterface of the Box I have not found any setting for the internal SIP details (unfortunately, I also cannot modify / play around with the firmware, since it's a provider locked box).

@fbriere
Copy link
Collaborator

fbriere commented Apr 12, 2022

However, pressing Xfer to complete the transfer also leads to 429 Provide Referrer Identity.

Damn. I had hoped that the FRITZ!Box developers were only half-insane...

As a last-ditch effort before giving up, could you check if Twinkle is actually sending a Referred-By header in its REFER? It should, and its absence would not trigger a 429 anyway, but it doesn't hurt to check at this point.

@fbriere fbriere reopened this Apr 12, 2022
@Cyborgscode
Copy link

At least in the Webinterface of the Box I have not found any setting for the internal SIP details (unfortunately, I also cannot modify / play around with the firmware, since it's a provider locked box).

AVM is always willing to help out, it can't harm to contact customer support there and ask for help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external The source of this issue lies outside of the Twinkle codebase info needed SIP/SDP
Projects
None yet
Development

No branches or pull requests

3 participants