At Sun, 9 Nov 2008 21:07:44 -0500, Bruce Lowekamp wrote: > > On Sat, Nov 8, 2008 at 12:02 PM, Henning Schulzrinne > <[EMAIL PROTECTED]> wrote: > > > > On Nov 4, 2008, at 3:57 PM, Bruce Lowekamp wrote: > > > >> Reload supports large messages, but it is missing a number of > >> components required to make this work. In particular, there is no > >> end-to-end congestion control, and a large message could essentially > >> block a link between two peers long enough to force other messages > >> (and the large message itself) to time out. > > > > This assumes that there is only a single "link" between nodes. > > > >> > >> > >> Solving this properly is likely to be quite complicated. Since our > >> primary usage requires only the exchange of URIs and certificates, the > > > > This isn't quite true. Even for the SIP usage, we'll have to worry about > > voicemail messages, for example. > > The SIP usage does not contain the word "voicemail." While I would > love to see a draft proposing how to manage voicemail, there is not > one at present. There are certainly some deployments that would be > incomplete without a way of storing voicemail in the overlay, but > there are also lots that have other ways to handle voicemail. I don't > know if it's even true that a majority of deployments is likely to > need or want voicemail in the overlay.
This isn't an accident, either, I don't think. My memory of the early WG and pre-WG discussions was that voicemail was going to be out of scope. Indeed the charter seems pretty clear on this point: The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional SIP. Speaking only for myself, I've been deliberately avoiding thinking about the voice mail problem based on the above understanding. -Ekr _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
