Hi Dave,
Thanks for your suggestion. Indeed, ICE encoding needs an update and we
are hoping to update it in the next version of the I-D.
Regards,
Salman
On Mon, 6 Jul 2009, Craig, Dave wrote:
#1: (5.5.1.3) Binary encoding of IceAttrs for fulfilling IceCandidate
mentioned in draft-ietf-p2psip-base-02
The IceAttrs is a customized, binary encoding of the candidate
specified for ICE [I-D.draft-ietf-mmusic-ice] and ICE-TCP
[I-D.draft-ietf-mmusic-ice-tcp]. This customized version drops
the following fields found in ICE:
o foundation: There is only one media in use for the RELOAD usage of ICE.
All candidates will have either a different type, host candidate, STUN
server, or protocol. There will not be any candidates to freeze when
ICE starts.
o ice-mismatch: RELOAD will prioritize and take TCP transport candidates
before UDP transport candidates.
o remote-candidate: ICE restart not supported.
o component: Same reason as foundation.
The candidate attributes TLV structure below is extensible enough to
incorporate new formats for candidates as well as extensions that all
nodes may not support.
struct {
uint16 IceAttrType; /* CandidateAttrTypeEnum */
uint16 IceAttrLength;
uint8 IceAttrPayload[IceAttrLength];
} IceAttrs;
The supported ranges for CandidateAttrType are:
o 0 through 127: Comprehension required ICE attributes.
A recipient must respond with an error to the
ATTACH, if it does not understand these attributes.
o 128 through 255: Comprehension optional ICE attributes.
A recipient may safely ignore these attributes
if it does not understand them.
The first three definitions within the comprehension-required
range are below. There are no comprehension-optional attributes
defined in this document.
enum {
no_next_attr {0},
ice_base_cand_attr {1},
rel_addr_cand_attr {2}
} IceAttrTypeEnum;
The definition of the first attribute is the base candidate
(ice_base_cand_attr) that denotes the start of a new candidate
in the sequence of candidate in the payload.
enum {
reserved_transport {0},
tcp_simultaneous_open {1}, /* tcp-so */
tcp_active {2}, /* tcp-act */
tcp_passive {3}, /* tcp-pass */
udp {4}
} TransportEnum;
enum {
reserved_candidate {0},
host_candidate {1}, /* host */
srflx_candidate {2}, /* srflx */
prflx_candidate {3}, /* prflx */
relay_candidate {4} /* relay */
} CandidateEnum;
struct {
TransportEnum Transport;
CandidateEnum CandidateType;
uint32 Priority;
IpAddressPort ConnectionAddressPort;
} IceBaseCandAttr;
Reflexive and Relayed candidates must have a rel-addr attribute
that follows them that is defined below for the rel_addr_cand_attr.
struct {
IpAddressPort RelAddressPort;
} RelAddrCandAttr;
Enhancement to AttachReqAns
struct {
opaque ufrag<0..2^8-1>;
opaque password<0..2^8-1>;
uint16 application;
+ uint16 ice_attrs_length;
opaque role<0..2^8-1>;
- IceCandidate candidates<0..2^16-1>;
+ IceAttrs ice_attrs[ice_attrs_length];
} AttachReqAns;
[Note: Tried to reuse layout schema in draft-ietf-p2psip-base-02]
[Problem: Attach-Lite's use of ICE-Lite is not supported in
draft-ietf-mmusic-ice-tcp-07. That document requires the Attach-Lite
recipient proceed with ICE not ICE Lite if there are TCP candidates.
The intended behavior is for Attach-Lite to use RFC4145 instead of
ICE-Lite for TCP connections.]
#2: (9.5 & 9.9) JoinReq, JoinAns, and Leave layouts for overlay_specific_data
struct {
AttachReqAns join_ice_attrs;
} ChordJoinReq;
struct {
AttachReqAns join_ice_attrs;
} ChordJoinAns;
Thanks,
Dave
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
