Hi,
I think it is significative to talk the topic before the the upload
reopenning date.
The accessory is the draft.
Feel free for discussion.
Thanks.
Gao
p2psip Y. Gao
Internet-Draft Y. Meng
Intended status: Standards Track ZTE
Expires: January 22, 2010 July 21, 2009
A New SIP Usage for RELOAD
draft-gaoyang-p2psip-new-sip-usage-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Gao & Meng Expires January 22, 2010 [Page 1]
Internet-Draft A New SIP Usage for RELOAD July 2009
Abstract
This document points out the main drawbacks of the solution in
"draft-ietf-p2psip-sip-01". And solve such problems by introducing a
new way.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Main drawbacks of the current solution . . . . . . . . . . . . 4
2.1. Hidden trouble in inter-domain interworking . . . . . . . . 4
2.2. Hidden trouble in sip users' mobility . . . . . . . . . . . 4
2.2.1. Compelling support for peers' mobility . . . . . . . . 4
2.2.2. Churn of the overlay . . . . . . . . . . . . . . . . . 4
2.3. Exclusivity towards overlay clients in sip usage . . . . . 4
3. The new solution . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Solution introduction . . . . . . . . . . . . . . . . . . . 5
3.2. More merits . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Half spending . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Supporting clients' mobility inherently . . . . . . . . 6
4. Normative references . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Gao & Meng Expires January 22, 2010 [Page 2]
Internet-Draft A New SIP Usage for RELOAD July 2009
1. Introduction
As described in "draft-ietf-p2psip-sip-01", RELOAD's only role in sip
usage is to set up the direct SIP connection between caller and
callee. So, the sip users are more like clients than peers here.
But "draft-ietf-p2psip-sip-01" restricts that caller and callee are
peers of the overlay.
Making bad thing worse, callee MUST be peers of the overlay while
using the solution in "draft-ietf-p2psip-sip-01". The reason is that
only peers can be reachable by routing table of the overlay.
Gao & Meng Expires January 22, 2010 [Page 3]
Internet-Draft A New SIP Usage for RELOAD July 2009
2. Main drawbacks of the current solution
2.1. Hidden trouble in inter-domain interworking
Considering inter-domain interworking, caller can be user of other
domain. If we use the solution in "draft-ietf-p2psip-sip-01", there
should be a node in the other domain as peer of callee's overlay.
That is not acceptable for overlay networking operating, as storing
data in other domain's node can be nightmare.
If we make sip users outside of the overlay just clients, there would
not be such problem. In fact, making caller just client of the
overlay can get rid of this problem. So, "draft-ietf-p2psip-sip-01"
can abolish the restriction of caller as peer.
What need to be mentioned is that sip users inside the overlay can
register itself from peers of the overlay or from clients.
2.2. Hidden trouble in sip users' mobility
2.2.1. Compelling support for peers' mobility
As sip users are peers, so the overlay compells the support of peers'
mobility. If we make sip user just client of the overlay, there
would not be such problem. It means that we can construct an overlay
supporting clients' mobility without needing peers' mobility.
2.2.2. Churn of the overlay
Considering sip users' mobility in wireless access network
environment, there would be more probability for peers' joining,
leaving of the overlay which has impact on the churn of the overlay.
Further, peers can be more easily to lose its connection before
sending Leave message in such wireless environment. And this will
make the data stored in the peers unreachable.
If we make mobile sip user just client of the overlay, there would
not be such problem.
2.3. Exclusivity towards overlay clients in sip usage
Exclusivity towards overlay clients in sip usage would have
restriction on operating way for overlay network operators.
Gao & Meng Expires January 22, 2010 [Page 4]
Internet-Draft A New SIP Usage for RELOAD July 2009
3. The new solution
The main difference is that sip user registers his address while not
NodeID, under his AOR.
3.1. Solution introduction
The process of a sip call:
1. Callee stores a mapping from his URI to his Node-ID in the
overlay. And the NodeID of the peer choosed to store the mapping has
hash relationship with callee's URI.
2. Caller looks up callee's URI in the overlay and retrieves
callee's address.
3. Caller uses ICE's offer/answer to exchange caller's and callee's
candidate addresses.
The process of a sip call
Caller Overlay Callee
-------------------------------------------------
<------------------- Store
Store ------------------->
Fetch ---------------->
<---------------- Fetch
ICE Offer -------------------------------------->
<------------------------------------- ICE Answer
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
Figure 1
3.2. More merits
3.2.1. Half spending
After fetching the callee's address, the caller can using ICE offer/
answer procedure directly, without AppAttach procedure in the
overlay.
Gao & Meng Expires January 22, 2010 [Page 5]
Internet-Draft A New SIP Usage for RELOAD July 2009
3.2.2. Supporting clients' mobility inherently
When callee changes its address, it can send a new registering
message to overlay.
Gao & Meng Expires January 22, 2010 [Page 6]
Internet-Draft A New SIP Usage for RELOAD July 2009
4. Normative references
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-03 (work in
progress), July 2009.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-01 (work in progress), March 2009.
Gao & Meng Expires January 22, 2010 [Page 7]
Internet-Draft A New SIP Usage for RELOAD July 2009
Authors' Addresses
Gao yang
ZTE
CHINA
Email: [email protected]
Meng Yu
ZTE
CHINA
Email: [email protected]
Gao & Meng Expires January 22, 2010 [Page 8]
===================================
Zip : 210012
Tel : 87211
Tel2 :(+86)-025-52877211
e_mail : [email protected]
===================================
===================================
Zip : 210012
Tel : 87211
Tel2 :(+86)-025-52877211
e_mail : [email protected]
===================================
--------------------------------------------------------
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
