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

From: "Wyss, Felix" <[email-masked]>
Date: Sun, 17 Apr 2011 01:09:15 -0400

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.

---

From: Eric Burger <[email-masked]>
Date: Mon, 18 Apr 2011 10:59:41 -0400

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:

> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web site:
> &lt;http://www.standardstrack.com/ietf/speechsc&gt;

---

From: "Wyss, Felix" <[email-masked]>
Date: Wed, 20 Apr 2011 01:24:39 -0400

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:[email-masked]]
> Sent: Monday, April 18, 2011 11:00
> To: Wyss, Felix
> Cc: [email-masked]
> Subject: Re: [Speechsc] MRCP and mixed IPv4/IPv6 environments
> 
> 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.
> 
> 
> > 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