Building the network
EarthLink SIPshare peers builds its network by sending to
each peer in its peers file a stateful SIP Subscribe message.
Here, the Peer A at 209.179.2.62 is "subscribing" to the peer
list of Peer B at 209.179.2.61:
SUBSCRIBE sip:peer-list@209.179.2.61;transport=udp SIP/2.0
Call-ID: 5560a044871b02ba7074e4816857f27d@209.179.2.62
CSeq: 1 SUBSCRIBE
From: "fluxMark" <sip:msp@209.179.2.62>;tag=1308
To: "Peer List" <sip:peer-list@209.179.2.61>
Via: SIP/2.0/UDP 209.179.2.62:5060;branch=z9hG4bKed6ffbb76ca2ed9b3aa7d938cb05ee19
Max-Forwards: 70
Contact: "fluxMark" <sip:msp@209.179.2.62:5060;transport=udp>
Event: x-earthlink-sip-fpx
Accept: application/x-earthlink-peerlist-fpx
Content-Length: 0
to which Peer B responds
SIP/2.0 200 OK
Call-ID: 5560a044871b02ba7074e4816857f27d@209.179.2.62
CSeq: 1 SUBSCRIBE
From: "fluxMark" <sip:msp@209.179.2.62>;tag=1308
To: "Peer List" <sip:peer-list@209.179.2.61>;tag=9791
Via: SIP/2.0/UDP 209.179.2.62:5060;branch=z9hG4bKed6ffbb76ca2ed9b3aa7d938cb05ee19
Max-Forwards: 70
Contact: "fargesiaMark" <sip:102@209.179.2.61:5060;transport=udp>
Expires: 86400
Content-Length: 0
thus creating a dialog for subsequent Notify messages.
When Peer B learns of peers not already part of its network,
it sends an in-dialog Notify to each Peer A that has subscribed
to its peer list
NOTIFY sip:msp@209.179.2.62:5060;transport=udp SIP/2.0
Call-ID: 5560a044871b02ba7074e4816857f27d@209.179.2.62
CSeq: 1 NOTIFY
To: "fluxMark" <sip:msp@209.179.2.62>;tag=1308
From: "Peer List" <sip:peer-list@209.179.2.61>;tag=9791
Max-Forwards: 70
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=z9hG4bKe20d35dcc81aef8501106f28a47d9036
Contact: "fargesiaMark" <sip:102@209.179.2.61:5060;transport=udp>
Event: x-earthlink-sip-fpx
Subscription-State: active;expires=86400
Content-Type: application/x-earthlink-peerlist-fpx
Content-Length: 96
<?xml version="1.0" encoding="UTF-8"?>
<peerlist>
<peer>209.179.2.62</peer>
</peerlist>
followed by 200 OK from Peer A
SIP/2.0 200 OK
Call-ID: 5560a044871b02ba7074e4816857f27d@209.179.2.62
CSeq: 1 NOTIFY
To: "fluxMark" <sip:msp@209.179.2.62>;tag=1308
From: "Peer List" <sip:peer-list@209.179.2.61>;tag=9791
Max-Forwards: 70
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=z9hG4bKe20d35dcc81aef8501106f28a47d9036
Contact: "fluxMark" <sip:msp@209.179.2.62:5060;transport=udp>
Content-Length: 0
In this case, Peer B is informing Peer A that B now knows
about A. This is not particularly useful to Peer A, but when
B's network grows, A will learn from B the addresses of other
hosts not A.
Distributed content search
When Peer U wishes to locate content on the network, it sends
a search message to all the Peers V to whom it has subscribed for
peer lists. This choice of to which peers to send a content
search message is somewhat arbitrary.
We could have chosen to send to all Peers W of which we are
simply aware, whether we are subscribed to their respective
peer lists or not, and which is a superset of all Peers V.
We chose the set V for simplicity.
That said, Peer U sends a stateless Subscribe to Peer V, to
whom it happens to be subscribed for peer lists:
SUBSCRIBE sip:search@209.179.2.62;transport=udp SIP/2.0
Call-ID: d33a2b31a59ea843a33a37e20c56aade@209.179.2.61
CSeq: 1 SUBSCRIBE
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=5256
To: "Search" <sip:search@209.179.2.62>
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=30392e3137392e322e36313a3530363
Max-Forwards: 70
Contact: "fargesiaMark" <sip:102@209.179.2.61:5060;transport=udp>
Event: x-earthlink-sip-fpx
Accept: application/x-earthlink-cachehits-fpx
Content-Type: application/x-earthlink-searchfilter-fpx
Content-Length: 88
<?xml version="1.0" encoding="UTF-8"?>
<search>
<regex>mount<regex>
<search>
Note that the Subscribe body contains a filter document
specifying in what content Peer U is interested.
Peer V responds:
SIP/2.0 200 OK
Call-ID: d33a2b31a59ea843a33a37e20c56aade@209.179.2.61
CSeq: 1 SUBSCRIBE
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=5256
To: "Search" <sip:search@209.179.2.62>;tag=6132
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=30392e3137392e322e36313a3530363
Max-Forwards: 70
Contact: "fluxMark" <sip:msp@209.179.2.62:5060;transport=udp>
Expires: 0
Content-Length: 0
NOTIFY sip:102@209.179.2.61:5060;transport=udp SIP/2.0
Call-ID: 03fc7456478dfef5548c5c47af4b2cae@209.179.2.62
CSeq: 1 NOTIFY
From: "fluxMark" <sip:msp@209.179.2.62>;tag=6243
To: <sip:102@209.179.2.61:5060;transport=udp>
Via: SIP/2.0/UDP 209.179.2.62:5060;branch=30392e3137392e322e36323a3530363
Max-Forwards: 70
Contact: "fluxMark" <sip:msp@209.179.2.62:5060;transport=udp>
Event: x-earthlink-sip-fpx
Subscription-State: terminated
Content-Type: application/x-earthlink-cachehits-fpx
Content-Length: 216
<?xml version="1.0" encoding="UTF-8"?>
<sharing>
<file>
<name>mountains.jpg</name>
<size>3342000</size>
<digest>287af1e2a0180a4df0edd01ee9b38130</digest>
<file>
<sharing>
where Peer V sends a stateless Notify containing content hit
information to Peer U's Contact header field. Note that with
the Notify message sent, the "subscription" for this content
has expired and is terminated. If Peer U wants to be notified
of new content on Peer W that matches this same regex,
Peer V must perform another search to pick up information
on this new content. Peer W will not, in other words,
notify Peer U if matching content develops on W after the
initial search by U.
Peer U sends its 200 OK in response to Peer V's Notify:
SIP/2.0 200 OK
Call-ID: 03fc7456478dfef5548c5c47af4b2cae@209.179.2.62
CSeq: 1 NOTIFY
From: "fluxMark" <sip:msp@209.179.2.62>;tag=6243
To: <sip:102@209.179.2.61:5060;transport=udp>;tag=789
Via: SIP/2.0/UDP 209.179.2.62:5060;branch=30392e3137392e322e36323a3530363
Max-Forwards: 70
Contact: "fargesiaMark" <sip:102@209.179.2.61:5060;transport=udp>
Content-Length: 0
The content search becomes fully distributed on behalf of Peer U,
when all Peers V send a similar message (not shown) to all Peers
W known to it, preserving the Contact header field value from
the original message from Peer U. Each receiving Peer W examines
its content store and issues a Notify to Peer U similar to Peer
V's Notify above, but matching W's content store, not V's.
To prevent searches from circulating indefinitely on the network,
each Peer W maintains a list of Call-IDs seen up to some maximum
number, and refuses to forward search messages bearing Call-IDs
seen in the past.
Content transfer
When Peer U locates interesting content on Peer W, it can request
a content transfer using a SIP Invite message. The Invite is
made to the hash of the content file, learned from the associated
Notify above:
INVITE sip:287af1e2a0180a4df0edd01ee9b38130@209.179.2.62;transport=udp SIP/2.0
Call-ID: a8d78ccab367086072f280ef0b818bca@209.179.2.61
CSeq: 1 INVITE
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=6591
To: "Download" <sip:287af1e2a0180a4df0edd01ee9b38130@209.179.2.62>
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=z9hG4bK9e89e38564ca687a0a0ad1a9ec5f23c1
Max-Forwards: 70
Contact: "fargesiaMark" <sip:102@209.179.2.61:5060;transport=udp>
Allow: INVITE,BYE,SUBSCRIBE,NOTIFY
Content-Type: application/sdp
Content-Length: 91
v=0
o=- 0 0 IN IP4 209.179.2.62
s=EarthLinkPFX
c=IN IP4 209.179.2.62
t=0 0
m=data 1960 udp
The Invite SDP body contains offer information on where to
connect to the Peer W's FSP file server process, in this case
209.179.2.62 UDP port 1960.
Peer W responds with a 200 OK, but changes the SDP service
port to match where its FSP server is running and awaiting file
transfer block requests:
SIP/2.0 200 OK
Call-ID: a8d78ccab367086072f280ef0b818bca@209.179.2.61
CSeq: 1 INVITE
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=6591
To: "Download" <sip:287af1e2a0180a4df0edd01ee9b38130@209.179.2.62>;tag=8923
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=z9hG4bK9e89e38564ca687a0a0ad1a9ec5f23c1
Max-Forwards: 70
Content-Type: application/sdp
Contact: "fluxMark" <sip:msp@209.179.2.62:5060;transport=udp>
Content-Length: 97
v=0
o=- 0 0 IN IP4 209.179.2.62
s=EarthLinkPFX
c=IN IP4 209.179.2.62
t=0 0
m=data 2121 udp
which is followed by Peer U's ACK
ACK sip:msp@209.179.2.62:5060;transport=udp SIP/2.0
Call-ID: a8d78ccab367086072f280ef0b818bca@209.179.2.61
CSeq: 1 ACK
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=6591
To: "Download" <sip:287af1e2a0180a4df0edd01ee9b38130@209.179.2.62>;tag=8923
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=30392e3137392e322e36313a3530363
Max-Forwards: 70
Content-Length: 0
Peer U now issues FSP-like requests
(not shown) out of the SIP signalling band for the content on
Peer W.
When Peer U finishes the transfer, it sends a SIP Bye message:
BYE sip:msp@209.179.2.62:5060;transport=udp SIP/2.0
Call-ID: a8d78ccab367086072f280ef0b818bca@209.179.2.61
CSeq: 2 BYE
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=6591
To: "Download" <sip:287af1e2a0180a4df0edd01ee9b38130@209.179.2.62>;tag=8923
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=z9hG4bKa596629d94b7acc25178d9fd9cdc93d6
Max-Forwards: 70
Content-Length: 0
followed by Peer W's 200 OK response:
SIP/2.0 200 OK
Call-ID: a8d78ccab367086072f280ef0b818bca@209.179.2.61
CSeq: 2 BYE
From: "fargesiaMark" <sip:102@209.179.2.61>;tag=6591
To: "Download" <sip:287af1e2a0180a4df0edd01ee9b38130@209.179.2.62>;tag=8923
Via: SIP/2.0/UDP 209.179.2.61:5060;branch=z9hG4bKa596629d94b7acc25178d9fd9cdc93d6
Max-Forwards: 70
Content-Length: 0