> Hi, > I have read the draft, which points out the drawbacks of draft- > ietf-p2psip-sip-01. But I have some questions and confusion as follows: > 1 You mentioned the exclusivity to overlay clients, but I don't > think the draft-ietf-p2psip-sip-01 has explicitly excluded the > client usage, whereas it doesn't mention the client support > explicitly. Could you show me the apparent conflicts with the client > usage in that draft?
> [Gao] draft-ietf-p2psip-sip-01 says that sip users are peers, not > *Node*. So, it can be treated as *exclusivity*. Do you think so. > Further, clients' routing and peers' routing is not the same way. > And I am arranging a separate text to talk about the reachability of > clients routed by NodeID. > I come to understand that the exclusivity mainly comes from the > differences between peer routing and client routing . I think the > "seperate text" is badly needed to further explore the drawback of > SIP usage without client routing. Here can I just conclude that the > draft-ietf-p2psip-sip-01 should add client routing? > [Gao] As you can see, draft-ietf-p2psip-sip-01 can modify the words from *peers* to *node*(including clients). But the problem behind it is the routing problem. And if I will arrange it as soon as possible. > > 2 I am a little confused about the description " The main > difference is that sip user registers his address while not NodeID, > under his AOR"in Section 3 "the new solution". Actually, client may > have NodeID in RELOAD protocol. In the new solution why does the sip > user register with address not NodeID? What does "address" here mean? > > [Gao] "Address" is the same as Contract header in normal SIP > register message. Why using *Contract address*, while not NodeID is > a nice question. > The reason is that clients' reachability can not be guaranteed by > any overlay when routing by NodeID for clients. > It's a nice answer, thanks:) > [Gao] It seems that you got the point here. > 3 In Section 3.2.1, I am confused about the "half spending". You > use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach > mechanisms, how can you say your mechanism is "half spending"? > [Gao] ICE offer/answer procedure is bypass of the overlay, and it is > sent directly between caller and callee. But the AppAttach has not > be routed peer by peer. > > My way: Fetch; > draft-ietf-p2psip-sip-01's way: Fetch and AppAttach. > So, it is half spending. > In my opinion, the overlay routing is based on NodeID in RELOAD > because RELOAD overlay is responsible for routing and storage. But > in your way, if the contact address can be retrieved, then the > routing can bypass the overlay. RELOAD overlay only stores the > mapping relationship and no more routes the application messages to > the destination. I think it's two kind of philosophy, do you think so? > [Gao] I have the same philosophy, but more terse. While my way has used the overlay for storage/retrieve data, it is usage of overlay. > > I would appreciate for your reply:) > Tao Ma > July 23rd > Beijing University of Posts and Telecommunications, Mobile lIfe and > New mEdia Lab_______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
