Talk:Session Initiation Protocol

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

message: "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)
replies: text: I'm a bit confused about "SIP gleaning". Could you name a RFC which defines this? --Kgfleischmann 12:17, 3 October 2006 (UTC)

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

text: 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)
thread_title:  SIP gleaning: merge here 

message: 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)
thread_title:  SIP vs. SS7 

message: 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)
replies: text: I added mention of this. ~Kvng (talk) 03:36, 24 August 2021 (UTC)
thread_title:  SIP Session Border Controller