Subject: [p2p-sip] A New Internet-draft is available

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Wed, 23 Aug 2006 10:01:08 +0800

Hello, all

We have submitted a new Internet-draft entitled "A Hierarchical P2P-SIP
Architecture". This draft focuses on the SIP-over-P2P architecture and
interworking of heterogeneous overlay networks. 

This document is available in the Internet-drafts archive now:

http://www3.ietf.org/internet-drafts/draft-shi-p2psip-hier-arch-00.txt

Comments are welcomed!

Thanks

Juwei

Juwei Shi 

Wireless Technology Innovation Institute (WTI)

Beijing Univ. of Posts and Telecommunications (BUPT)

Tel: +86-10-62283600 ext. 312

Email: jwshi at bupt.edu.cn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060822/b5eec6a6/attachment.html

---

From: kyara543 at yahoo.com (K.Yamamoto)
Date: Tue, 22 Aug 2006 21:21:29 -0700 (PDT)

THE DOCUMENT IS GORGEOUS BUT NEED RENAME AS "A MESHY ARCHITECTURE AMONG MULTIPLE P2P-SIP NETWORKS".

FOMULA "Node-ID=Hash(Node-IP)" HAS PROBLEM WITH MULTIPLE NODES BEHIND A NAT.

THERE IS LITTLE ABOUT P2P OR SIP, FOR ONE SINGLE OVERLAY.

THANK YOU.

--KY
PLEASE QUALITY CONTROL LIKE BUILDING A LEXUS.

Juwei Shi <jwshi at bupt.edu.cn> wrote:           st1\:*{behavior:url(#default#ieooui) }           Hello, all

We have submitted a new Internet-draft entitled &#8220;A Hierarchical P2P-SIP Architecture&#8221;. This draft focuses on the SIP-over-P2P architecture and interworking of heterogeneous overlay networks. 

  Comments are welcomed!
   
  Thanks
  Juwei
   
  Juwei Shi 

  _______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060823/1ec5c580/attachment.html

---

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Wed, 23 Aug 2006 12:58:21 +0800

The NAT issues will be discussed in our future drafts. 

This draft focuses on the interworking among heterogenous overlays and the SIP-over-P2P architecture in one single overlay is proposed by E. Shim etc. 

http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt

Thanks

Juwei

  _____  

???: K.Yamamoto [mailto:kyara543 at yahoo.com] 
????: 2006?8?23? 12:21
???: Juwei Shi; p2p-sip at cs.columbia.edu
??: Re: [p2p-sip] A New Internet-draft is available

THANK YOU.

--KY

Juwei Shi <jwshi at bupt.edu.cn> wrote:

Hello, all

We have submitted a new Internet-draft entitled ?A Hierarchical P2P-SIP Architecture?. This draft focuses on the SIP-over-P2P architecture and interworking of heterogeneous overlay networks. 

Comments are welcomed!

Thanks

Juwei

Juwei Shi 

  

  _____  

Yahoo! Messenger with Voice. Make <http://us.rd.yahoo.com/mail_us/taglines/postman1/*http:/us.rd.yahoo.com/evt=39663/*http:/voice.yahoo.com>  PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060823/9387d3c2/attachment-0001.html

---

From: kyara543 at yahoo.com (K.Yamamoto)
Date: Wed, 23 Aug 2006 11:15:44 -0700 (PDT)

WHEN NUMEROUS MULTI-OVERLAID NODES ARE INTERCONNECTED, "the interworking among heterogenous overlays" IS GENERALLY MESSY NOT HIERACHICAL. 

THANK YOU.
 
--KY
PLEASE QUALITY CONTROL LIKE BUILDING A LEXUS.
Juwei Shi <jwshi at bupt.edu.cn> wrote:        v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}         st1\:*{behavior:url(#default#ieooui) }                      

  Thanks
  Juwei

  
  ?????????: K.Yamamoto [mailto:kyara543 at yahoo.com] 
 ????????????: 2006???8???23??? 12:21
 ?????????: Juwei Shi; p2p-sip at cs.columbia.edu
 ??????: Re: [p2p-sip] A New Internet-draft is available

 
 
 THANK YOU.
 
 --KY

We have submitted a new Internet-draft entitled ???A Hierarchical P2P-SIP Architecture???. This draft focuses on the SIP-over-P2P architecture and interworking of heterogeneous overlay networks. 

  Comments are welcomed!
   
  Thanks
  Juwei
   
  Juwei Shi 

    
  
  Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2??/min or less.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060823/817cf63c/attachment-0001.html

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Thu, 24 Aug 2006 09:33:15 +0800

Interworking among heterogeneous hierarchical is more efficient than do it meshy, you can not expect a flat huge mesh over whole world can work reliably, the reason why mesh is used is the absence of a acceptable standard.

Thanks.

Seaward 

  _____  

From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of K.Yamamoto
Sent: Thursday, August 24, 2006 2:16 AM
To: Juwei Shi; p2p-sip at cs.columbia.edu
Subject: Re: ????: [p2p-sip] A New Internet-draft is available

THANK YOU.
 
--KY

Thanks
Juwei

  _____  

 
 
 THANK YOU.
 
 --KY

We have

 submitted a new Internet-draft entitled ???A Hierarchical P2P-SIP Architecture???. This draft focuses on the SIP-over-P2P architecture and interworking of heterogeneous overlay networks. 

Comments are welcomed!

Thanks
Juwei

Juwei Shi 

  _____  

Yahoo! Messenger with Voice. Make  <http://us.rd.yahoo.com/mail_us/taglines/postman1/*http:/us.rd.yahoo.com/evt=39663/*http:/voice.yahoo.com> PC-to-Phone Calls to the US (and 30+ countries) for 2??/min or less.

  _____  

Yahoo! Messenger with Voice. Make  <http://us.rd.yahoo.com/mail_us/taglines/postman1/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com> PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060823/bbbd6c3e/attachment.html

---

From: bessler at FTW.at (Sandford Bessler)
Date: Fri, 25 Aug 2006 15:02:41 +0200

Hi,
Reading the call example in the draft, the user location functionality 
we know from SIP is not quite clear:
Basically I would like to call Alice using her fixed SIP-URI without 
having to know that she is at pku.can

In case alice at pku.can is the SIP address everybody has in the address 
book, we should maybe explain how her current address is obtained when 
she registers from another local overlay. e.g in another country she is 
visiting.

Best Regards
Sandford

Juwei Shi schrieb:
> ------------------------------------------------------------------------
>

-- 
Dr. Sandford Bessler
Key Researcher,
ftw. - Telecommunications Research Centre Vienna - www.ftw.at
bessler at ftw.at, Tel: +431 5052830-43

---

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Sat, 26 Aug 2006 00:24:23 +0800

Hi, Sandford

The sip:alice at pku.can is the global uniform identifier for Alice which
everybody records it in the address book, and we assume that pku.can is the
home domain of Alice at Peking Univ. in the CAN overlay (The IP of her home
domain host is 59.64.154.11). When Alice visits another country (The IP of
her visiting domain host is 211.154.71.23), she can also register the
sip:alice at pku.can SIP URI to the CAN overlay. Then the INVITE message to
Alice will be routed to both the hosts in his home domain and visiting
domain.

We have implemented this application layer mobility based on the multicast
function provided by Internet Indirection Infrastructure (I3). When Alice is
in her home domain, she will register sip:alice at pku.can to the CAN overlay
(indeed we use Chord overlay in I3, here use CAN for instance) via Reg_URI()
at 59.64.154.11. When Alice move to 211.154.71.23 in another domain, she
will re-register sip:alice at pku.can to the CAN overlay via Reg_URI() at
211.154.71.23. Then the INVITE message to Alice will be routed to both
59.64.154.11 and 211.154.71.22. When Alice leaves the visiting domain and
comes back to her home domain, the URI registration from 211.154.71.22 will
be removed. Then the INVITE message will be only routed to 59.64.154.11. 

Thanks
Juwei

_________________________________________________________

Hi,

Best Regards
Sandford

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 25 Aug 2006 15:02:39 -0700

This note is an excellent reminder on the discussions about using the
right hand side of the user at domain.

Here the TLD is an extension showing the type of DHT.

Is this the optimal naming schema?

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Juwei Shi
Sent: Friday, August 25, 2006 11:24 AM
To: 'Sandford Bessler'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] A New Internet-draft is available

Hi, Sandford

The sip:alice at pku.can is the global uniform identifier for Alice which
everybody records it in the address book, and we assume that pku.can is
the
home domain of Alice at Peking Univ. in the CAN overlay (The IP of her
home
domain host is 59.64.154.11). When Alice visits another country (The IP
of
her visiting domain host is 211.154.71.23), she can also register the
sip:alice at pku.can SIP URI to the CAN overlay. Then the INVITE message to
Alice will be routed to both the hosts in his home domain and visiting
domain.

We have implemented this application layer mobility based on the
multicast
function provided by Internet Indirection Infrastructure (I3). When
Alice is
in her home domain, she will register sip:alice at pku.can to the CAN
overlay
(indeed we use Chord overlay in I3, here use CAN for instance) via
Reg_URI()
at 59.64.154.11. When Alice move to 211.154.71.23 in another domain, she
will re-register sip:alice at pku.can to the CAN overlay via Reg_URI() at
211.154.71.23. Then the INVITE message to Alice will be routed to both
59.64.154.11 and 211.154.71.22. When Alice leaves the visiting domain
and
comes back to her home domain, the URI registration from 211.154.71.22
will
be removed. Then the INVITE message will be only routed to 59.64.154.11.

Thanks
Juwei

Hi,

Best Regards
Sandford

---

From: bessler at ftw.at (Sandford bessler)
Date: Sun, 27 Aug 2006 21:29:06 +0200

Thanks Juwei for the detailed answer.

I have a few other questions related to the draft:

1) In the example of  section 7, Bob's UA needs basically the address of 
Alice's UA in order to set up the INVITE message. Is it not more elegant 
to get
this address via the overlay infrastructure and then send the INVITE 
directly to Alice ? Why do the P1 nad P2 proxies have to understand SIP 
(messages F3, F7, etc.) ?

2) Looking at figure 1, we see that gateway nodes are both in the global 
and one or more local overlays.
Another more traditional design possibility would be to connect local 
overlay gateway nodes with global nodes  via a link and a simple 
protocol. This would allow to
better secure domain nodes, implement access and storage policies, 
require only one DHT technology per domain, etc.  The drawback is an 
additional hop introduced.
What do you think ?

3) How is performed the addressing in the hash space ?  There are again 
two possibilities IMHO:  in the first one each local domain has the 
whole 160 bit hash space at its disposal. The routing is done with
the additional identified overlay-ID. The advantage is that in all 
overlays a user for example would be stored under the same key.
The other possibility is to use the overlay-ID as prefix  and consuming 
a part of the  160 bit hash  space.  Which one did you consider ?

Thanks,
Sandford

---

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Mon, 28 Aug 2006 14:10:29 +0800

Hi, Sandford

There're the answers for you.

1)
The reason why F3 and F7 exist is that we intend to make the session initial course more controllable. Traditionally the proxy will respond a 100-Try message to the UA when it forwards the INIVTE message to other proxies. Here we also expect that the P2P Proxy could respond the mid-status during the inter-domain session initial process but not only roughly forward the message to other overlays. If we use overlays to locate the peer?s IP address and send the INVITE message to it directly, we will not know what happens during the inter-domain peer lookup process. In sum, we intend to inherit the controllable feature of SIP when we replace its peer locating service by P2P overlays and this hierarchical architecture may combines the advantages of both SIP-over-P2P and P2P-over-SIP.

2)
I agree that this is a simple and practical design. But we think that the deployment and maintenance cost will be increased since we need to deploy and maintain additional global nodes. And what kind of nodes do you think should become the global nodes?

3)
Both of the two naming schemes are under consideration now and we are also exploring some novel naming schemes to make the P2P-SIP overlay be aware of the underlining physic position. You may refer to the ID-stack design of Internet Indirection Infrastructure (i3) first and we can discuss this issue deeply in the future.

Thanks 
Juwei
_______________________________________________________________

Thanks,
Sandford