Talk:Session Initiation Protocol

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Telecommunications  
WikiProject icon This article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the quality scale.
 ???  This article has not yet received a rating on the importance scale.
 
WikiProject Computing / Networking (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Mid-importance).
 

What's the legal status of the SIP protocol?[edit]

I was about to fix a link in the text of Wengo which was trying to point to a page about 'Free Standards'. But then I noticed that the SIP page doesn't actually say if it's free/open or whatever. If someone can clear this up and add clarification to this SIP page that would be great. --DuLithgow (talk) 07:50, 13 October 2008 (UTC)

The protocol is covered by the IETF copyright which appears at the end of the RFC(s). It's basically an open-source type of license. --Kvng (talk) 15:02, 19 August 2011 (UTC)

I believed every RFC made public by IETF are open, not that they are GNU, rather open. Anyone can use those standards to implement their own product without giving any royalty to IETF of whomsoever. Mvineetmenon (talk) —Preceding undated comment added 10:21, 2 August 2012 (UTC)

SIP handler (URL protocol)[edit]

Does anyone knows how to make a clickable sip link ( sip://1231231234 ) to dial the number in the softphone? —Preceding unsigned comment added by 189.52.177.110 (talk) 21:55, 9 January 2008 (UTC)

I think you would make a link with "sip:user@example.com" as the URL, similar to how you link to mail addresses with "mailto:user@example.com". The browser you view the page in, must of course know what to do with a sip (or mailto) link, i.e., what program to start. You are talking about numbers, so perhaps you are referring to ordinary phone numbers. I don't know really how you would link to those. —Bromskloss (talk) 15:47, 29 January 2008 (UTC)
To link to just an e.164 telephone number, without specifying server or gateway? tel:+1-867-867-5309 works on a few mobile devices. K7L (talk) 15:49, 27 October 2013 (UTC)

Bandwidth[edit]

Could someone who knows about SIP please add some bits about bandwidth usage? Thanks. David Johnson [T|C] 14:30, 25 Jan 2006 (UTC)

A1. I feel it's important to distinguish between SIP (the signaling protocol), and RTP (widely used as the "data" protocol). A typical SIP "phone call" would generate around 8-10 SIP packets. If we assume the size of these packets to be typically less than 1200 size, and generally around 200 bytes in size. Per "phone call", we are talking around 10*200bytes = 2kb. Look at contents of all SIP messages exchanged during a typical phone call scenario (EG). Regarding RTP, it depends on the underlying codec that is used. GSM (13kbit/s), G.711 (64kbit/s) and Speex (2kbit/s - 44kbit/s) are common codecs used with SIP/RTP. Moogman 03:36, 30 September 2006 (UTC)

Don't forget all the protocol overheads of packetising all the data produced by the codec in question. For example, with G.711 (Mu-law and A-law), 64kbit/s is the raw data rate of the voice traffic. After packetisation with RTP and also any SIP signalling that may be present, a G.711 call over SIP uses approximately 85kbit/s in each direction of a call. JonTeh 01:32, 4 May 2007 (UTC)

SIP and RTP[edit]

Are we sure SIP uses RTP as transport protocol?


A1: SIP uses roughly 3-5 Kilobytes per second of bandwidth, this can vary depending on the codec being used, and be as high as 15 Kilobytes per second synchronously.x

A2: No, SIP does not use RTP for transport. SIP itself is transported over either TCP or UDP. UDP is more common.

SIP is associated with RTP: a SIP session describes (typically one) RTP session. When the SIP handshake is complete, the RTP session can be set up. (This is somewhat simplified). The comment above (A1) on bandwidth should refer to RTP, not to SIP. SIP bandwidth does not vary with the codec, since media is never transported with SIP. BTW, the current version of the article is correct with respect to SIP/RTP, but maybe it can be clarified. Yaron 11:58, Apr 5, 2005 (UTC)

Here's a shot-- worth reviewing before incorporating: "In typical use, SIP "sessions" are simply packet streams of the Real-time Transport Protocol (RTP). RTP is the carrier for the actual voice or video content itself." might be better said "In typical use, two endpoints use SIP to establish a dialog or session by exchanging SDPs. These SDPs tend to describe Real-time Transport Protocol (RTP) packet streams. RTP is the carrier..." Rhys 17 Aug 2005.

A3: SIP doesn't mandate any sort of trnasport media. It's just that UDP is the popular transport media becuase of it's less overhead than TCP. But now a days TCP is gaining populatiry as a transport for SIP(more so after SIPS). RTP on the other hand is the transport for media. When RTP transport starts, SIP messages are no longer needed, since signalling has been completed. Mvineetmenon (talk) 10:25, 2 August 2012 (UTC)

SIP and H.323[edit]

The opening paragraph of the article states that SIP is now "the leading protocol" for VOIP and is "replacing" H.323. My understanding is that this is not the case – that H.323 remains more commonly used than SIP. No source is cited for the assertion. The SIP vs. H.323 story seems to have long been surrounded by substantial FUD/hype, so it seems important to get the facts straight. A bit of balance seems called for (see, e.g., [1] for an alternative point of view). In fact, even some SIP promoters appear to acknowledge that H.323 remains dominant (see [2], which, after bad-mouthing H.323 mercilessly, says "The majority of existing IP telephony products rely on the H.323 suite"). Is there a reliable source to validate the statement, or should it just be removed? –Mulligatawny 04:50, 11 September 2005 (UTC)

I suggest creating a new wikipedia entry comparing the two protocols H.323 and SIP, and moving the second half of section "Protocol design" into it. It could make sense also for discusing convergence there. 07 Feb 07 —The preceding unsigned comment was added by 212.184.75.134 (talk) 12:06, 7 February 2007 (UTC).

Opinionated introduction[edit]

Maybe I'm in the minority, but the introduction seems pretty speculative and opinionated. While it may or may not be true that everything will converge to one network, there is no indication SIP will be the protocol used. It is well written, however.

One attempt to enable fixed/mobile convergence is the IP Multimedia Subsystem (IMS), which uses SIP. Codecatster 11:47, 25 October 2006 (UTC)
Another one being the 3GPP which has chosen SIP as their signalling protocol. Mvineetmenon (talk) 10:29, 2 August 2012 (UTC)

Well, the introduction might be opinionated, but one thing is for sure, SIP is the actual protocol used in the majority of scenarios involving voice transport over IP. About the convergence mmm... who knows? 81.114.228.2 16:01, 30 November 2006 (UTC) The Supernatural Protocols Anaesthetist

Protocol design[edit]

From the article:

A goal for SIP was to provide a superset of the call processing functions and features present in the public switched telephone network (PSTN).

Is there any evidence for this? All I can find is a quote that seems to contradict this :

SIP is not meant to be used as a strict Public Switched Telephone Network (PSTN) signaling replacement. It is not a superset of the Integrated Services Digital Network (ISDN) User Part (ISUP). [3]

Alf Boggis (talk) 13:49, 28 October 2005 (UTC)


Also from the article:

SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of the session, e.g. what IP ports to use

I wonder at "IP ports"...I thought IP does not have ports, but IP addresses? Matthi2 14:32, 7 May 2007 (UTC)

You are right, UDP, TCP ports were the right thing! --Kgfleischmann 17:45, 7 May 2007 (UTC)


Also from the article:

SIP-enabled telephony networks can also implement many of the more advanced call processing features present in Signalling System 7 (SS7), though the two protocols themselves are very different. SS7 is a centralized protocol, characterized by a complex central network architecture and dumb endpoints (traditional telephone handsets).

I do not claim to be an expert in PSTN but to my knowledge, telephone handsets do NOT talk SS7. It is the service switching point (SSP) nodes of the network that are nearest to end user that talk SS7 with other signaling entities. —Preceding unsigned comment added by 128.214.26.248 (talk) 10:52, 3 January 2008 (UTC)

Well having worked in the Telecommunications industry for the last 20 years in engineering capacities and having seen the development of VoIP protocols, (SIP being one of them), and having commissioned both legacy and IP based voice netowrks I can categorically state that the assertion that SIP, (or any other VoIP), based networks are "simple" network architectures is wrong. With SS7 you had single switches at each node which had integrated signalling capabilities right across the network up to the local exchange. The final leg between LE and handset using a completely different signalling principle but one that is again integrated in to the local switches. The most complicated SS7 ever became was to impliment a seperate "signalling" topology on top of "voice" network which required signalling switches, (known as Signalling Transfer Points ie STPs). This was done predominantly for redundancy purposes and wasn't actually necessary in order to implement SS7. In fact the vast majority of SS7 switches had STP functionality inherently, (only small switch vendors products didn't). VoIP on the other hand is predominantly characterised by mulitple boxes, (Media Gateways, Servers, Controlers etc) which all have to intercommunicate across both their own "internal" networks as well as the infrastructure network as a whole in order to work properly. Simplicity is NOT a feature of VoIP networks as they mark a move to what is called distibuted computing in other industries. —Preceding unsigned comment added by 82.45.124.228 (talk) 10:37, 29 October 2010 (UTC)

Not a web directory[edit]

This article has been bothering me for a long time - I've decided to remove the entire Software section from the article, since it has become a web directory of sorts. I'm sure some of the links I removed belong in the article (and some indeed do appear in the text), but I doubt there would be more than a handful. If someone wants to add a link back in, they should be required to prove that it belongs in this encyclopedia, otherwise they should be directed to dmoz.org. Is this OK with everyone? Mindmatrix 01:33, 9 November 2005 (UTC)

I disagree. The removed section is in my opinion is not a mere collection of external links. In my opinion the section that was removed is an valuable portion of this article and should remain. While I would admit the list is long and inclusive it and other sections like it are one of the reasons I use wikipedia instead of dmoz.org (when is the last time anybody searched dmoz.org?). Wikipedia can include freeform text and lists to related information, it is open in contrast to dmoz.org which is closed. Wikipedia is not the Encyclopedia Brittanica and I use it more often than either EB or dmoz.org because it can and does include links and subsections that provide lists that can point to actual organizations (or external document links). If a short list can be justified, I see no reason an inclusive list of companies and organizations that develop sip software should not. The router article includes a list of router companies and is better off for it. Should we start shortening that list as well? Thane Eichenauer 04:56, 9 November 2005 (UTC)

Little problem concerning Gizmo[edit]

Sorry to maybe report this the wrong way, but I think there is a problem concerning Gizmo: The Gizmo Project has implemented SIP has integrated XMPP in their client and service.. I'm not sure, but I think this should be: The Gizmo Project has implemented SIP and integrated XMPP in their client and service.

SIP Security[edit]

a imho big problem of this article is the complete lack of (in)security aspects of SIP. RFC3261 mentions over 20 pages the different threats and suggestions on solutions of this problem

SIP gleaning: merge here[edit]

"SIP gleaning" is a one short paragraph long article that would barely become anything much larger. I don't see any rationale why it shouldn't be part of main SIP article. --GreyCat 11:59, 3 October 2006 (UTC)

I'm a bit confused about "SIP gleaning". Could you name a RFC which defines this? --Kgfleischmann 12:17, 3 October 2006 (UTC)
This seems to be a neologism or marketing term. The only SIP device manufacturer that mentions the phrase is Nortel (see this google search, which yields 14 hits total). I don't think we need to discuss this - I'm going to redirect without merging. If anyone wants to merge the info, by all means do so. The topic most certainly doesn't warrant its own article. Mindmatrix 14:51, 3 October 2006 (UTC)

Must agree with MindMatrix here, a wording from a switch user manual they sell (I'm not from Nortel!):

SIP NAT and Gleaning Support

The IP end points on a network are typically assigned private addresses. Voice calls from and to the public network need to reach end points on the private network. As a result, NAT is required to allow proper routing of media to end points with private addresses. The SIP carries the identification of the IP end point (IP address/Port) within the body of the message. The voice media which gets directed to the private IP address identified in the signaling message cannot be routed and results in a one way path. Therefore, switches or end point routers shall NAT the SDP and create sessions for the media communication. The term "gleaning" is likely not relevant to the context, says how a NW element (can) optimises such function/feature. 81.114.228.2 15:40, 5 December 2006 (UTC)The Supernatural Protocols Anaesthetist

I also agree to merge it with this article. Sae1962 (talk) 10:41, 15 February 2011 (UTC)

External links cleanup[edit]

This article is attracting many links that do not meet WP:EL guidelines. Particularly, links to commercial websites, FAQs, Forums, etc. WP is also not a directory of links WP:NOT and by simply reorganizing the External Links section into categories does not satisfy this guideline. Replaced most links with dmoz (WP recommendation) and request link additions that meet WP guidelines be discussed and agreed upon here in the talk page first. If there are any Standards websites or other Official links that have been removed, please comment here and add them back. Thanks for helping to keep this article free of spam. Calltech 13:18, 1 January 2007 (UTC)

The Entire list of SIP related specs organized by IETF WG


I would like to add informative content in the form of a white paper on "SIP Protocol Overview" as an external link to the Wikipedia page "Session Initiation Protocol" . The URL of the white paper is

http://www.radvision.com/NR/rdonlyres/51855E82-BD7C-4D9D-AA8A-E822E3F4A81F/0/RADVISIONSIPProtocolOverview.pdf

Please advise if this would be agreeable to the editor. 05:26, 29 May 2007 (UTC)AIMSzpc

AIMSzpc 14:23, 10 June 2007 (UTC)

Just begin editing, there will be people who correct if necessary --Kgfleischmann 15:01, 10 June 2007 (UTC)

Suggesting an article about SIP and NAT: http://www.voipuser.org/forum_topic_7295.html Jodi.a.schneider (talk) 23:50, 4 January 2009 (UTC)

Suggest adding the IETF SIP Working Group page as an external link: http://tools.ietf.org/wg/sip/ Jc3 (talk) 18:24, 9 January 2009 (UTC)

SIP in OSI app or pres layer?[edit]

Hi. This is a 'passer by' with (still) little experience adding to Wikipedia, so please forgive any protocol mis-steps here, but this is a simple thing... I notice that this article says SIP is in the application layer of the IP model and the presentation layer of the OSI model. But if you look at the wikipedia entry for the OSI model, it shows SIP in the application layer there, too. —Preceding unsigned comment added by DrTLesterThomas (talkcontribs) 16:21, 9 June 2008 (UTC)

As I read further, I may have missed two important points: (1) quoting from the wikipedia OSI entry: "Not understanding that the pure seven-layer model is more historic than current, many beginners make the mistake of trying to fit every protocol they study into one of the seven basic layers." (2) quoting from the wikpedia "Internet protocol suite" entry: "The IETF has repeatedly stated that Internet protocol and architecture development is not intended to be OSI-compliant."... (hmm, not sure how to properly 'sign' these entries.) —Preceding unsigned comment added by DrTLesterThomas (talkcontribs) 16:40, 9 June 2008 (UTC)

Ah... learned how to properly sign; let's see if it works: DrTLesterThomas (talk) 17:28, 9 June 2008 (UTC)

Imho it is a bad idea to press SIP into the OSI model, it never was designed for. SIP is an application, therefore it is an app. layer protocol. As TCP/IP does not know the OSI-session-layer, SIP itself is in charge to define functions decribed there, if it needs them. The term session, as used in SIP, has nothing to do with the term session in the OSI model. --Kgfleischmann (talk) 03:42, 10 June 2008 (UTC)
SIP is also placed at the session layer in the Session (computer science) article, and in the Session Layer article. Please clarify and contribute to these. Mange01 (talk) 10:27, 6 January 2009 (UTC)

SIP-T and SIP-I[edit]

SIP-T is no extension to SIP, but practises for interfacing SIP to the PSTN. SIP-I (SIP ISUP mapping) is from ITU (Q.1912.5) which specifies recommendations for interworking of ISUP/BICC and SIP-T. SIGTRAN has an own article, so the chapter extensions is not needed. --Kgfleischmann (talk) 08:09, 18 July 2008 (UTC)

I renamed the chapter "extensions" to "SIP-ISUP" interworking, as that is what SIP-I and SIP-T are good for. The SIP sided duties to make that interworking work are a scattered over different RFCs, some written for interworking, others having a more general purpose (Examples are the PRACK and UPDATE primitives, the "early ringing" feature). The chapter should be extended. SIP-T and some BICC-applications (the ISUP side of the thing) should be mentioned. --Kgfleischmann (talk) 04:21, 19 July 2008 (UTC)

SIP and lawful interception[edit]

It is bogus that SIP can't handle lawful interception. You can intercept SIP traffic on an IP-line and also you can use a SIP-server to initiate a lawful intercept of the call-related data that passes the SIP-server and even the media that passes a media gateway under the control of that operator or even the entire IP-traffic on a specific line as long as it is under the control of the Telco. Raindeer (talk) 13:21, 23 June 2009 (UTC)

Raindeer is correct, but it should be clarified. SIP traffic may be intercepted on the application level so long as the media and SIP traffic is proxied by a provider. Otherwise, the destination entity acts as the SIP server, preventing it being used as an interceptor. Traffic may be intercepted on the IP level through the ISP, or any hop between the two parties, but this information may be rendered useless easily be communicating over a secured socket connection. -Verdatum (talk) 15:46, 23 June 2009 (UTC)

Bad Grammar[edit]

Another solution is ICE. It combine STUN and TURN protocols. STUN is almost resources-less solutions, but it does not work in some cases. —Preceding unsigned comment added by 203.167.214.129 (talk) 04:05, 14 September 2009 (UTC)

The IETF Network Working Group published RFC 3261 - as of 2013 the latest version of the specification - in June 2002.[3] -- this sentence is a bit wonky. Should be reworded to -- As of 2013, the latest version of the specification is RFC 3261, published in June 2002.

Yes check.svg Done ~KvnG 23:34, 11 May 2014 (UTC)

Compatibilities?[edit]

It's not clear from anything in the article whether different SIP-driven VOIP networks routinely connect to each other. I have insufficient knowledge. Could anyone add this information? Centrepull (talk) 13:10, 20 December 2009 (UTC)

Technically SIP driven VOIP networks should interact. What happens to a caller is a question of the security policy of the providers and their roaming agreements. The latter are not described as part of the standard(s) nor the possible technical szenarios behind them. --Kgfleischmann (talk) 14:59, 20 December 2009 (UTC)

SIP Implementation by Broadcast Audio Codec Manufacturers[edit]

There is not much discussion on the page about how broadcast audio codec manufacturers have implemented SIP, according to EBU N/ACIP Tech 3326 specifications, in order to allow different brands to connect to each other. SIP is used to ensure that a common protocol is used by manufacturers so that interoperability is maximised. It also makes connections between IP audio codecs more simple when traversing firewalls and when Network Address Translation is required. You can read more about how these broadcast codecs work by clicking on the following link *Tieline Technology IP Audio Protocols for Broadcasting Audio over IP (EBU N/ACIP Tech 3326) and there is also a website for the Audio-via-IP Experts group that talks about interoperability of IP audio codecs using SIP. —Preceding unsigned comment added by Glenndavies (talkcontribs) 03:04, 8 February 2010 (UTC)

This has very little to do with SIP per se. SIP uses SDP to negotiate codecs and these are no different than any other codec. Why would the implementation of SIP by such vendors be any different? Nothing special in SIP is required to use whatever codec. Different brands to connect to each other, what are you asking? Kbrose (talk) 03:25, 8 February 2010 (UTC)
I have added a mention to the Applications section. --Kvng (talk) 15:17, 19 August 2011 (UTC)

SIP security[edit]

SIP security is a challenge for networking due to it's nature "Easy to understand". Application layer messages involve all below layers and therefore security from all levels become part of this top layer protocol. Research is continue in this field and there are some tools available such as PROTOS for fuzzing and verifying SIP implementations. Some application layer firewalls (SonicWALL) are also capable to protect SIP attacks and SIPT (Spam over Internet Telephony).Gaurav.raval (talk) 10:42, 31 May 2010 (UTC)

Merge SIP registrar into Session Initiation Protocol[edit]

SIP registrar is a very short article. It would better if it was a section directly on Session Initiation Protocol article. --I don't remember my username (talk) —Preceding undated comment added 12:44, 7 June 2010 (UTC).

A merge from SIP connection has also been proposed. I support both proposals. No need to wait for permission on these sorts of things. Be WP:BOLD. --Kvng (talk) 04:03, 27 June 2010 (UTC)

SIP registrar is using the sip protocol, but it comes a lot of information in that. It should not be merged. —Preceding unsigned comment added by Jiffingeorge (talkcontribs) 08:50, 28 June 2010 (UTC)

Leave them separate. Usually you only want some info about what a SIP registrar without having to read all the kruft in the main article. 71.131.2.48 (talk) —Preceding undated comment added 04:04, 11 October 2010 (UTC).

Merge we need not have articles for each topic about a single protocol, SIP Register as section in SIP will suffice----User talk:R.srinivaas 06:21, 12 February 2011 (UTC)
Merging it is better. Sae1962 (talk) 10:44, 15 February 2011 (UTC)
I've merged SIP registrar; It was straightforward. A SIP connection merge looks to be a bit more complicated. Some of the content might be better placed in VoIP. --Kvng (talk) 17:07, 19 August 2011 (UTC)

SIP vs. SS7[edit]

The article (as per July 8th 2010) saids that "SS7 is a centralized protocol, characterized by a complex central network architecture and dumb endpoints (traditional telephone handsets)" This statement is not accurate, as SS7 is in fact a data network protocol intended to transport different signalling protocols between nodes (not terminals) of public communication networks.

Consequently, different NNI (Node-to-Node) interfaces can be implemented over SS7 (wich is specified in the Q.7xx series of ITU-T recommendations), whilst UNI (User-to-Node) interfaces CAN'T be implemented over it.

It is however true that in traditional public communication services, each specific NNI usually has a corresponding UNI. As an example, the ISDN UNI (specified in Q.93x recommendations) corresponded to the ISUP (ISDN User Part) protocol for NNI (specified in Q.73x series of recommendations). The latter protocol is provided over SS7 whislt the former is not (it is actually provided over the Q.921/LAP-D access protocol). In these networks generally UNI protocols were asymmetrical (client/server based) whilst NNI protocols (i.e. those based on SS7) where symmetrical.

Furthermore, in traditional communication networks the level of sophistication of terminals is highly variable depending on which specific network are we considering (POTS - Plain Old Telephone System vs. ISDN) and, whithin each network, the specific type of service/terminal considered. As an example we can recall that some ISDN terminals implemented videoconferencing capabilities (including multivideoconferencing bridging), high quality voice communications (7kHz and even 16kHz wideband codecs) and multi-site distributed PABX capabilities (e.g. Centrex based). They also supported data communication services (X.25 and Frame Relay) with flexible on-demand usage of the available bandwithd, by gradually aggregating the 16kbps D-channel to the two 64/56kbps B-channels available in the BRI access interface. Most of these (UNI) capabilities had their corresponding NNI counterparts, which in turn could be implemented both in a distributed form along all the nodes of the network (following the traditional telephone approach) or on a more centralised way in specialised nodes of the network (IN - Intelligent Network) making use of generic transport capapibilities provided by the underlying network. The last approach, specified in the late 90's although not widely implemented, is conceptually closer to the telephone services presently implemented over SIP. —Preceding unsigned comment added by 193.146.123.226 (talk) 08:47, 8 July 2010 (UTC)

Merge SIP URI sips URI scheme into Session Initiation Protocol[edit]

From my standpoint the URI structure of SIP, while a low level element of the protocol, is not robust enough in it's own right to require an independent section, let alone a whole page. The current suggested merge location #NetworkElements also makes good sense when you consider the overall structure of the article. I approve this merge. Jeremiah.tidmore (talk) 16:45, 28 January 2012 (UTC)

Agree due to limited scope of sips URI scheme (corrected heading above) which will never make a substantial article Widefox (talk) 10:14, 8 April 2012 (UTC)

Yes check.svg Done --Kvng (talk) 18:41, 9 April 2012 (UTC)

Too technical[edit]

This article needs a laymen's introduction before all these specifics. — Preceding unsigned comment added by 75.64.191.59 (talk) 23:58, 12 February 2012 (UTC)

Agreed. A {{technical}} banner alerting readers and editors to this has been in place for a few months now. --Kvng (talk) 18:43, 9 April 2012 (UTC)

Advertising Link[edit]

The external link "Some examples of SIP Use Cases" looks like advertising to me, and not very informative about SIP. Cmcqueen1975 (talk) 01:41, 24 February 2012 (UTC)

Yes! + The link is about products and not about the protocol --Kgfleischmann (talk) 11:11, 24 February 2012 (UTC)

SIP Session Border Controller[edit]

SIP rfc 3261 doesn't talk about SBCs. Rather it's an engineered solution for NAT/Firewall traversal. I guess, it should be mentioned separately from other elements like proxy and registrar. Mvineetmenon (talk) 14:34, 19 September 2012 (UTC)

SIP address lives[edit]

K7L has brought SIP address back into existence by moving Sips URI scheme. I had previous merged SIP address into this article (see discussion above). There's a bit more to this new article so I'm not going to jump and merge it. I am interested to know what's the WP:COMMONNAME for a SIP address. Is it SIP address or SIP URI. I've heard both with the latter being more common but I work with geeky implementers not end-users. ~KvnG 15:31, 27 October 2013 (UTC)

I get 103000 ghits for "SIP address" and 170000 for "SIP URI" so likely both are valid. The previously-merged text was 1101 bytes (vs. 6019 bytes currently at SIP address) and was about just sips: (not sip: addressing in general) so isn't the same article. The question of how a SIP user on one provider directly contacts a SIP user somewhere else without gating the call to PSTN and back is itself a fairly broad topic and the subject of multiple articles. A published SIP address could make this process as 'free' as e-mail or (conversely) as spam-laden and broken as e-mail. K7L (talk) 15:43, 27 October 2013 (UTC)

Ode to SIP[edit]

In terms of telephony applications, SIP is not without limitations. The main criticisms of SIP involve limitations surrounding emergency calling and law enforcement interception activities. The peer to peer architecture of the SIP protocol uses IP endpoints that, by their nature, are unrestricted in terms of mobility. Unlike regular PSTN 911 calls, with SIP, there is no network layer location mechanism available to pinpoint the location of the user. It is also extremely difficult for law enforcement to monitor and intercept SIP based phone calls due to the same reason. Despite these limitations, SIP is growing in popularity due to its ease of deployment and management, low cost, and scalable capability.

In love, 178.197.236.111 (talk) 04:00, 14 January 2014 (UTC)