Subject: [MMUSIC] Candidate address type in ICE

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 11 Nov 2007 20:40:43 +0200

Hi Jonathan,

the SDP format for candidate lines specified in ICE takes 
<connection-address> from RFC 4566, but does not precede it with <addrtype>.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-19.txt

Is the user agent parsing the candidate attribute supposed to figure out 
whether the address is IPv4 or IPv6 somehow or is this information 
encoded somewhere else?

a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host

Thanks,

Gonzalo

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 12 Nov 2007 09:45:40 +0200

> whether the address is IPv4 or IPv6 somehow or is this information

Seems like it. We have standardized APIs that are capable of handling both 
address types automatically (POSIX getaddrinfo() is one). In particular, so 
long as there is only IPv4 and IPv6, it's IPv6 iff there is at least one 
colon. Is there an I-D on HIP for SDP by the way ? :)

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2007 21:04:58 -0500

This is a good catch. During auth48 I'll add a sentence that says that 
the determination is made by looking for the colon.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Nov 2007 09:11:07 +0200

Hi Jonathan,

of course, having an explicit address type would be better than using 
heuristics to figure out what type of address we are dealing with (e.g., 
in order to tackle address types different than IPv4 and IPv6). But 
given the current state of the spec, I guess we can live with that.

Thanks,

Gonzalo

Jonathan Rosenberg wrote:
>> Seems like it. We have standardized APIs that are capable of handling 
>> both address types automatically (POSIX getaddrinfo() is one). In 
>> particular, so long as there is only IPv4 and IPv6, it's IPv6 iff 
>> there is at least one colon. Is there an I-D on HIP for SDP by the way 
>> ? :)
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 Nov 2007 14:09:30 +0100

Hi,

I agree with Gonzalo - it would be good to actually include the <addrpart> in the candidate.

But, if that change can't be done during auth48 (what does auth48 mean, anyway???) I guess we'll have to live with it.

Regards,

Christer 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 13. marraskuuta 2007 9:11
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Candidate address type in ICE
> 
> Hi Jonathan,
> 
> of course, having an explicit address type would be better 
> than using heuristics to figure out what type of address we 
> are dealing with (e.g., in order to tackle address types 
> different than IPv4 and IPv6). But given the current state of 
> the spec, I guess we can live with that.
> 
> Thanks,
> 
> Gonzalo
> 
> >> Le Sunday 11 November 2007 20:40:43 ext Gonzalo Camarillo, 
> vous avez 
> >> écrit :
> >>> Is the user agent parsing the candidate attribute 
> supposed to figure 
> >>> out whether the address is IPv4 or IPv6 somehow or is this 
> >>> information encoded somewhere else?
> >>
> >> there is at least one colon. Is there an I-D on HIP for SDP by the 
> >> way ? :)
> >>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Nov 2007 23:43:23 -0500

Auth48 is the theoretically 2-day period between when RFC-editor 
completes its process and the document is published as an RFC. During 
this period, the editors have a chance to make any final changes and to 
approve any changes made by RFC-editor to make sure those editorial 
changes have not accidentally altered meaning (I have had this happen 
many times in fact).

I believe a syntax change to add a new field is beyond something that 
should be done in auth48. Also note that it would break backwards 
compatibility of the protocol with previous drafts. The last 4 or so 
have been interoperable.

-Jonathan R.