Diskussion:Session Initiation Protocol

Aus dem Artikel:

"Die dafür verwendeten UDP-Ports werden dynamisch vergeben, was die Verwendung von SIP in Verbindung mit Firewalls oder Network Address Translation (NAT, RFC 2663) schwierig macht, da die meisten Firewalls bzw. NAT-Router die dynamisch vergebenen Ports nicht der Signalisierungsverbindung zuordnen können."

Ist damit Port Triggering gemeint? Siehe dazu die Diskussion in Port Forwarding.

Danke, --Abdull 18:36, 18. Jan 2005 (CET)

Echo

Kann jemand erklaeren, wie die Echos bei der SIP Telephonie enstehen? Ich denke das ist ein haufig zu beobachtendes Phenomen und wird viele interessieren?

Gruss -- Sparti 16:20, 30. Mai 2005 (CEST)

Das ist kein SIP-spezifisches Problem. --(nicht signierter Beitrag von ThomasSkora (Diskussion | Beiträge)) 22:21, 14. Aug. 2005 (CEST)

RFC Links

Die Links auf die RFC's verweisen alle auf RFC 1. Ist das so gewollt?!? -- Matze 09:23, 19. Okt 2005 Unterschrift nachgetragen durch Stefan506 13:50, 19. Okt 2005 (CEST)

Das scheint ein neuer Software-Bug zu sein, denn im Quelltext des Artikels ist es richtig. Ich habe mal in Wikipedia:Fragen_zur_Wikipedia#Automatische_Verlinkung_von_RFC gefragt. -- Stefan506 13:50, 19. Okt 2005 (CEST)

Unnötige Werbung?

Eine weitere Lösung für das NAT-Traversal-Problem stellen sogenannte Application Layer Gateways (ALG) dar. Diese sind zwischengeschaltete SIP-Proxys, die, auf einem NAT-Router bzw. einer Firewall installiert, für reibungslosen Transfer der SIP-Signalisierung und -Medienströme sorgen. Der IX66/IX67-Router der schwedischen Firma Intertex ist ein solcher ALG, der bei SIP-Telefonaten automatisch für die Öffnung der notwendigen Ports auf der integrierten Firewall sorgt. Außerdem markiert der IX66/IX67 RTP-Medienströme mit DiffServ-Bits, wodurch diese mit höherer Priorität über das Internet transportiert werden können.

Ist es nötig, den Namen der Firma Intertex und deren Produkt zu nennen? Ist das nicht unnötige Werbung? Oder gibt es keine alternativen Produkte am Markt, so dass dieses Produkt eine derart außergewöhnliche Stellung einnimmt und ein Erwähnen an dieser Stelle sinnvoll ist? (15.12.2005) --(nicht signierter Beitrag von 194.95.8.6 (Diskussion)) 17:05, 15. Dez. 2005 (CET)

Muss definitiv nicht sein, habs umformuliert Thomas 21:25, 16. Dez 2005 (CET)

Teilnehmerzahl?

Unterstützt SIP nun "ein oder mehr" oder "zwei oder mehr" Teilnehmer? Vergleiche ersten Satz und Abschnitt Funktionsweise, zweiter Absatz. --(nicht signierter Beitrag von 128.176.152.101 (Diskussion)) 15:08, 11. Jan. 2006 (CET)

Der Wortlaut ist richtig. Im ersten Abschnitt steht "Kommunikationssitzung zwischen zwei" und im zweiten Absatz steht "Sessions mit einem oder...". Es ist also eine Session mit einem Partner, also zwischen zwei Partnern. -- Ole.Hinz 14:24, 27. Mär 2006 (CEST)

Protokoll

Kann jemand sagen, auf welchem Protokoll SIP in der Regel aufsetzt? Es wird wohl TCP oder UDP sein. --(nicht signierter Beitrag von 84.150.53.229 (Diskussion)) 18:18, 28. Feb. 2006 (CET)

Nach RFC3261 sind sowohl TCP wie auch UDP in der Implementierung vorgeschrieben. Dabei dient TCP mehr als Fallback, wenn UDP nicht funktioniert. TCP kann aber auch erzwungen werden. SDP, RTP und RTCP setzen alle auf UDP auf. --Ole.Hinz 10:06, 27. Mär 2006 (CEST)

Mal eine kleine Korrektur. Im Normalfall (bei SIP über UDP) wird das SDP im Datenfeld der ersten SIP-Nachricht (Invite) übertragen. Das heißt es ist zwar ein eigenes Protokoll wird aber nicht als seperates Protokoll übertragen. --(nicht signierter Beitrag von Rockopa1 (Diskussion | Beiträge)) 20:49, 3. Jul. 2008 (CEST)

Weblink defekt?

Der erste Weblink, "IMS SIP Technology Overview", verlangt die Eingabe einer Mail-Addresse und Name damit man das angeforderte Paper bekommt. Kennt hier jemand eine Alternative? Ist meiner Meinung nach nicht so gut für direkte Verlinkung geeignet. --Khong 21:15, 4. Jun 2006 (CEST)

Angriff?

Da SIP-Server verteilt sind, betrifft ein solcher Angriff nur den jeweiligen Anbieter und nicht die gesamte über SIP vermittelte Telefonie. Dieser Satz ist

• schwer verständlich (welcher Angriff?)
• und aus dem Kontext gerissen.

Was ist damit exakt gemeint: --193.81.246.92 16:47, 9. Aug 2006 (CEST)

Damit ist gemeint, dass es keinen zentralen Anbieter gibt, sondern viele kleine - wenn einer ausfällt (beispielsweise aufgrund eines Angriffs) sind die anderen nicht betroffen. Ich finde den Satz eigentlich verständlich und empfinde ihn nicht als aus dem Kontext gerissen. --Inquisitive Mind 19:20, 2. Jul. 2010 (CEST)

ICE

ICE ist kein Protokol sondern nur eine Beschreibung wie andere Protokolle wie STUN, TURN und Verfahren wie Realm-Specific IP angewendet werden sollen. --(nicht signierter Beitrag von 194.138.39.37 (Diskussion)) 12:10, 6. Nov. 2006 (CET)

Protokoll Videotelefonie bei UMTS

Aus Artikel: "SIP wurde auch vom 3rd Generation Partnership Project (3GPP) als Protokoll für Multimediaunterstützung im 3G-Mobilfunk (UMTS) ausgewählt." Meines Wissens kommt für die Videotelefonie das leitungsvermittelte 3G-H.324M Protokoll zum Einsatz. http://www.netbricks.com/pdfnew/H324M-bricks.pdf --(nicht signierter Beitrag von 134.60.106.133 (Diskussion)) 00:23, 29. Jan. 2007 (CET)

In dem PDF wird keine Aussage darüber gemacht, ob das 3GPP H.324 ausgewählt hat. Meines wissens nach wird SIP bevorzugt, in der Praxis aber nicht unbedingt eingesetzt. --Thomas 09:25, 29. Jan. 2007 (CET)

Ab Release 5 wird SIP als Signalsierungsprotokoll für das IMS eingesetzt. (3GPP TS 24.229) ---- 19:47, 23. Mär. 2007 (CET)

Infobox

Ich bin ja froh, dass sich endlich jemand gefunden hat, den SIP Artikel auszubauen. Die Infobox sollte aber noch dahingehend angepasst werden:

• Transport: nicht nur TCP, sondern vor allem auch UDP und SCTP
• ports: 5060 ist nur ein default port und sollte auch so genannt werden.
• Standards: da hab ich generell bei dem ganzen Artikel Bauchschmerzen, es gibt einen ganzen Sack voll Erweiterungs-RFCs, die einen weniger wichtig die anderen unverzichtbar (z.B.: RFC3264). Eigentlich sollte man eine eigene Infobox machen, mit allen Standards bzgl. SIP nach Funktionalitäten geordnet.

Gruß --Andys 20:43, 11. Feb. 2007 (CET)

Inkompatibilität durch Einfachheit?

Der letzte anonyme Autor hat folgenden Absatz wie kursiv gestellt vervollständigt:

Im Gegensatz zu H.323, das von der ITU-T stammt, wurde SIP mit Blick auf das Internet von der IETF entwickelt und orientiert sich an der Architektur gängiger Internet-Anwendungen. Dabei wurde von Beginn an auf leichte Implementierbarkeit, Skalierbarkeit, Erweiterbarkeit und Flexibilität geachtet, wobei es aber gerade hierdurch oft zu Problemen bei der Interoperabilität zwischen verschiedenen Herstellern und Applikationen kommt.

Das finde ich hoch interessant! Da wir ja auch versuchen ein Protokoll zu erfinden, welches leicht, skalierfähig, flexibel und erweiterbar ist - äh, ehrlich gesagt, ich denke wir haben es schon - würde ich wahnsinnig gern wissen wollen was SIP und/oder wir übersehen haben, weswegen wir mangelhaft interoperabel werden. Kurzum, her mit den dreckigen Details! --lynX

nachdem ich den hier kursiv gesetzten Absatz gelöscht hatte, hatte sich der Schreiber bei mir beschwert (siehe meine Diskussionsseite). Nun, er hat recht, dass viele RFCs vieles offen lassen, gar manches SHOULD oder MAY kann zu Problemen führen. Es ist gerade auch bei VoIP eine bekannte Unsitte Drafts zu implementieren, bevor sie stabil sind. Aber mit der "Einfachheit" hat das nichts zu tun. Allerdings passt der kursive Beitrag allemal nicht in's Wikipedia, er gibt eine persöniche Meinung seines Verfassers wieder und ist wahrscheinlich auch ein NPOV Verstoss. --Kgfleischmann 19:08, 31. Mär. 2007 (CEST)

bin auch der Meinung, dass der NNPOV Abstatz hier nicht hin gehört. Besonders unter guter Skalierbarkeit verstehe ich persönlich etwas anderers. Ich denke allerdings, dass die erwähnte Inkompatibilität nicht durch halbfertige drafts und andere prorietäre Ergänzungen entstehen, sondern vor allem durch die hohe Flexibiltät des RFC3261 inhärent ist, z.B. kenne ich keinen Hersteller der zu RFC3261 "full compliant" (im wahren Sinne des Wortes, nicht was auf dem Papier steht) wäre oder das in den nächsten Jahren je erreichen wird, von den ganzen Ergänzungs-RFC natürlich ganz zu schweigen. Ich kann allerdings nicht zustimmen, dass SIP auf http basiert, nur ein paar zentrale Mechanismen sind zur Basis von SIP geworden, z.B. das transaction-model, damit hört die reine Basis auch schon auf. "angelehnt" wäre besser! --Andys 19:46, 31. Mär. 2007 (CEST)

@http: "angeleht" findet meine Zustimmung, basiert kann einen falschen Einduck erwecken

@Inkompatibilität: Ein jeder hat seine Erfahrung und eine Enzyklopedie ist nun mal kein Blog und daher nicht der Ort diese zu publizieren. Aus diesem Grunde habe ich auch im Artikel gekürzt und nicht "geblogt"

--Kgfleischmann 20:01, 31. Mär. 2007 (CEST)

Verstehe die Bemerkung nicht, dass SIP inkompatibel zu HTTP ist. Formal angelehnt, fein, zum Beipiel menschenlesbar. Aber »inkompatibel« ist verwirrend, stehen die beiden Protokolle doch nicht in Konkurrenz oder wären Untermengen voneinander. Könnt man nicht »(ist zu diesem aber nicht kompatibel) und ist deutlich besser für IP-Netze geeignet« streichen oder stattdessen nur klarer schreiben »und ist deutlich besser als H.323 für IP-Netze geeignet«? Fritz Jörn 22:20, 4. Mai 2009 (CEST)

"und ist deutlich besser als H.323 für IP-Netze geeignet"???? Klingt und ist erschreckend unenzyklopädisch. Auch mit H.323 kann man in Internet telefonieren, wo auch sonst. Der Grund, warum SIP das Rennen gemacht hat ist sehr vielschichtig; eine Erörterung würde den Rahmen dieses Artikels sprengen. Die Kompatibilitätsfrage SIP/HTTP ist aufgesetzt und führt zu nichts. Die Macher von SIP hatten schlicht beim SIP-Design HTTP im Hinterkopf. HTTP ist also das Vorbild einiger Designprinzipien von SIP. Gruß --Kgfleischmann 23:23, 4. Mai 2009 (CEST)

"Die dafür verwendeten UDP-Ports werden dynamisch vergeben, was die Verwendung von SIP in Verbindung mit Firewalls oder Network Address Translation (NAT, RFC 2663) schwierig macht ..." Dieser zutreffende Satz im Artikel ist ein direkter Widerspruch zur angeblichen Einfachheit. Schwieriger ist es bei H.323 auch nicht, eher im Gegenteil. --84.157.204.158 22:58, 1. Aug. 2012 (CEST)

tel-URI => SIP-URI?

Zitat: "Bsp: "tel:+49-69-1234567". Diese kann bei Bedarf in eine SIP URI gewandelt werden Bsp: "sip:+49-69-1234567@domain"."

Meines erachtens ist das ein weit verbreiteter Irrtum. Wie ich das verstehe kennt eine SIP-URI keine semantic die eine tel-URI beinhaltet. Für die SIP-URI ist die Telefonnummer im Userpart einfach ein String der den Usernamen darstellt. Country Code, Network Destination Code etc pp der Telefonnummer können natürlich wieder umgewandelt werden, aber das erfordert spezielle Logik die meines Wissens in Standardkomponenten nicht enthalten ist.

Ich bin mir natürlich bewußt das das Verständnis im Artikel weit verbreitet ist, habe aber schon öfter erlebt das es deshalb Mißverständnisse über mögliche Funktionen gibt (Zum Beispiel das der User ja seine Telefonnummer in ein Adressfeld eingeben kann, etc)

Ich schlage vor die Verwendung der tel-URI als user name einer SIP-URI entsprechend kommentieren.

Grüße, Mattes --(nicht signierter Beitrag von 193.254.155.48 (Diskussion)) 09:02, 27. Apr. 2007 (CEST)

Hallo Mattes,

• Es stimmt dass ein SIP-URI auf Protokolebene keine semantic kennt, der SIP-UA aber schon, denn der SIP-URI erlaubt eine phone-number encoding, die Interpretation im UA selbst ist nicht standardisiert aber üblich (s.u.), jedenfalls wird TEL-URI nicht immer eingesetzt um eine E.164 zu transportieren, Grund: Fehlende routing information in Request-URI, zum TEL-URI braucht man eigentlich einen ENUM, wenn man's korrekt macht, der ist aber meistens so nicht verfügbar.
• Mein revert war gestern nicht ganz korrekt. Der SIP-URI def. in RFC3261 enthält zwar den BNF telephone-subscriber, der ist aber nur in RFC2806 (TEL-URI) spezifiziert.
• Ich weiss nicht welche Standardkomponenten du meinst, kommerzielle SIP-stacks sicher nicht, reine SIP-Poxys brauchen's nicht sofern ::sie nur innerhalb eines SIP-netzes eingesezt werden, da hier keine Notwendigkeit einer "Umwandlung besteht. Aber von SIP-Proxys an Netz-Grenzen müsste es unterstützt werden. Kommerziell erhältliche B2BUA, so die SIP-SBCs (z.B von ACMEpacket) unterstützen dies, da die Umwandlung eigentlich nur bei SIP-Netz-Übergängen notwendig wird.
• Eigentlich macht die Umwandlung nur in B2BUAs Sinn, da für Proxies die to- and from-header nicht verändert werden können und im TEL-URI format verbleiben würden. Jedoch kann ein stateful SIP-Proxy den Request URI durchaus auf einen SIP-URI umsetzen, zwecks routing für nachfolgende hops.

Vorschlag den Satz im Artikel umzuändern in: Diese kann in bestimmten Fällen in eine SIP URI gewandelt werden Bsp: "sip:+49-69-1234567@domain. Gruß --Andys 17:51, 27. Apr. 2007 (CEST)

Hi Andy,

ich freue mich über Deine ausführliche Antwort.

Natürlich hast Du recht, man kann eine tel-URI nicht routen, der saubere Weg ist allerdings das verwenden eines route headers und nicht das faken eines user name (ENUM braucht man eigentlich nur am proxy). Zitat aus 2806: "Unless a SIP UA connects directly to a PSTN gateway, one of the SIP proxy servers has to translate the "tel" URI to a SIP URI, with the host part of that URI pointing to a gateway."

Du hast natürlich recht das to und from nicht umgeschrieben werden dürfen, aber die werden ja auch nicht fürs routing verwendet, die request line kann man natürlich umschreiben (siehe zum Beispiel die IMS Umschreibeorgie), aber dafür braucht man genau dann ENUM.

Mit Standardkomponenten meine ich alle Komponenten, auch stacks, die den RfC Funktionsumfang implementieren. Dort steht nämlich meines Wissens nirgends das man den user name einer SIP-URI ausschneiden kann und dann eine E.164 Nummer hat (im Gegenteil zu einer tel-URI, mit der man das machen kann), was bedeutet: es gibt keinen Standard wie das gemacht wird und damit wären die Ergebnisse nicht interoperabel.

Ich kenne zufällig die Kisten von ACME (mit der Idee eines SBC oder ALG habe ich aus verschiedenen Gründen so mein Probleme, aber das gehört wohl nicht hierher) und weiß das sie diese und eine Menge andere Funktionen haben um solche "Standardlücken" und außerdem eine ganze Reihe häufiger und seltener Kompatibilitätsprobleme "an der Netzgrenze zu lösen".

Worauf es mir ankommt ist einfach das darauf hingewiesen wird das das ausschneiden und umformatieren eines user name aus einer SIP-URI nicht standardisiert ist und das man, wenn irgendwer eine Telefonnummer in eine UA GUI eintippt und der die dann innerhalb einer SIP-URI weitergibt man nachher eine SIP-URI und keine Telefonnummer (E.164) mehr hat (und wie sollte man dann Telefonnummern und user names auseinanderhalten, die dürfen doch auch Zahlen enthalten).

Letztendlich führt das alles zu einer Menge interoperabilitätsprobleme und einem riesen Haufen spezifisher Logik mit der alle möglichen Fehlerfälle unterschieden werden müssen.

Grüße, Mattes --(nicht signierter Beitrag von 80.136.152.40 (Diskussion)) 21:24, 29. Apr. 2007 (CEST)

Hallo Mattes,

Es stimmt natürlich dass die Umformung von sip-uri <=> tel-uri nicht standardisiert ist, da die Verwendung einer E.164 im sip-uri nicht standardisiert ist und dass es dadurch zu Interoperabiltäten kommt, aber ist das wirklich die einzige Interoperabilität? SIP hat sich leider die Interoperabilität zu Eigen gemacht (sonst hätten solche Firmen wie ACME nicht solch einen Erfolg), und das liegt sicherlich nicht nur an voreilig implementierten SIP-drafts sondern bereits in den fertigen RFC3261 begründet. (übrigens wird to- and from-header zwar nicht zum routen benutzt, zum display in manchen Fällen allerdings schon und deswegen braucht man eben B2BUA die alles umformen).

Die Umformung obwohl nicht standardisiert, wie viele proceduren für SIP, ist nun mal gängige Praxis, und funktioniert eigentlich ganz gut, solange man sich darauf beschränkt, dass der username eine E.164 enthält und nichts anderes, von ein paar Ergänzungen abgesehen, wie z.B, "Anonymus" etc...;)

Wenn du auf Interoperabiltäten eingehen willst, dann bitte in einem neuen chapter im Artikel (dein Punkt u.a. hat ein eigenes chapter sicherlich verdient), im chapter Funktionsweise würd ichs nicht sehen, sonst wird es einfach zu überladen.

Gruß --Andys 17:45, 30. Apr. 2007 (CEST)

Hallo Andy

Das solche Firmen wie ACME Erfolg haben hat meiner Erfahrung nach hauptsächlich damit zu tun das Architekturmuster aus der Leitungsvermittlung auf SIP Netze aufgepfropft werden (oder anders gesagt das Netzbetreiber SIP einführen, aber ihre Strukturen, sowohl auf Netz als auch auf Prozessebene, dafür nicht ändern wollen). Aus der gleichen Quelle wird die Flut von Drafts gespeist die Du erwähnst.

Das die Umformung im Prinzip funktionieren kann ist mir schon klar und dem widerspreche ich ja auch nicht. Mein Punkt ist einfach folgender: die Vorkehrungen um dafür zu sorgen das, wie Du schreibst "der username eine E.164 enthält und nichts anderes" sind im Standard nicht vorgesehen und weit davon entfernt trivial zu sein. Die Umformung ist natürlich auch nicht standardisiert, aber das liegt nicht daran das die Umformung an sich so schwierig wäre, sondern das es kein zuverlässiges Mittel gibt Deine Vorraussetzung zu erfüllen, jedenfalls keines das ich kenne.

Dafür ein eigenes Kapitel fände ich übertrieben, wie wäre es mit dem einfachen Hinweis das "es übliche Praxis ist, aber kein entsprechender Standard existiert"?

Ein eigenes Kapitel für interoperabilität von SIP Netzen könnte man sich überlegen, aber wäre das nicht mehr ein Wikibook?

Noch eine kleine Anmerkung in eigener Sache:

SIP ist ein peer-to-peer Protokoll (_kein_ P2P Netz!) und die Idee eines SBC passt da einfach nicht rein. Vordergründig lösen die SBCs Probleme, aber langfristig führt das zu einer nur mit viel Geld zu reparierenden Architektur (siehe die ganzen XCON Protokolle). Über die Gründe warum ich das denke können wir uns gerne mal unterhalten, aber das passt wohl nicht hierher. --(nicht signierter Beitrag von 80.136.153.45 (Diskussion)) 08:54, 1. Mai 2007 (CEST)

Hallo Mattes,

dein Vorschlag ist ok, ein knapper Kommentar ohne grosse Ausführung deutet auf das Problem hin, ohne von dem Titel abzuschweifen.

Noch meine Meinung zu SBCs: ´Weniger die SBC als vielmehr die bei ETSI spezifizierten iBCF/iBGF Systeme (B2BUAs) haben eine Zukunft für die Abgrenzung und Sicherung von SIP-Netzen zu anderen Carriern. IETF ist da auch schon ganz heftig beim Spezifizieren, allerdings mit eigenen Vorschlägen. Stimmt SIP ist kein Link zu link Protokoll, aber diese Zeiten der Vermittlungstechnick sind nun mal vorbei (obwohl manche der Konzepte besser waren, aber zu eng geworden). Alles fliegt jetzt auf SIP, mit IMS wird es wohl oder übel durch die Decke gehen, ob's jetzt rein passt oder nicht. Die Netzbetreiber (aus alten Tagen) tun ihr Übriges, wie du schon sagtest. Gruß --Andys 09:18, 1. Mai 2007 (CEST)

Hallo Andys

alles klar. PS: Auf IMS würde ich nicht mehr wetten, SIP als Protokoll ja, auf jeden Fall, aber IMS, pffff, ich glaub nicht mehr an IMS als Diensteplattform. Wenn da was gemacht wird dann auf Basis von JSR289 (AR). Ob sich IMS als session Plattform durchsetzt oder nicht hängt davon ab was mit P2PSIP passiert. Ich weiß das die Festnetzbetreiber alle auf IMS fliegen und die Kabelnetzjungs auch, aber ob diese teuere, komplexe Plattform mit ihren Architekturmängeln auf Dauer gegen P2PSIP wettbewerbsfähig ist? Das wäre nur Vorstellbar wenn die Minutenpreise auf ungefähr heutigem Niveau stagnieren (und jetzt brechen den IMS Herstellern schon die Business Modelle weg, weil die Preise für Session Control zu schnell fallen), aber das werden sie nicht tun? Am Ende geht es darum wer die Commodity "Voice" ohne schnickschnack (wie QoS und ähnliches Zeugs) am billigsten Produzieren kann. --(nicht signierter Beitrag von 80.136.153.45 (Diskussion)) 21:24, 1. Mai 2007 (CEST)

Hallo Mattes,

doch noch mal zurück zum tel-uri<=>sip-uri: schau mal RFC3261 chap "19.1.6 Relating SIP URIs and tel URLs" nach. Da ist eine Konvertierung schon festgelegt über den uri parmaeter user=phone, damit ist klar dasss in diesem Fall der user part als phone number interpretiert wird ohne post dial digits. Sicherlich nicht in allen Fällen sauber durchspezifiziert (was ist mit service codes mit # und * und overdecadic digits A-F?) aber genug um nicht behaupten zu können es sei nicht spezifiziert. Gruß --Andys 11:12, 3. Mai 2007 (CEST)

Request to add white paper:::::

Dear Editor, Please give me permission to add a very informative white paper "SIP Protocol Overview" http://www.radvision.com/NR/rdonlyres/51855E82-BD7C-4D9D-AA8A-E822E3F4A81F/0/RADVISIONSIPProtocolOverview.pdf/ Upon your agreement I shall edit as above. Paul Glen 09:01, 12. Jul. 2007 (CEST)

Server pflicht oder geht es auch direkt?

In dem Artikel steht nicht, ob man, um über SIP mit jemanden zu kommunizieren, einen SIP-Zwischenserver braucht oder ob es auch direkt geht. Dass es direkt geht, ist mir schon klar. Nur viele denken, dass SIP nur mit einem SIP-Provider bzw. einem eigenen SIP-Server funktioniert. --(nicht angemeldeter Benutzer) --(nicht signierter Beitrag von 84.153.107.223 (Diskussion)) 20:21, 6. Okt. 2007 (CEST)

Es geht auch so, allerdings sollten dann

1. beide Partner ohne NAT auskommen. Lösungen, die ohne diese Einschränkung auskommen, mögen zu realisieren sein, sind aber in der Regel von eingeschränkter Praxistauglichkeit
2. beide Partner immer auf der gleichen IP-Adresse erreichbar sein.

--Kgfleischmann 10:07, 7. Jun. 2008 (CEST)

Das mit der gleichen IP-Adresse ist nicht so ganz richtig. Benutzt man kphone (open source) ist es ebenfalls möglich einen Partner über den Rechnernamen (z.B.: computer.domainxyz.com) zu erreichen. D.h. über DNS (Domain Name System) wird dann die zugehörige IP-Adresse ermittelt. Aber es ist auf jedenfall zu empfehlen, einen Proxy einzusetzen. Asterisk free PBX (open source) ist super einfach zu konfigurieren und bringts auf jeden Fall. http://www.asterisk.org/. Dieser unsignierte Beitrag stammt von Benutzer:Rockopa1.

Da hat mich jemand missverstanden, es kommt nicht darauf an ob Rechnernamen oder IP, sondern dass eine von den beiden bekannt sein muss, und zwar für jeden Gesprächpartner, wo immer der auch gerade ist. --Kgfleischmann 21:55, 3. Jul. 2008 (CEST)

Richtigstellung

Zitat: Da über eine SIP-Adresse die aktuelle IP-Adresse eines Teilnehmers ermittelt werden kann, bietet sich auch die Möglichkeit, dass man in Zukunft über eine Adresse erreichbar sein wird, die dann sowohl für E-Mail als auch Telefonie verwendet werden kann.

Anmerkung: Über das SIP-Protokoll kann nicht die aktuelle IP-Adresse ermittelt werden, sondern das geschiet über Umwege. Prinzipiell funktioniert das so: Ein Teilnehmer meldet sich am SIP-Registrar an, welcher die aktuelle IP-Adresse an den Teilnehmernamen bindet und an den SIP-Locationserver übermittelt. Will nun ein Teilnehmer eine Verbindung zu einem anderen Teilnehmer aufbauen, gelangt die INVITE-Nachricht zunächst an zuständigen Proxy-Server der in der Lage ist, die IP-Adresse über den Locationserver herauszufinden und die Nachricht entsprechend weiterleiten kann.

Leider fehlen in diesem Artikel die feinen Details die meiner Meinung für das Verständnis wichtig sind. Über die Funktion von SIP-Registar und SIP-Locationsserver wird kein Wort verloren. Zusammen mit dem Proxyserver ist das, das eigendliche Herzstück von VoIP. In der Regel sind das nicht einzelne Server. Meistens sind sie in einem Kästchen vereint (es handelt sich hier um die logischen Funktionen) . Bei der Graphik über den prinzipiellen Verbindungsaufbau fehlen auch die Nachrichten "100 Trying" und "180 Ringing" die sozusagen als Reaktion auf das INVITE gesendet werden und auch schon in der Standartisierung verankert sind.

Empfohlene Literatur: Badach, Anatol: ”Voice over IP Die Technik“, Carl Hanser Verlag, 2005, 3-446-40304-3 Dieser unsignierte Beitrag stammt von Benutzer:Rockopa1.

Was mich angeht, ich gebe dir in weiten Teilen recht. Ich trage mich schon seit längerem mit dem Gedanken, der Artikel gebneralzuüberholen. Freue mich allerdings über jeden, der mir beim überbessern zuvorkommt. Sein englisches Gegenstück en:Session Initiation Protocol ist da (verwandte Artikel dazugerechnet) ein Stück besser, könnte also als Ausgangspunkt gelten. --Kgfleischmann 14:33, 4. Jul. 2008 (CEST)

Werde mir mal ein paar Gedanken darüber machen was man umstrukturieren sollte. Eine Anlehnung an den Englsichen Artikel finde ich nicht gut, da ja dort ebenfalls die gleiche Grafik zu finden ist, die den ganzen Sachverhalt nicht richtig wiederspiegelt. --Rockopa1 20:09, 4. Jul. 2008 (CEST)

An das dortige Bild dachte ich auch nicht, eher an die Struktur des Artikels. Es gibt aber sicher noch andre Ansätze, ich bin gespannt. --Kgfleischmann 23:29, 4. Jul. 2008 (CEST)

STUN Protokoll

Im Artikel heisst es:

Abhilfe für dieses Problem schafft der Einsatz von STUN (Simple Traversal of UDP over NATs), welches NAT-Router erkennt und durchdringt, .... Durch den Einsatz des STUN-Protokolls wird die IP-Adresse und der Port ermittelt, mit dem die NAT-Firewall bzw. der NAT-Router nach außen (d.h. in das öffentliche Internet) geht.

IMHO funktioniert STUN nur bei Full Cone NAT. Die häufigste heutzutage vorkommende Art von NAT ist "port restricted cone", wie es z.B. im Masquerading von Linux Netfilter verwendet wird. Ich habe die Problematik auf einem Linux-Router (DD-WRT) untersucht, und bin dabei zu folgendem Ergebnis gekommen:

Für jede abgehende Verbindung wird auf dem Router ein Mapping erzeugt, sodaß eingehende Antworten von der gleichen IP und Port (deswegen port restricted) eindeutig weitergeleitet werden können. Das Mapping hat eine bestimmte Lebensdauer, meist im Bereich von ca. 3 Minuten. Beim erzeugen eines neuen Mappings versucht Linux Netfilter den Quellport (aus dem LAN) auf der WAN-Seite beizubehalten. Ist der Port bereits von einem Mapping belegt, so wird ein neuer Port auf WAN-Seite zugeordnet.

STUN versucht zu einer bestimmten Kombination aus Quell-Port und -IP (die anschliessend vom Telefon für SIP verwendet werden soll) die vom Router erzeugte WAN-IP und -Port zu bestimmen. Die STUN-Abfrage selbst erzeugt im Router jedoch bereits ein Mapping, und da der anschliessende SIP-Call zu einem anderen Server geht (der SIP-Server ist in der Regel ein anderer als der STUN-Server) muss der Router ein neues Mapping mit einem anderen Port anlegen, solange das Mapping der STUN-Abfrage noch lebt. Der Port auf WAN-Seite ist dann ein anderer als der den die STUN-Abfrage zurückgeliefert hat, und die RTP-Pakete werden uns nicht erreichen, weil das Telefon in die SDP-Nachricht den Port aus der STUN-Abfrage einsetzen wird.

Fazit: innerhalb der Lebensdauer eines Mappings wird der Router auf WAN-Seite einen anderen Port vergeben als zuvor durch STUN ermittelt wurde, somit ist STUN keine Lösung für das NAT-Problem bei SIP.

Dass es in der Praxis dennoch häufig funktioniert hängt von vielen Faktoren ab, z.B. die Häufigkeit mit der ein Telefon eine STUN-Abfrage durchführt. Je seltener die STUN-Abfrage gemacht wird, umso geringer ist die Wahrscheinlichkeit dass das STUN-Mapping zum Zeitpukt eines Calls noch lebt. Da DSL-Verbindungen jederzeit neu aufgebaut werden können (z.B. wegen Inaktivitäts-Timeout, Störungen, usw.) und damit die Zuordnung einer neuen IP verbunden ist, ist es bei DSL erstrebenswert das Telefon in kurzen Intervallen Registrierungen und STUN-Abfragen durchführen zu lassen. Nach IP-Änderungen ist das Telefon bis zur nächsten Registrierung nicht von aussen erreichbar. Abgehende Gespräche sind bis zur nächsten STUN-Abfrage nicht möglich. Aus dem Grunde erzwingen manche VoIP-Provider (z.B. Carpo und Sipgate) ein Registrierungsintervall von 5 Minuten (egal was das Telefon vorgibt). Wenn das Telefon mit jeder Registrierung auch eine STUN-Abfrage macht, wäre in den 5 Minuten nur 2 Minuten ein Gesprächsaufbau möglich (das wäre der worst-case).

IMHO ist das einzige zuverlässige Heilmittel gegen die NAT-Problematik ein ALG für SIP auf dem Router. Das preiswerteste ALG ist ein Router mit "DD-WRT Voip" oder "Openwrt/Milkfish".

Gruss jochen58 --(nicht signierter Beitrag von Jochen58 (Diskussion | Beiträge)) 10:52, 12. Okt. 2008 (CEST)

"IMHO funktioniert STUN nur bei Full Cone NAT", sorry, das stimmt so einfach nicht. Es geht bei einem Port Restricted Cone NAT genau so gut, so der seine Hausaufgaben richtig erledigt! Voraussetzung ist natürlich, dass das Mapping vor "Zerfallsdatum" aufgefrischt wird (wiederholte STUN-Request zum Beispiel). Problematisch ist was ganz anderes: Viele "moderne" Access-Router agieren nur als NAT, nicht aber als PAT. Das heisst, wenn 2 UAs den gleichen Port benutzen geht es schief und man muss allen UAs im LAN händisch disjunkte Portbereiche zuordnen.

Zu deiner Beobachtung, Linux Netfilter agierte lange Zeit als Symmetrischer NAT, ob sich das zwischendurch geändert hat entzieht sich meiner Kenntnis.

Anderes Problem: "sodaß eingehende Antworten von der gleichen IP und Port ..."; damit beschreibst du u.U. einen symmetric NAT. Bei port restricted wird einfach ein Loch gebohrt(addresse:port), wer dieses kennt kann an diesen Port an dieser Adresse senden. Symmetric heisst, dass nur das Ziel der Request das kann.

DSL-Resets sind auch mit ALG tödlich

Gruß --Kgfleischmann 13:16, 12. Okt. 2008 (CEST)

Belege fehlen

'In der IP-Telefonie ist das SIP ein häufig angewandtes Protokoll'. Bitte belegen wenn dies bereits in der Einleitung steht. (nicht signierter Beitrag von 138.246.46.160 (Diskussion) 10:30, 2. Mai 2012 (CEST))

Abhörsicher?

Sind die Protokoll rund um SIP abhörsicher? Ist die Authentifizierung verschlüsselt bzw. gehasht?

Es gibt sowohl SIPS (SIP über TLS) als auch SRTP (verschlüsseltes RTP), die nicht mehr so einfach mitgelesen werden können, beide sind allerdings nicht so verbreitet. Bei SIP selbst wird die Authentifizierung mit Hilfe des Digest-Verfahrens durchgeführt. D.h. das Passwort geht nie im Klartext über die Leitung.

"Zu beachten ist, dass durch die Trennung von Sitzung und Medien diese auch getrennt verschlüsselt werden können ... Jede Kombination davon ist möglich." Diese Formulierungen im Artikel sind irreführend. Beides muss getrennt verschlüsselt werden, und nur das zusammen ist sinnvoll. Zur Verschlüsselung der "Medien" (des Gesprochenen) über RTP müssen die entsprechenden Schlüssel schon vorher mit der Sitzung über SIP ausgehandelt werden. Wenn das ohne Verschlüsselung von SIP erfolgt, also im Klartext, kann man es gleich bleiben lassen. Das Digest-Passwort soll nur verhindern, dass auf anderer Leute Kosten telefoniert wird. --84.157.204.158 23:36, 1. Aug. 2012 (CEST)

stimmt natürlich, habe es weiter ausgeführt --Andys / ☎ 08:35, 2. Aug. 2012 (CEST)

Ich glaube der Abschnitt ist zu euphemistisch. Besonders der letzte Satz bedeutet, dass bei Verwendung von SIPS und SRTP die Verbindung sicher sei. Da SIPS aber nur die Verbindung vom Endgerät zum Proxy absichert, aber nicht die Strecke vom Proxy des "Absenders" zum Proxy des "Empfängers", stimmt das nicht. Zwischen den Gesprächsteilnehmern ist also eine Strecke, deren Verschlüsselung keiner der Gesprächsteilnehmer kontrolliert und deshalb als unverschlüsselt angesehen werden muss. Das einzige mir bekannte Verfahren, das nicht diese Man-in-the-Middle-Lücke hat (und das es außerdem zu einer gewissen Verbreitung gebracht hat) ist ZRTP. 89.12.88.204 02:05, 23. Okt. 2014 (CEST)

Beispiel-INVITEs

Der Beispiel-INVITE nebst (zugehöriger?) Antwort irritiert mich etwas: Im INVITE wird über das "From"-Feld ein Tag übermittelt, der nach RFC 3261 (8.2.6.2) in der Antwort exakt so wie übermittelt im "To"-Feld zurückgegeben werden muss. Das ist ein elementarer Bestandteil um die Funktionalität von SIP-Proxies zu gewährleisten, da sonst bei viel Traffic zu identischen Zielen keine Unterscheidung mehr erfolgen kann worauf sich eine Antwort bezieht. Gleiches gilt im Übrigen für das "Call-ID"-Feld. Im gezeigten Beispiel unterscheiden sich die Inhalte beider Felder jedoch, und bei genauerer Betrachtung komme ich zu dem Schluss dass da zwei SIP-Pakete ohne Bezug zueinander da stehen.

Das finde ich enorm verwirrend, denn wenn sie sich nicht aufeinander beziehen und alleine für sich dastehen, sollte das m.M.n. so gekennzeichnet werden. Sinnvoller wäre es in meinen Augen aber, wenn man einen SIP-INVITE mit dazu passender Antwort abbildet.

z.B.:

So könnte ein SIP-Request aussehen:		Und so eine SIP-Response:
Startzeile INVITE sip:44455566@192.0.2.44;user=phone SIP/2.0 Header Via: SIP/2.0/UDP 198.51.100.1:5060;branch=z9hG4bK134853b6 Max-Forwards: 70 From: "Max Mustermann" <sip:12345678@198.51.100.5>;tag=as7d63ad66 To: <sip:44455566@192.0.2.44;user=phone> Contact: <sip:12345678@198.51.100.5:5060> Call-ID: 57fa2a9c5555c2f403be6067441e5024@192.0.2.44 CSeq: 103 INVITE Supported: replaces, timer Content-Type: application/sdp Content-Length: 249 Leerzeile Body v=0 o=stanley 1725266762 1725266763 IN IP4 198.51.100.5 s=Asterisk c=IN IP4 198.51.100.5 t=0 0 m=audio 44786 RTP/AVP 9 8 101 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv		Startzeile SIP/2.0 200 OK Header Via: SIP/2.0/UDP 198.51.100.1:5060;branch=z9hG4bK134853b6 To: <sip:44455566@192.0.2.44;user=phone>;tag=h7g4Esbg From: "Max Mustermann" <sip:12345678@198.51.100.5>;tag=as7d63ad66 Call-ID: 57fa2a9c5555c2f403be6067441e5024@192.0.2.44 CSeq: 103 INVITE Contact: <sip:44455566@192.0.2.44;user=phone> Content-Type: application/sdp Content-Length: 215 Session-ID: 17c71b371fc823a81939195919891d6a Leerzeile Body v=0 o=- 2146332032 2440400861 IN IP4 192.0.2.44 s=Obelisk c=IN IP4 192.0.2.44 t=0 0 m=audio 15326 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:8 PCMA/8000 a=ptime:20 a=sendrecv

(nicht signierter Beitrag von Lordgurke (Diskussion | Beiträge) 17:54, 4. Jan. 2016 (CET))