Frtizbox 7590 und SIP telephone

Mabel2

Neuer User
Mitglied seit
1 Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
Sorry for writing in English! My problem is that I can't find any documentation about configuring our SIP telephones. There is a lot about SIP telephony, but it all seems to deal with 'how do I get the Fritzbox connected'. Apparently, this part was already done by my provider: the two telephone numbers are readily available. They were configured to use the two 'analogue' ports on the box, for use with conventional phones and this works.
BUT we do not have 'conventional' phones; we have a pbx and phones which connect to the LAN (I think that's a SIP-phone or IP-phone?). Using such phones is clearly an option on the Fritzbox 7590.
In the menu 'Telephony.Telephony devices' I deleted the entries for the analogue ports and replaced them with new entries for IP phones. Configuration seemed fairly straightforward; just a few clear choices and a 'username' and 'password'.

So far, so good, but now my problem. The SIP central phone aks for a LOT of data to get things working. I have to fill in several kinds of 'servers' (registrar server, presence server, proxy server) and also various port-addresses (which I can't configure in the Frtizbox as far as I can see), logins and passwords. The documentation on the AVM website seems (?) to be about the part that was already preconfigured but not about configuring my phone.

My question: am I right in thinking that the Fritzbox, set up as I described, can serve as an 'in-house' SIP server? E.g. that I should use its internal ip-address everywhere where a 'server' is asked for? But what about the port numbers?
It seems like a wonderful option on the Fritzbox but I can't find anything on te AVM website to help me use it.
Mabel
 

KunterBunter

IPPF-Urgestein
Mitglied seit
12 Okt 2005
Beiträge
26,030
Punkte für Reaktionen
548
Punkte
113
My question: am I right in thinking that the Fritzbox, set up as I described, can serve as an 'in-house' SIP server?
Yes, but it depends on the type of the phone whether it is functioning with a Fritzbox. You left us in the dark about that. :(
Btw: the correct spelling is Fritzbox, not Frtizbox.
 

Mabel2

Neuer User
Mitglied seit
1 Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
We have Panasonic TX-TGP 550 central with TX-TGP-500 handsets.
I wonder why you ask, since this type of phone equipment seems to be fully standardised. Very versatile, but also dependent on many data like servers, domains, logins+passwords, ip-portnumners etc.
Mabel
 
Zuletzt bearbeitet:

DM41

Moderator
Teammitglied
Mitglied seit
26 Apr 2005
Beiträge
7,366
Punkte für Reaktionen
113
Punkte
63

sunnyman

Mitglied
Mitglied seit
13 Jan 2006
Beiträge
465
Punkte für Reaktionen
33
Punkte
28
since this type of phone equipment seems to be fully standardised.

No. SIP is not a standard, it is - like many parts and protocols used in the IT world today, based on a bunch of documents, written mostly in natural language. In my opinion, RFCs are simply misconceived as standards.

ISDN, as a counter-example, is "ratified" by several standardization organizations and foundations around the world: ISO, ECMA, ETSI, ITU-T, ... just to name some.
Many parts of ISDN are specified using the (itself standardized) specification language SDL, that has been designed (citing Wikipedia) for "the unambiguous specification and description of the behaviour of reactive and distributed systems". This is what I'd like to call "fully standardised". The ISDN standards specify every layer, from the physcial communication (S0, Up0, Uk0,..), routing (SS7, etc.) up to application protocols like E-DSS1.

In the contrast, you even don't know which RFCs to follow since there is a bunch of RFCs, loosely coupled by weak references. Sometimes, RFCs are sometimes superseded by other ones, and often you just have to know what is the current practice.
Apart from that, SIP is just a inherently universal protocol to initiate a session for "something" between two communication partners. Hence its name "Session Initiation Protocol", without any reference to telephony or else. So, the only thing SIP is what you call signaling in traditional telephony. For everything else you need for a phone call, additional protocols and specifications are used (SDP, RTP, TLS, XML, ...). As a matter of fact, SIP has been introduced in the mid-90s, long before people started to build IP-based telephony networks.
Alternative examples for VoIP protocols exist. H.323 is an alternative to SIP-based VoIP and was mainly used in the early days of VoIP (Microsoft NetMeeting based on it). Apart from that, there are some vendor-specific VoIP protocols for their PBX phones, like Simens/Unify's HFA. Alcatel and Cisco do also maintain their proprietary VoIP protocols.

Standards like for ISDN are often verbose, have strong, intricate cross-references, often use a bureaucratic language with many hard to remember acronyms, may even not be freely available and they often take a long time until they are finished. Some standardization organizations fund their work by selling (hard) copies of the standards (while staying independent from industry lobby financing that way). You sometimes even are / were not allowed to buy copies of that standards unless you were a company, research institute or else working in the telecommunications field. But what you get is a extremely stable system and high degree of interoperability. Often, you can pin-point a erroneous implementation because one or both vendors did not strictly follow the standard.

RFCs are like a counterdraft to real standards: Always freely available, mostly non-formal language, and in principle, "everyone" can also participate in designing them by engaging in the respective committees, like IETF working groups.
In fact, RFCs are also said to be intentionally a designed that way, to tackle drawbacks of standards. So, the idea is to not design "a thing" from ground up in all of its possible aspects, RFCs are nothing more than "documented best practice".

Here is a very interesting yet disenchanting discussion regarding implementation of TCP/IP:

The reason why TCP/IP is such a success story is not because the specification (i.e. RFCs) are so unambiguous that it is super-easy to write a TCP/IP stack on your own. The reason is that there exists a tiny number of TCP/IP implementations in the world to which a huge amount of work has been put into to have them interoperable and be able to handle the wrongdoings of the others.

RFCs are often not more than "recommendations". RFC uses some "standard" wording to express priority of requirements (defined in RFC2119), like SHOULD, MUST, OPTIONAL, etc.
In my opinion, at least when reading SIP-related RFCs, way too many aspects are specified way too lax.

Ultimately, there is only very little functionality you can count on, at least in a sense that you can refer to MUST-annotated requirements of the RFCs. In everything case that goes beyond it, you cannot really tell who is wrong on what, since the combination of all that options, given by the SHOULDs, OPTIONALs, etc. span a big room of possible implementations. Apart from that, the often non-formal or incomplete specifications just leave room for interpretation.

There even is more than one way where to read or write the phone number of caller / callee.
Apart from From/To headers in SIP, there are various additional headers or supportive information (P-Asserted-Identity, P-Preferred-Identity,..).
There are for example (at least) three variants (and of course a bunch of RFCs) of how DTMF tones can be submitted.

And the result is that, when all that stuff works, the feature set you get is nothing more than an everyday POTS landline phone in the 1990s, when backed by an ISDN exchange, had.

There is a lot more that can hinder your calls, like other protocols involved or general network design questions like Proxy, NAT, IPv4/6 problems, DS-lite and so on.
Just for coping with Proxy and/or NAT issues, there is a plethora of mechanisms, protocols, supplemental services out there which can be in use.

Because of all of that, some vendors founded an initiative to further specify and narrow-down the RFCs into a convention called SIPconnect.

For decent telephony in commercial PBX systems, there is still a lot of features missing that has been tinkered into SIP, by using additional messages, headers, etc.
These features include presence information, message waiting indication (MWI), text messages and a lot more.

To finally answer your questions:
Yes, the Fritzbox has what you call a SIP server. In SIP-speech, it is called a registrar.
Some equipment uses the term SIP proxy, which may be confusing, this is not related to a proxy as internet access server.
Your phone seems at least to have some advanced functionality for SIP like presence. As all of these functionalities can be in principle hosted on different systems, the phone lets you specify different addresses for them.

However, the Fritzbox does NOT feature presence functionality. Regarding the ports: I suggest to leave them empty, the phone should try reasonable defaults (like 5060 for SIP).
 

Mabel2

Neuer User
Mitglied seit
1 Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
I am very grateful for these answers; I am a lot wiser now since I understand I know nothing :)
Yet the answers confirm what I suspected: that the advice of our providers helpdesk (pointing to servers on the internet) was totally wrong and that, instead, I should try to connect to the Fritz!box.
@DM41: YES, the page you mention was precisely what I was looking for. (Why couldn't I find that myself, I wonder.) I'll try it a.s.a.p.
@sunnyman: in addition to providing lots of valuable insights and info you also made me feel a lot better about myself since I'd started to wonder if I was just too dumb to simply install a modern phone. I still don't know if it will work but if not, at least I'll know it's not something to be ashamed of.
The phone itself suggests port 5060 so that figures.

Meanwhile, it indeed seems high time to establish some clear standards, but also better documentation and information. On our location, we can only use 'landline' numbers which work with VoIP technology and it seems fairly ridiculous that the only way to use these 'lines' in a comprehensible way is to use the 'analogue' ports on a device like the Fritz!box. (Or maybe DECT phones; I didn't try that.) Even for a small office like ours this would be a big step backward.
All we demand are the options we've had for 40 years, like seeing the incoming line on the handset (so we can answer appropriately) and choosing a line/number for outgoing calls (for the benefit of our customers). Whereas I could up till 10 years ago buy a simple PBX with handsets allowing just that (everything analogue of course, and wired) it now seems like a major task to achieve this.

Thanks again!
Mabel
 

Mabel2

Neuer User
Mitglied seit
1 Apr 2021
Beiträge
4
Punkte für Reaktionen
0
Punkte
1
I can't get it to work; please help?
Summarising my situation:
- Our provider installed a Fritz!box 7590, with 2 telephone numbers preconfigured for the 2 analogue ports. This works, BUT
- We have a VoiP PBX (Panasonic TX-TGP 550), which I'm trying to connect to the Fritz!box.
I can't get it to work; the number of fields the Panasonic asks me to fill in is staggering and also the terms used in the Fritz!box are different from those on the phone. (e.g. is the 'ID' of the line/tel.number the same as the 'Name' I gave it in the Fritz!box?)
I think I configured the Fritz!box correctly since there are not that many choices to make. Here is a picture of the settings:
Panasonic_02 Apr. 08 18.39.gif

And here is a picture of the settings I made on the Panasonic PBX. Where did I go wrong?
Panasonic_03 Apr. 08 18.40.gif

Mabel
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via