[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] IETF MMUSIC Response to 3GPP LS on .invalid
- To: "Jean-Francois Mule" <jf.mule at cablelabs.com>
- Subject: Re: [MMUSIC] IETF MMUSIC Response to 3GPP LS on .invalid
- From: "Philip Hodges" <philip.hodges at ericsson.com>
- Date: Tue, 21 Oct 2008 10:26:34 +1100
- Cc: peter.schmitt at NSN.COM, mmusic-ads at tools.ietf.org, statements at ietf.org, Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>, Adrian.Zoicas at ETSI.ORG, mmusic-chairs at tools.ietf.org, Susanna.Kooistra at ETSI.ORG, hannu.hietalahti at nokia.com, mmusic at ietf.org
- Delivered-to: ietfarch-mmusic-web-archive at core3.amsl.com
- Delivered-to: mmusic at core3.amsl.com
- In-reply-to: <9AAEDF491EF7CA48AB587781B8F5D7C601482D2F at srvxchg3.cablelabs.com>
- List-archive: <http://www.ietf.org/pipermail/mmusic>
- List-help: <mailto:mmusic-request@ietf.org?subject=help>
- List-id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
- List-post: <mailto:mmusic@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
- References: <9AAEDF491EF7CA48AB587781B8F5D7C601482D2F at srvxchg3.cablelabs.com>
- Sender: mmusic-bounces at ietf.org
- Thread-index: AckfqwmDGn/6HGY8QtejTKimBgHq5wTVpmHQ
- Thread-topic: IETF MMUSIC Response to 3GPP LS on .invalid
Hi Jean-Francois, and other interested parties,
CT4 thanks MMUSIC for their response and in light of the recommendation
from IETF, CT4 has agreed to use 0.0.0.0 for the unspecified connection
address when IPv4 is used.
As the SIP-I on Nc is a profile of the SIP capabilities purely for
support of 3GPP requirements the stage 3 specification makes the use of
0.0.0.0 strictly limited to the function required; deferred MGW
selection. It is not used for other purposes and shall not be signalled
in subsequent INVITEs for example.
On behalf of CT4, thankyou for your support in this matter.
Phil Hodges
Ericsson
Mobile: +61404069546
-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule at cablelabs.com]
Sent: Friday, 26 September 2008 5:40 PM
To: Philip Hodges
Cc: peter.schmitt at NSN.COM; Adrian.Zoicas at ETSI.ORG;
Susanna.Kooistra at ETSI.ORG; Gonzalo Camarillo; statements at ietf.org;
mmusic-chairs at tools.ietf.org; mmusic-ads at tools.ietf.org;
hannu.hietalahti at nokia.com; mmusic at ietf.org
Subject: IETF MMUSIC Response to 3GPP LS on .invalid
Philip,
The IETF MMUSIC working group would like to thank 3GPP for the
liaison statement referenced under
https://datatracker.ietf.org/liaison/449/. 3GPP asked for IETF feedback
on whether the .invalid TLD may be used to indicate an unspecified IPv4
connection address in SDP.
The working group has discussed the question on its mailing list and
also during its recent meeting on August 1 2008 at IETF#72 in Dublin,
Ireland. The MMUSIC chairs specifically requested feedback from IETF
participants on both what is allowed or recommended by IETF RFCs, and
the experience of SDP implementations.
We note that several IETF participants clarified that the question
should be taken in the context of SDP use for an H.248-based protocol
specification. While the feedback we received is mostly coming from SIP
SDP IPv4 implementers, this may be relevant feedback if SDP is to be
re-used between H.248 connections and SIP dialogs, or if
interoperability with IPV4 SIP implementations is important.
Based on the input we received, we would like to recommend that 3GPP
continues to use the 0.0.0.0 IPv4 address to indicate an invalid
connection address in SDP connection lines with IPv4 addresses:
- while the SDP aBNF allows .invalid (RFC 4566), the SDP offer/answer
RFC has a normative requirement for implementations to support 0.0.0.0
as a connection address to indicate that neither RTP nor RTCP should be
sent to the peer (RFC 3264, section 8.4). Note that the use of port 0
has a special meaning per RFC 3264 section 5.1 for unicast streams.
- feedback received on the IETF MMUSIC mailing list from several SIP
implementers indicate that only 0.0.0.0 is supported by IPv4-only
endpoints.
We would appreciate if you could let us know what the additional
discussions in 3GPP conclude for the benefit of the working group
participants.
Regards,
Joerg Ott and Jean-Francois Mule
IETF MMUSIC co-chairs
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic