Thanks, please see inline 2009/7/23 <[email protected]> > > Hi, > > Comments inline. > > Thanks. > > Gao > > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : [email protected] > =================================== > > > *Tao Ma <[email protected]>* > 发件人: [email protected] > > 2009-07-23 15:49 > 收件人 > [email protected], [email protected] > 抄送 > [email protected] 主题 > Re: [P2PSIP] A new proposal for SIP Usage for RELOAD > > > > > 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?
> > > 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:) > > 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? > > > > 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. > >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
