We discussed this response last Friday 4/8 during the mmusic meeting at
IETF#72 (see mmusic slides from chairs for a response proposal).
A few comments were made at the mike during the session:
- Gonzalo stressed the fact that this LS was related to SDP use in
H.248 and hence that we should indicate in the LS reply that most of the
feedback we got was from the SIP community;
- I stated that while the question seems related to H.248 SDP use, MGCs
tend to have SIP legs and re-use SDP exchanged across the H.248 and SIP
exchanges
- Tom Taylor added that indeed, H.248 SDP interop with what SIP UA do
is important
Therefore, the consensus is still to respond that 0.0.0.0 is
recommended.
I will circulate a draft LS reply before the end of this week
summarizing what I think is the wg consensus on this question.
Finally, Keith Drage and I had a brief chat after the MMUSIC session
related to this. Keith correctly pointed out that the requirement we
have pointed at to justify the support for 0.0.0.0 to indicate an
invalid IPv4 connection address is in RFC 3264 O/A which is applicable
to SIP mostly. We should write up something more generic about this,
may be in a short draft, may be in 4566bis. Thoughts?
Jean-Francois.
-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
Behalf Of Philip Hodges
Sent: Tuesday, August 05, 2008 7:33 AM
To: mmusic at ietf.org
Subject: Re: [MMUSIC] Liaison from 3GPP on how to
encodetheinvalidconnection address in IPv4,
Hi,
can you explain to me the process from now on with this LS - will a
draft be circulated on this exploder for further comment before
being
returned to CT4 ?
best regards,
Phil Hodges
Ericsson
Mobile: +61404069546
-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
Behalf
Of Philip Hodges
Sent: Tuesday, 29 July 2008 9:18 AM
To: mmusic at ietf.org
Subject: Re: [MMUSIC] Liaison from 3GPP on how to encode
theinvalidconnection address in IPv4,
Hi Jonathan,
I just wanted to clarify that the intended use is strictly within
the
bounds of 3GPP SIP-I Core Network. The profile rules will not
permit
signalling of unspecified connection address (in any form) outside
of
the PLMN so in my understanding provided that IETF would endorse
use of
.invalid for "new implementations where no
interworking/interoperability
issues would occur" then I dont see a problem with this. I believe
the
concern within 3GPP would be that IETF would not permit the use of
.invalid for IPv4 but this does not appear to be the case as
described
by Brett below ? So the main concern is receipt of .invalid by
existing
IPv4 implementations but 3GPP SIP-I does not have any existing
implementations - it will be first available in Release 8 which is
not
yet approved.
Best Regards,
Phil
Jonathan Rosenberg wrote:
I think its dangerous to assume .invalid will work with IPv4 hosts.
Most
will not know that it means something special, attempt to look it
up,
fail the DNS query, and probably do something like terminate the
call.
We were able to make this work for v6 because there was no
backwards
compatibility issue.
So my response would be that they should not use .invalid for v4.
-Jonathan R.
Brett Tate wrote:
The liaison statement referenced below by Gonzalo
indicates that the IPv4 0.0.0.0 is currently used as a means to
signal
an invalid connection address in IPv4. The liaison statement asks |
"whether the .INVALID address may be used to | indicate an
unspecified
IPv4 connection | address and does IETF offer any | recommendation
in
this respect ?".
--- specification wise
We had a thread on mmusic related to something close to
this back in 2004:
http://www.ietf.org/mail-archive/web/mmusic/current/msg02532.html
due to the requirement of rfc 3264 Offer/Answer to
require an agent to accept 0.0.0.0 (" An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case
it
means that neither RTP nor RTCP should be sent to the peer."). The
thread seemed to conclude that 0.0.0.0 should be used for IPv4 and
.invalid for IPv6 but the question of .invalid for IPv4 was not
debated
directly.
After a quick check, the SDP BNF
notations from RFC 4566 and its predecessors RFC 2326 & 3266 seem
to
allow the use of .invalid for IP4 connections (a connection address
may
be represented as an FQDN and .invalid is a valid TLD).
AFAIK, no rfc has defined TLD ".invalid" to have the same
meaning as
"0.0.0.0" within rfc3264. RFC 3725 does indicate to look for
future
specification. However AFAIK, only
draft-ietf-sipping-v6-transition has
updated rfc3264 with such usage but only discusses IP6.
--- implementation wise
0.0.0.0 is typically handled by implementers given the
2543 history and the 3264 MUST requirement. How would today's
implementations react to "c=IN IP4 .invalid"? can folks provide
some
feedback?
Although it appears valid per rfc4566 ABNF, isn't something
needed prior
to ".invalid" to be structured like a valid FQDN?
Until more devices support IPv6, I assume many will not treat
IP4 TLD
".invalid" like "0.0.0.0". However once IPv6 supported, I
assume some
will interpret receiving IP4 TLD ".invalid" similar to
"0.0.0.0";
however they likely would not send it unless interoperability
concerns
have been alleviated.
Phil Hodges
Core Network Standardisation
Mobile: +61404069546
Fax: +61395308658
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic