Diskussion:Session Initiation Protocol

message: "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)
thread_title:  Aus dem Artikel: 

message: 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)
thread_title:  Echo 

message: 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)
replies: text: 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)
thread_title:  RFC Links 

message: 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)
thread_title:  Unnötige Werbung? 

message: 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)
replies: text: 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)
thread_title:  Teilnehmerzahl? 

message: 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)
replies: text: 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)
thread_title:  Protokoll 

message: 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)
thread_title:  Weblink defekt? 

message: 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)
thread_title:  Angriff? 

message: 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)
thread_title:  ICE 

message: 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)
replies: text: 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)

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

message: 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)
thread_title:  Infobox 

message: 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)
replies: text: Es geht auch so, allerdings sollten dann 
#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
#beide Partner immer auf der gleichen IP-Adresse erreichbar sein.
--Kgfleischmann 10:07, 7. Jun. 2008 (CEST)

text: 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)
thread_title:  Server pflicht oder geht es auch direkt? 

message: 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)
replies: text: 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)
thread_title:  Richtigstellung 

message: '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)
thread_title:  Belege fehlen 

message: 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)
replies: text:  stimmt natürlich, habe es weiter ausgeführt --Andys / ☎ 08:35, 2. Aug. 2012 (CEST)
thread_title:  Abhörsicher? 

message: 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	
 (nicht signierter Beitrag von Lordgurke (Diskussion | Beiträge) 17:54, 4. Jan. 2016 (CET)
thread_title:  Beispiel-INVITEs