Talk:Session Initiation Protocol: Difference between revisions

Content deleted Content added

Inline

Revision as of 15:41, 5 December 2006

Bandwidth

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. 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)[reply]

SIP and RTP

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.

SIP and H.323

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)[reply]

Opinionated introduction

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)[reply]

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[reply]

Protocol design

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)[reply]

Not a web directory

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)[reply]

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)[reply]

Little problem concerning Gizmo

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

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

"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)[reply]

I'm a bit confused about "SIP gleaning". Could you name a RFC which defines this? --Kgfleischmann 12:17, 3 October 2006 (UTC)[reply]

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)[reply]

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

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. 81.114.228.2 15:40, 5 December 2006 (UTC)The Supernatural Protocols Anaesthetist[reply]