📄 draft-willis-p2psip-concepts-02(1012).txt
字号:
2) SIP INVITE/200 OK /----------------\ / \ --->PSTN +------+ N +------+ +---------+ / | | A | | | Gateway |-/ | UA |####T#####| UA |#####| Peer |######## | Peer | N | Peer | | G | # Client Protocol | E | A | F | +---------+ # GET/PUT | | T | | # | +------+ N +------+ # | # A # | NATNATNATNAT # | # # | \__/ NATNATNATNAT +-------+ v / \ # N | |=====/ UA \ +------+ A P2PSIP Overlay | Proxy | /Client\ | | T | Peer | |___C__| | UA | N Route Data | Q | | Peer | A +-------+ | D | T P2PSIP Peer Protocol # | | N # +------+ A # # T # # N +-------+ +-------+ # # A | | | | # #########T####| Proxy |########| Redir |####### | Peer | | Peer | | P | | R | +-------+ +-------+ Figure: P2PSIP Peer to Peer3.3.2. P2PSIP Client contacts P2PSIP Peer NOTE: In a design where unmodified SIP is used for the P2PSIP Client protocol, this case does not exist/is not needed. Sections Section 3.3.3 and Section 3.3.4, covering conventional SIP access are all that are required. The following diagram shows P2PSIP UA Client "C" placing a call to P2PSIP UA Peer "F". 1) "C" first sends a GET request using the P2P Client GET/PUT protocol to a Peer in the overlay, in this case "Q". 2) Some messages are exchanged among client "C" and the peers in the overlay to perform the lookup (flow not shown as this will depend on the protocol designed), and the address of "F" is passed back to "C" using the P2PSIP Client protocol. 3) "C" then establishes a session directly with "F" using a conventional SIP INVITE/200 OK mechanism.Willis, et al. Expires April 15, 2007 [Page 14] Internet-Draft P2PSIP Concepts and Terminology October 2006 3) SIP INVITE/200 OK /---------------------------------------------+ / | / --->PSTN | +------+ N +------+ +---------+ / | | | A | | | Gateway |-/ | | UA |####T#####| UA |#####| Peer |######## | | Peer | N | Peer | | G | # 1) Client Protocol | | E | A | F | +---------+ # GET | | | T | | # | | +------+ N +------+ # | | # A # | / NATNATNATNAT # | / # # | \__/ / NATNATNATNAT +-------+ v / \ / # N | |=====/ UA \ / +------+ A P2PSIP Overlay | Proxy | /Client\/ | | T | Peer | |___C__| | UA | N Route Data | Q | | Peer | A +-------+ | D | T P2PSIP Peer Protocol # | | N # +------+ A # # T # # N +-------+ +-------+ # # A | | | | # #########T####| Proxy |########| Redir |####### | Peer | | Peer | | P | | R | +-------+ +-------+ Figure: P2PSIP Client to Peer3.3.3. Conventional SIP Device using a Proxy Peer The following diagram shows a conventional SIP device, SIP UA "A", establishing a dialog with UA Peer "F". 1) "A" sends a conventional SIP INVITE to Proxy Peer "P". 2) Proxy Peer "P" uses the P2PSIP Overlay Protocol to locate the target (flow not shown as this will depend on the protocol designed), in this case UA Peer "F". 3) "P" forwards the SIP request to the destination and proxies the response back to "A".Willis, et al. Expires April 15, 2007 [Page 15] Internet-Draft P2PSIP Concepts and Terminology October 2006 --->PSTN +------+ N +------+ +---------+ / | | A | | | Gateway |-/ | UA |####T#####| UA |#####| Peer |######## | Peer | N | Peer | | G | # Client Protocol | E | A | F | +---------+ # GET/PUT | | T | | # | +------+ N +------+ # | # A | # | NATNATNATNAT | # | # | # | \__/ NATNATNATNAT | +-------+ v / \ # N | | |=====/ UA \ +------+ A P2PSIP Overlay | Proxy | /Client\ | | T | | Peer | |___C__| | UA | N | | Q | | Peer | A | +-------+ | D | T |3) SIP INVITE/200 OK # | | N | # +------+ A | # # T | # # N +-------+ +-------+ # # A | | | | # #########T####| Proxy |########| Redir |####### | Peer | | Peer | | P | | R | +-------+ +-------+ / / \__/ / 1) SIP INVITE/200 OK /\ / / \/ / UA \ /______\ SIP UA A Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer Proxy3.3.4. Conventional SIP Device Using a Redirect Peer The following diagram shows a second conventional SIP device, SIP UA "A" establishing a dialog with a P2PSIP Client UA "C". 1) "A" sends a conventional SIP INVITE to the Redirect Peer "R". 2) Redirect Peer "R" uses the P2PSIP Peer Protocol to locate the target (flow not shown as this will depend on the protocol designed), in this case P2PSIP Client UA "C". In contrast to the Proxy peer above, "R"Willis, et al. Expires April 15, 2007 [Page 16] Internet-Draft P2PSIP Concepts and Terminology October 2006 returns the result of the lookup to "A" as a 302 Moved message, with a contact of "C" (the conventional SIP 302 mechanism), rather than proxying the request for "A". 3) The conventional SIP UA "A" device can then establish the dialog directly with UA Client "C", even though "A" has no awareness of the P2PSIP Overlay, or of the P2PSIP Client Protocol. --->PSTN +------+ N +------+ +---------+ / | | A | | | Gateway |-/ | UA |####T#####| UA |#####| Peer |######## | Peer | N | Peer | | G | # Client Protocol | E | A | F | +---------+ # GET/PUT | | T | | # | +------+ N +------+ # | # A # | NATNATNATNAT # | # # | \__/ NATNATNATNAT +-------+ v / \ # N | |=====/ UA \ +------+ A P2PSIP Overlay | Proxy | /Client\ | | T | Peer | |___C__| | UA | N Route Data | Q | | | Peer | A +-------+ | | D | T P2PSIP Peer Protocol # | | | N # 3) SIP INVITE +------+ A # /200 OK # T # | # N +-------+ +-------+ # | # A | | | | # | #########T####| Proxy |########| Redir |####### | | Peer | | Peer | / | P | | R | / +-------+ +-------+ / \ / \ / 1) SIP INVITE \ \__/ / /302 Moved \ /\ / \ / \ / \/ UA \/ /______\ SIP UA A Figure: Redirect from P2PSIP OverlayWillis, et al. Expires April 15, 2007 [Page 17] Internet-Draft P2PSIP Concepts and Terminology October 20063.4. Conceptual Outline of Operations3.4.1. Enrolling and Inserting an P2PSIP Peer Peers are the full-function "routing and storage" nodes of a P2PSIP Overlay. When a new peer is first created, it must enroll in the P2PSIP Overlay. We currently have no defined mechanism for this (should this group define one?), but we know that once the process is complete, the new peer will have at least a P2PSIP Peer-ID and optionally a set of credentials. After enrollment, each time the peer connects to the overlay, it must insert itself. We don't have a defined protocol mechanism for this, and assume we need one. Presumably the inserting peer connects to one or more existing peers (possibly with the aid of a bootstrap server) presents its credentials, and after exchanging some messages with other P2PSIP Peers, ends up connected to the overlay. It will then have some knowledge of neighbors (successor, precursor, finger tables, or whatever the distribution mechanism defines) and is able to store data on behalf of and route requests to other nodes in the P2PSIP overlay.3.4.2. More on The Difference Between a Peer, Client, and User Agent P2PSIP Peers directly interact with and contain the routing and storage fabric of the overlay. P2PSIP Clients simply use the routing and storage facilities provided by the peers to get/put information. The peers speak the P2PSIP Peer Protocol, which presumably has a full range of expressivity for the routing and storage facilities of the overlay. Clients speak the P2PSIP Client protocol, which is presumably a subset of the peer protocol, and is limited to storage insertion (put), storage retrieval (get), and message routing (send). Some designs do not require a separate client protocol. Some peers and some clients may be coupled to SIP user agents, making them P2PSIP User Agents capable of both sending and receiving conventional SIP messages (as per a SIP UA) using conventional SIP resolution procedures and of using the resolution facilities provided by the overlay. The mix and configuration of peers, clients, and P2PSIP UAs is expected to vary depending on the deployment scenario. For example, an ad-hoc scenario might deploy nothing but P2PSIP Peers, each of which is coupled to a P2PSIP User Agent, using a broadcast or multicast bootstrap mechanism. Another common scenario, the "self organizing proxy farm", might consist of P2PSIP Peers, each of which is coupled to a SIP proxy/registrar function.Willis, et al. Expires April 15, 2007 [Page 18] Internet-Draft P2PSIP Concepts and Terminology October 2006 Some of the systems proposed that use SIP for the P2PSIP Client protocol essentially remove that protocol from their design. Standard SIP messages are sent to a proxy or redirect server which speaks the P2PSIP server protocol, eliminating the need for another protocol.3.4.3. Enrolling a User and Inserting a P2PSIP User Agent Clients and Peers are devices, the "end points" or "user agents" of a P2PSIP Overlay. Users are the named entities that participate in a P2PSIP overlay using a client. To get started, users must be enrolled in the overlay. We do not have a process or protocol for this, nor are we certain we need a standardized mechanism. We presume that after enrollment, the user has a distinguished name within the overlay (example: sip:bob@example.com) and a set of credentials useful for authenticating its usage of the distinguished name. One possible mechanism for these credentials would be an x.509 certificate. It might also be possible to use a PGP key, a password, or some other mechanism. Presumably following enrollment, the user is also equipped with the information needed to connect to the overlay, such as the address of a bootstrap server. Whether this startup information is delivered as a part of enrollment of through some separate configuration process remains an open question, and it is not clear it is within the scope of the proposed WG. Once a user is enrolled, the user may exercise a P2PSIP User Agent to insert into the P2PSIP Overlay. We currently have no protocol mechanism for this, and need to define one. The P2PSIP UA exercises the associated P2PSIP Peer or P2PSIP Client to execute the "registration" function and insert a route for the user into the P2PSIP overlay. This function is described as a "PUT" request, and results in the storage of an authenticated route-set for the user in the P2PSIP overlay, such that the terminus of the route is the URI of the user at the P2PSIP UA. This is analogous to "registration" in a classic SIP environment, and one mechanism proposed is in fact to use the SIP REGISTER method. Presumably, the P2PSIP UA connects to a peer or client and uses the user's credentials to authenticate a route-set (Contact: plus Path:) to itself, and the peer or client stores the route-set into the overlay, using a key derived from the user's identity.3.4.4. Bootstrapping If a client or peer is just starting up and has no knowledge of how to reach the other nodes of the overlay, it may exercise a bootstrap server to find one. Presumably it discovers the bootstrap server byWillis, et al. Expires April 15, 2007 [Page 19] Internet-Draft P2PSIP Concepts and Terminology October 2006 some mechanism such as a DNS lookup, multicast, broadcast or configuration, then queries the bootstrap server and receives an address for a peer or set of peers that can be used to reach the overlay. Ideally, these target peers will be selected from a relatively large pool of peers that are currently online and reachable. After discovering the address of a peer, the behavior of the starting node will vary depending on whether it is intending to be a peer or a client. If it is intending to be a peer, it goes into the P2PSIP Peer Insertion process, at the conclusion of which it is actively participating in the target overlay as a peer and is capable of routing requests and storing records on behalf of the P2PSIP overlay. If it is intending to be a client, it does not bother with insertion, but merely contacts the discovered peer in order to use the overlay. In the typical case, the peer or client coming up is also a P2PSIP User Agent with one or more associated P2PSIP Resource (User) Identifiers. The next step then is to insert a P2PSIP Resource Record (a Contact:) into the P2PSIP Overlay. We may wish to have a mechanism in place where a particular bootstrap server can send a redirect response, offloading a heavily loaded server.4. Questions⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -