Welchen Vorteil hat SIP over TCP ?

[GK]

- Schau Dir mal die VIA-Header bei SIP an ;-)

Hmm, was haben VIA-Header mit SDP/RTP zu tun?

- Schau Dir mal das Konzept der "Application-Level Gateways" in Routern an ;-)

Natürlich kann man mit einem ALG (oder entsprechendem Port-Forwarding oder UPnP) alles lösen, aber funktionierende SIP-ALGs sind glaube ich eher noch die Ausnahme als die Regel.

- Und dann würde ich noch empfehlen, den Start einer Fritz!Box zu beobachten... genauer: den Start des voipd, der nämlich gleich zu Beginn seine externe IP-Adresse herausfindet ;-)

Die externe IP-Adresse herauszufinden ist auch i.d.R. möglich (auch bei STUN und symmetrischer NAT) aber beim später zu verwendenden RTP port ist das schon wesentlich schwieriger, da das ensprechende NAT-Binding erst erzeugt wird, wenn Daten zwischen beiden Endpunkten fließen und die NAT i.d.R den lokalen Port verändert.
Deswegen scheitert hier STUN (der vom STUN-Server übermittelte Port ändert sich für die Belange des RTPs).

Ich weiss nicht wie eine Fritz!Box hinter einer symmetrischen NAT ohne ALG funktioniert und habe auch keine Fritz-Box/symmetrisches NAT zur Hand aber es würde mich schon wundern, wenn das geht.

Das Quoten geht wieder, hab' wohl aus Versehen auf "Antworten" geklickt.

Gruss,
Gunnar

 

[gandalf94305]

[...]NAT i.d.R den lokalen Port verändert.[...]

Genau. Da symm. NAT jedoch immer den gleichen Port für eine bestimmte Kommunikationsverbindung (Paar von Src/Srcport Dst/Dstport) verwendet, muß die Gegenstelle einfach die Daten an den Source-Port zurückschicken...

In jedem Fall: es funktioniert ;-)

--gandalf.

 

[TWELVE]

Mmmh...versteh ich hier was falsch...?

SIP ist doch nur das Protokoll, um die Anrufe auf und abzubauen, der Stream wird doch immer per UDP übertragen...?

SIP can run over any datagram or stream protocol such as UDP 10 , TCP, ATM,
and frame relay. SIP is commonly run over TCP/IP because of inexpensive
widespread connectivity, directory services, naming services, and a widely
known development environment.
The audio and video data streams are transported using the Real-time
Transport Protocol 11 (RTP) over UDP. SIP call signaling messages can be
carried over UDP or TCP, with UDP being the preferred method because of its
better performance and scaleability. One important consideration when using
SIP over UDP is that the entire message should fit within a single packet. If a
SIP message is fragmented into multiple datagrams, the probability of losing
the entire message increases with the number of fragments. When SIP
messages are being transmitted over a WAN, the retransmissions that result
due to lost fragments can seriously degrade call signaling performance. The
default port for SIP is 5060 although any available user port may be used. The
port to be used for RTP/RTCP is specified in SIP call signaling messages.

Grüße

TWELVE

 

[gandalf94305]

SIP ist doch nur das Protokoll, um die Anrufe auf und abzubauen, der Stream wird doch immer per UDP übertragen...?

Genau... das ist für die Session Control... wo liegt der Widerspruch oder das Rätsel? ;-)

--gandalf.

 

[TWELVE]

wo liegt der Widerspruch oder das Rätsel?

Och..wenn Du so fragst..an einigen Stellen...;-)

Für ein Session-Protokoll ist daher TCP klar besser geeignet.

Nachteile von TCP Retransmissions bei SIP sehe ich nicht, da das Protokoll im Gegensatz zu RTP nicht derart zeitkritisch ist. Vorteile von TCP sehe ich ganz klar an der Verbindungsorientierung, die (wie schon genannt) andere Paketgrößen gestatten (selten jedoch benötigt) und bessere Firewall- sowie NAT-Tauglichkeit bedingen.

Aus RFC 2543:

1.5.2 Lower-Layer-Protocol Neutral

SIP makes minimal assumptions about the underlying transport and
network-layer protocols. The lower-layer can provide either a packet
or a byte stream service, with reliable or unreliable service. In an Internet context, SIP is able to utilize both UDP and TCP as
transport protocols, among others. UDP allows the application to more
carefully control the timing of messages and their retransmission, to
perform parallel searches without requiring TCP connection state for
each outstanding request, and to use multicast. Routers can more
readily snoop SIP UDP packets. TCP allows easier passage through
existing firewalls.

...
For UDP, reliability is achieved using retransmission (Section
10).

10.4.2 TCP
Clients using TCP do not need to retransmit requests.

...

10.5.1 UDP

For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an
interval that starts at T1 seconds, and doubles after each packet
transmission. The client ceases retransmissions if it receives a
provisional or definitive response, or once it has sent a total of 7
request packets.

A server which transmits a provisional response should retransmit it
upon reception of a duplicate request. A server which transmits a
final response should retransmit it with an interval that starts at
T1 seconds, and doubles for each subsequent packet. Response
retransmissions cease when any one of the following occurs:

1. An ACK request for the same transaction is received;

2. a BYE request for the same call leg is received;

3. a CANCEL request for the same call leg is received and the
final response status was equal or greater to 300;

4. the response has been transmitted 7 times.

10.5.2 TCP

A user agent using TCP MUST NOT retransmit requests, but uses the
same algorithm as for UDP (Section 10.5.1) to retransmit responses
until it receives an ACK.

Aber egal...die Kriterien, ob TCP oder UDP verwendet werden sollte, kann man ja in den entsprechenden Dokumenten nachlesen.
Wenn ich die RFC richtig lese, dann sollte jeder SIP Server,Proxy und Client sowieso beides können.Es wird dann das genommen,was beide können.


Grüße

TWELVE

 

[prochmi]

zum thema NAT (auch wenn offtopic).

ich verwende netfilter (linux) ein symetrisches nat. und es funktioniert problemlos ohne stun (mit der nat=yes funktion von meinem asterisk).

ich sehe das so:

signalisierung (sip):
sobald ich mich beim proxy anmelde wird eine "UDP session" geöffnet und bei netfilter standardmäßig 180 sekunden offengehalten => daher kann ich 180 sekunden lang auch von außen erreicht werden. nun muß ich halt schauen, das der client <= 180s irgendwas zum proxy schickt. d.h. entweder die re-registration <= 180 setzen oder irgendwie anders (bei asterisk kann man über die funktion qualify erreichen, das der server in regelmäßigen abständen SIP Option messages zum client schickt, die dieser auch beantwortet => "udp session" bleibt offen)

media session (rtp):
wenn man symmetrisches rtp verwendet (ein port zum senden und empfangen), dann ist auch das kein problem.

ich habe also "böses" symmetrisches nat ;-) und kann trotzdem ohne STUN, ALG, usw. problemlos telefonieren.

mfg,
michael

 

[prochmi]

Aus RFC 2543:

VORSICHT!!!!

RFC 2543:
Obsoleted by RFC3261, RFC3262, RFC3263, RFC3264, RFC3265

immer schön die aktuellen RFCs lesen

mfg,
michael

 

[TWELVE]

VORSICHT!!!!

RFC 2543:
Obsoleted by RFC3261, RFC3262, RFC3263, RFC3264, RFC3265

immer schön die aktuellen RFCs lesen

Da Du die sicher schon gelesen hast, kannst Du mir ja sicher mal schnell erklären, was sich in Bezug auf den Kontext hier darin geändert hat.

Danke !

TWELVE

 

[TWELVE]

Na gut, ich hab selber mal kurz nachgelesen.

Aus [FONT=arial, sans-serif, helvetica]RFC3263[/FONT]

First, the client selects a transport protocol.

If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used.

Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
for a SIPS URI. Similarly, if no transport protocol is specified,
and the TARGET is not numeric, but an explicit port is provided, the
client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is
because UDP is the only mandatory transport in RFC 2543 [6], and thus
the only one guaranteed to be interoperable for a SIP URI. It was
also specified as the default transport in RFC 2543 when no transport
was present in the SIP URI. However, another transport, such as TCP,
MAY be used if the guidelines of SIP mandate it for this particular
request. That is the case, for example, for requests that exceed the
path MTU.


Otherwise, if no transport protocol or port is specified, and the
target is not a numeric IP address, the client SHOULD perform a NAPTR
query for the domain in the URI. The services relevant for the task
of transport protocol selection are those with NAPTR service fields
with values "SIP+D2X" and "SIPS+D2X", where X is a letter that
corresponds to a transport protocol supported by the domain. This
specification defines D2U for UDP, D2T for TCP, and D2S for SCTP. We
also establish an IANA registry for NAPTR service name to transport
protocol mappings.

Das klingt doch irgendwie schön.

Grüße

TWELVE

 

[GK]

ich verwende netfilter (linux) ein symetrisches nat. und es funktioniert problemlos ohne stun (mit der nat=yes funktion von meinem asterisk).

(immer noch off-topic)
Bist Du sicher dass das netfilter-Zeug bei Dir kein SIP-ALG enthält?
Bei neueren Kerneln (>2.6.x) ist das so, wenn ich mich recht entsinne.

signalisierung (sip):
sobald ich mich beim proxy anmelde wird eine "UDP session" geöffnet und bei netfilter standardmäßig 180 sekunden offengehalten => daher kann ich 180 sekunden lang auch von außen erreicht werden. nun muß ich halt schauen, das der client <= 180s irgendwas zum proxy schickt. d.h. entweder die re-registration <= 180 setzen oder irgendwie anders (bei asterisk kann man über die funktion qualify erreichen, das der server in regelmäßigen abständen SIP Option messages zum client schickt, die dieser auch beantwortet => "udp session" bleibt offen)

einverstanden.

media session (rtp):
wenn man symmetrisches rtp verwendet (ein port zum senden und empfangen), dann ist auch das kein problem.

Das nützt normalerweise nix:
Angenommen Dein UA will 'raustelefonieren. Dann schickt er ein INVITE mit einer Session Description in der bereits ein RTP-Port 'drinstehen muß. Da der UA aber (noch) nicht wissen kann, welchen RTP-Port die Gegenstelle verwenden wird, kann er nicht künstlich ein NAT-Binding durch Senden eines Dummy-Pakets erzeugen (das NAT-Binding definiert sich ja durch beide Adressen und Ports). Egal welchen (externen) Port der UA angibt, es gibt keine Garantie, dass das NAT-Binding welches später beim Senden des ersten RTP-Pakets entsteht dem vorher im SDP angegebenen Port entspricht.

Gruss,
Gunnar

 

[prochmi]

Bist Du sicher dass das netfilter-Zeug bei Dir kein SIP-ALG enthält?
Bei neueren Kerneln (>2.6.x) ist das so, wenn ich mich recht entsinne.

ja.

cat /proc/version
Linux version 2.4.32

Das nützt normalerweise nix:
Angenommen Dein UA will 'raustelefonieren. Dann schickt er ein INVITE mit einer Session Description in der bereits ein RTP-Port 'drinstehen muß. Da der UA aber (noch) nicht wissen kann, welchen RTP-Port die Gegenstelle verwenden wird, kann er nicht künstlich ein NAT-Binding durch Senden eines Dummy-Pakets erzeugen (das NAT-Binding definiert sich ja durch beide Adressen und Ports). Egal welchen (externen) Port der UA angibt, es gibt keine Garantie, dass das NAT-Binding welches später beim Senden des ersten RTP-Pakets entsteht dem vorher im SDP angegebenen Port entspricht.

weiß nicht was du meinst, ich sehe das so:

+) UA schickt ein invite (von mir aus mit portnummer)
+) verbindung wird aufgebaut
+) sobald das erste RTP paket vom UA rausgeht, passt das nat binding und die RTP pakete vom proxy kommen auch an

mfg,
michael