Hello, Roni.
Thank you for your comments.
To summary my draft very compactly,
we can draw a diagram:
Input Output
+----------------+
Keyword -->| RELOAD Overlay |--> ChannelID
+----------------+
+----------------+
ChannelID -->| RELOAD Overlay |--> Connection Point
+----------------+
Because we didn't decide which protocol is best protocol for the control
protocol, we did not specify a common protocol. We need to discuss which
protocol is best protocol for the control protocol further. PPSP, modified
SIP, and overlay multicast protocols are candidates for it.
The size of IptvChanInfo is not fixed yet. but, I'll consider big size
problem.
Regards,
Seokkap Ko
----------------------
From: [email protected] [mailto:[email protected]] On Behalf Of
Roni Even
Sent: Wednesday, February 25, 2009 5:40 PM
To: [email protected]
Subject: [P2PSIP] comments on draft-softgear-p2psip-iptv-00
Hi,
I read the draft and think that it is good to see other usage for RELOAD.
I am not sure what is the result of the process described in the draft. In
the SIP usage this enables the peers to start SIP protocol. In this case
there is no protocol specified so the peers find each other but do not have
a common protocol to use for the content.
I am not sure that SIP can be used for the control protocol. I think this
work maybe relevant if P2P streaming is going to be standardize.
Another issue has to do with the size of the information. The IptvChanInfo
structure is quiet big (can be about 1MB), this topic is being discussed on
the RELAOD draft. On one side you can say that this usage have less total
information than SIP usage. (Many small elements in the SIP case or fewer
large elements in this case)
Regards
Roni Even
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
