So, um das Thema zumindest zu einem vorläufigen (unbefriedigenden) Ende zu bringen: Folgt man wortgetreu dem Standard (RFC 3261, SIP: Session Initiation Protocol), dann verhält sich das TC 300 kurz und bündig FALSCH.
Der RFC beschreibt auf Seite 15 in einem Anwendungsbeispiel schon etwas blumig das korrekte Verhalten:
Finally, Alice's
softphone sends an acknowledgement message, ACK, to Bob's SIP phone
to confirm the reception of the final response (200 (OK)). In this
example, the ACK is sent directly from Alice's softphone to Bob's SIP
phone, bypassing the two proxies. This occurs because the endpoints
have learned each other's address from the Contact header fields
through the INVITE/200 (OK) exchange, which was not known when the
initial INVITE was sent. The lookups performed by the two proxies
are no longer needed, so the proxies drop out of the call flow. This
completes the INVITE/200/ACK three-way handshake used to establish
SIP sessions.
Das Ganze wird dann in 12.1.1 genauer definiert
When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values. The UAS MUST add a Contact header field to
the response. The Contact header field contains an address where the
UAS would like to be contacted for subsequent requests in the dialog
(which includes the ACK for a 2xx response in the case of an INVITE).
Damit ist klar: Indem das TC 300 das ACK an den Proxy schickt, wird ein Grundprinzip von SIP verletzt. Es kommt zu keinem echten End-zu-End-Dialog und der 1und1 Server löst berechtigt aus, weil für ihn die Verbindung einfach nicht zustande kommt.
Tja, wer sagt's nun der T-COM
