Subject: Re: [P2PSIP] A new proposal for SIP Usage for RELOAD

From: Tao Ma <[email-masked]>
Date: Thu, 23 Jul 2009 15:49:20 +0800

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?
    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?
    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"?
    I would appreciate for your reply:)
Tao Ma
July 23rd
Beijing University of Posts and Telecommunications, Mobile lIfe and New
mEdia Lab

---

From: Tao Ma <[email-masked]>
Date: Thu, 23 Jul 2009 17:19:48 +0800

Thanks,  please see inline
2009/7/23 <[email-masked]>

>
> Hi,
>
> Comments inline.
>
> Thanks.
>
> Gao
>
>
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : [email-masked]
> ===================================
>
>
>  *Tao Ma <[email-masked]>*
> 发件人:  [email-masked]
>
> 2009-07-23 15:49
>   收件人
> [email-masked], [email-masked]
>  抄送
> [email-masked]  主题
> Re: [P2PSIP] A new proposal for SIP Usage for RELOAD
>
>
>
>
> Hi,
> [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] "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] 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?

> mEdia Lab_______________________________________________
> P2PSIP mailing list
> [email-masked]
> 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.
>
>

---

From: [email-masked]
Date: Thu, 23 Jul 2009 17:38:47 +0800

> 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. 

[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; 

> 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.

> Beijing University of Posts and Telecommunications, Mobile lIfe and 
> New mEdia Lab_______________________________________________
> P2PSIP mailing list
> [email-masked]

> 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.