Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

[Hadriel Kaplan <[e-mail]>]

That was my understanding as well - that ccap wouldn't be used to perform alternate address family selection.  However the current text doesn't clearly say that, but rather is confusing.  Mostly just because of the exact English words being used, I think.

Regardless, ccap can't really be used for alternate address selection anyway, because it doesn't indicate a port number for the ccap alternate address.  It's technically possible to use the same port number for an IP4 and IP6 interface, of course, but it's not practical for many.

But because ccap doesn't support indicating a port number, it also can't be used to indicate an IP address when the m/c= lines indicate a PSTN circuit, afaict.  Right?

If so, then why does ccap even support indicating an IP address to begin with?  Why isn't it *only* for indicating a PSTN circuit, when the m/c lines indicate an IP4 or IP6 default?  In other words, why not just change the ABNF of ccap to only support a PSTN type; or to never be for 'IP4' nor for 'IP6'.

-hadriel


On Mar 15, 2013, at 8:04 AM, [e-mail] wrote:

> I think this goes all the way back to IETF68, where an agreement was made to use ICE for future address type selection (deprecating ANAT).
>  
> I couldn’t find a written statement in minutes on ccap being explicitly forbidden to express IP4 and/or IP6 addresses as alternatives – but my thought has been that alternative IP addresses may only be offered with ICE. This was also reflected in by Jean-Francois (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html) where he says ” As for proposing IPv4/IPv6 alternatives, ICE deprecates ANAT and is the preferred solution the WG has chosen so far per IETF#68. “             
>