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:
news.ycombinator.com
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).
