Talk:Session Initiation Protocol

This is the talk page for discussing improvements to the Session Initiation Protocol article. This is not a forum for general discussion of the subject of the article.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Article policies Neutral point of view No original research Verifiability

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1Auto-archiving period: 12 months

This article is rated B-class on Wikipedia's content assessment scale. It is of interest to multiple WikiProjects.

Telecommunications Mid‑importance 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.TelecommunicationsWikipedia:WikiProject TelecommunicationsTemplate:WikiProject TelecommunicationsTelecommunications Mid This article has been rated as Mid-importance on the project's importance scale. Computing: Networking Mid‑importance 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by Networking task force (assessed as Mid-importance). Technology This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of 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.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology

The content of SIP registrar was merged into Session Initiation Protocol on 2011-08-19. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. For the discussion at that location, see its talk page.

The content of sips URI scheme was merged into Session Initiation Protocol on 2012-04-09. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. For the discussion at that location, see its talk page.

The content of SIP connection was merged into Session Initiation Protocol on 2012-10-11. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. For the discussion at that location, see its talk page.

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

We do have Session_Initiation_Protocol#Encryption but a more comprehensive discussion of security issues would be welcome. ~Kvng (talk) 03:36, 24 August 2021 (UTC)[reply]

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

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

SIP gleaning now redirects here but SIP gleaning is not mentioned in this article which creates an WP:ASTONISHING situation for readers. The former content of SIP gleaning was

The process of identifying the IP end point of a SIP based message. SIP gleaning is necessary for proper routing of SIP traffic to end points with private addresses. SIP gleaning is typically associated with maintaining persistence in load balanced SIP environments.

Perhaps somone will take it upon themselves to incorporate this information. ~Kvng (talk) 03:36, 24 August 2021 (UTC)[reply]

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

Mazinalzypiry Mazinalzybiry (talk) 17:14, 14 December 2018 (UTC)[reply]

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

I added mention of this. ~Kvng (talk) 03:36, 24 August 2021 (UTC)[reply]