Re: [Speechsc] MRCP and mixed IPv4/IPv6 environments

Hi Felix,

In our opinion, this problem is unrelated to cmid or MRCPv2 in general. For example, in SIP the offer may contain multiple media channels, with a mix of IPv4/IPv6 endpoints -- and the problem of what to specify in the answer is the same, except in the case of SIP there's only one control channel (the session itself).

While the clarifications, and especially an informational examples draft, could be helpful, it should come as a follow up to the Offer/Answer RFCs (3264 and 4317), maybe with examples spanning multiple control protocols, including MRCPv2.

-- dan

On Apr 20, 2011, at 1:24 AM, Wyss, Felix wrote:

> Hi Eric,
> 
> It may be true that the IPv6 dependent parts of MRCP depend on other RFCs, but I fear there will invariably be ambiguities that implementers will have to make judgment calls on.  Every time this happens, the likelihood of interoperability issues increases.  As this RFC introduces new SDP attributes, I think it makes sense to proactively identify cases where there may be a particular risk for impedance mismatches and addressing them with examples and/or some prose -- even if non-normative.  
> 
> I feel the "a=cmid" attribute in particular has potential for such ambiguities and think mixed IPv4/IPv6 environments are an area that could benefit from guidance.  At a minimum this will ensure implementers are aware that there may be additional aspects to consider. 
> 
> Thanks,
> --Felix
> 
>> -----Original Message-----
>> From: Eric Burger [mailto:eburger@standardstrack.com]
>> Sent: Monday, April 18, 2011 11:00
>> To: Wyss, Felix
>> Cc: speechsc@ietf.org
>> Subject: Re: [Speechsc] MRCP and mixed IPv4/IPv6 environments
>> 
>> This is a really good point.  Especially in light of IPv4 exhaustion, IPv6
>> should be on everybody's mind.
>> 
>> That said, while it would be extremely helpful to have IPv6 examples in
>> the published RFC, I am not sure the MRCPv2 document under-specifies IPv6
>> use.  Moreover, the speechsc work group will not be the place to work out
>> SDP IPv6 issues.  The good news is according to the SIPit 24 report,
>> almost 70% of implementations came with IPv6 SIP stacks, so we are well on
>> our way to proving interoperability.
>> 
>> Especially since IETF Last Call completed last week, I would offer that
>> IPv6 examples could be a great follow-on Informational draft, if people
>> would like to work on it.
>> 
>> 
>> On Apr 17, 2011, at 1:09 AM, Wyss, Felix wrote:
>> 
>>> The examples in the most recent draft (draft-ietf-speechsc-mrcpv2-
>> 24.txt) use only IPv4 address types.  There is no mention of IPv6, let
>> alone how MRCP should be used in mixed IPv4/IPv6 environments.  I think
>> that should be addressed in the RFC, at a minimum with some examples
>> and/or discussion to provide guidance to implementers.  This seems
>> especially important as the introduction of the "a=cmid" co-media
>> attribute adds another dimension to the media negotiation.
>>> 
>>> As an example, I took a synthesizer sample from the current draft and
>> tried to come up with an offer/answer exchange in a mixed environment with
>> alternate address type semantics (RFC#4091).  I am assuming here that the
>> offerer allows the answerer to accept a different address type for MRCP
>> and RTP by listing both stream identifiers of the IP4 and IP6 RTP streams
>> as two separate "a=cmid" attributes.  Thus, the answerer could elect to
>> use IPv6 for MRCP and IPv4 for RTP:
>>> 
>>> 
>>> Offer:
>>> 
>>> v=0
>>> o=sarvi 2890844526 2890844526 IN IP6 2001:DB8::4
>>> s=-
>>> a=group:ANAT 1 2
>>> a=group:ANAT 3 4
>>> m=application 9 TCP/MRCPv2 1
>>> c=IN IP4 192.0.2.12
>>> a=setup:active
>>> a=connection:new
>>> a=resource:speechsynth
>>> a=cmid:3
>>> a=cmid:4
>>> a=mid:1
>>> m=application 9 TCP/MRCPv2 1
>>> c=IN IP6 2001:DB8::1
>>> a=setup:active
>>> a=connection:new
>>> a=resource:speechsynth
>>> a=cmid:3
>>> a=cmid:4
>>> a=mid:2
>>> m=audio 49170 RTP/AVP 0
>>> c=IN IP4 192.0.2.12
>>> a=rtpmap:0 pcmu/8000
>>> a=recvonly
>>> a=mid:3
>>> m=audio 49170 RTP/AVP 0
>>> c=IN IP6 2001:DB8::1
>>> a=rtpmap:0 pcmu/8000
>>> a=recvonly
>>> a=mid:4
>>> 
>>> 
>>> Example Answer 1 (IPv6 for MRCP, IPv6 for RTP):
>>> 
>>> v=0
>>> o= 2890842808 2890842808 IN IP6 2001:DB8::5
>>> s=-
>>> m=application 0 TCP/MRCPv2 1
>>> c=IN IP4 0.0.0.0
>>> a=mid:1
>>> m=application 32416 TCP/MRCPv2 1
>>> c=IN IP6 2001:DB8::2
>>> a=setup:passive
>>> a=connection:new
>>> a=channel:32AECB234338@speechsynth
>>> a=cmid:4
>>> a=mid:2
>>> m=audio 0 RTP/AVP 0
>>> c=IN IP4 0.0.0.0
>>> a=mid:3
>>> m=audio 48260 RTP/AVP 0
>>> c=IN IP6 IN IP6 2001:DB8::2
>>> a=rtpmap:0 pcmu/8000
>>> a=sendonly
>>> a=mid:4
>>> 
>>> 
>>> Example Answer 2 (IPv6 for MRCP, IPv4 for RTP):
>>> 
>>> v=0
>>> o= 2890842808 2890842808 IN IP6 2001:DB8::5
>>> s=-
>>> m=application 0 TCP/MRCPv2 1
>>> c=IN IP4 0.0.0.0
>>> a=mid:1
>>> m=application 32416 TCP/MRCPv2 1
>>> c=IN IP6 2001:DB8::2
>>> a=setup:passive
>>> a=connection:new
>>> a=channel:32AECB234338@speechsynth
>>> a=cmid:3
>>> a=mid:2
>>> m=audio 48260 RTP/AVP 0
>>> c=IN IP4 192.0.2.11
>>> a=rtpmap:0 pcmu/8000
>>> a=sendonly
>>> a=mid:3
>>> m=audio 0 RTP/AVP 0
>>> c=IN IP6 ::
>>> a=mid:4
>>> 
>>> 
>>> Does that seem like an appropriate interpretation?
>>> 
>>> Thanks,
>>> Felix Wyss
>>> Interactive Intelligence, Inc.
>>> 
>>> _______________________________________________
>>> Speechsc mailing list
>>> Speechsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/speechsc
>>> Supplemental web site:
>>> &lt;http://www.standardstrack.com/ietf/speechsc&gt;
> 
> 
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org
> https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web site:
> &lt;http://www.standardstrack.com/ietf/speechsc&gt;