On 01/14/2011 01:39 AM, Olle E. Johansson wrote: > > 13 jan 2011 kl. 23.36 skrev Paul Kyzivat: > >> >> >> On 1/13/2011 10:38 AM, Iñaki Baz Castillo wrote: >>> 2011/1/13 Olle E. Johansson<o...@edvina.net>: >>>> - Does your UA add an SDP to a 488 error message? >>> >>> Most probably no UA in the world adds SDP to a 488 response. >> >> I don't know, but I suspect you are right, or nearly so. >> >>> And for sure, no UA in the galaxy would inspect/interpret a SDP in a >>> 488 response, at least not within next 20 years. >> >> Again I presume you are right regarding *current* status. >> But if it were to become known that doing so is beneficial to completing >> calls successfully, then it doesn't seem at all difficult to do. >> >> For instance, if this were to be seen as a way to achieve better interop as >> IPv6 is deployed, people might be motivated to do it. >> It might be easier that using ICE. OTOH, there are other reasons to use ICE, >> and it is probably a better solution. > > But how would you use ICE in this situation to find out about IPv6 and/or > IPv4 capabilities if only one address family was advertised in the SDP? > Would it make sense to send an IPv4 only offer and ICE candidates in IPv6 and > IPv4? > > If you send me a SDP with only IPv4 and only IPv4 candidates - then I can't > answer with IPv6, I have to deny the call. > > In this case the deny - 488 - will indicate that I actually have a problem > with IPv4 and the NEXT invite may have dual stack offers (multiple media > streams) > or IPv6 only and then we can use ICE to find out the most efficient media > route.
The usage of ICE, ideally, is supposed to follow the same model as for all the other parts of the offer: the offerer indicates *everything* they can support in the list of ICE candidates. If the offerer can support IPv6 but doesn't include it in the list of candidates, then you are right, there's no practical way for the answerer to indicate that it can only support IPv6 and would prefer an offer that includes IPv6. To some extent, this 'optimistic' model is good, because it cuts down on round-trips sending offer/answer pairs until the two endpoints agree. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kflem...@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
