Talk:Session Initiation Protocol

Little problem concerning Gizmo

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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)

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)

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)

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)

SIP vs. SS7

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)

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

SIP Session Border Controller

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)

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