Re: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-01

[Bernard Aboba <[e-mail]>]

Dan Wing said:

 

"By my read, they violate the last paragraph of RFC3264 Section 8.4,
http://tools.ietf.org/html/rfc3264#section-8.4, which says:
 
   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  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.
 
-d"
 
[BA] I believe that there is an issue here, but it is with RFC 5245, not RFC
3264. The RFC 3264 paragraph you cite points out the issues with using
0.0.0.0 to place a user on hold, but that is not suggested in
draft-rescorla-mmusic-ice-trickle.  The usage that is suggested (potential
usage of 0.0.0.0 as a placeholder) is described in the above paragraph, with
agents being required to be able to "receive it" (provided that the port
number is not zero).  The problem is how RFC 5245 implementations will
react.  From RFC 5245 Section 9.1.1.1:
 
   These rules imply that setting the IP address in the c line to
   0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
   MUST NOT utilize this mechanism for call hold, and instead MUST use
   a=inactive and a=sendonly as described in [RFC3264
<http://tools.ietf.org/html/rfc3264> ].
 
The implication is that a SIP error is not generated, indicating that
trickle is unsupported; rather, RFC 5245 implies that implementations may
generate repeated ICE restarts as the trickling proceeds.
 
To understand this better, it might help to test what RFC 5245
implementations actually do in response to a trickle offer. 

 

 

[BA] SDP from createOffer(), Chrome Version 24.0.1297.0 dev

v=0
o=- 1321413050 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:9wMh/Gc6fgJBzvzQ
a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1635880669 cname:ZXVf3drwG3fT+Wh5
a=ssrc:1635880669 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=ssrc:1635880669 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr00
m=video 1 RTP/SAVPF 100 101 102
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:9wMh/Gc6fgJBzvzQ
a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=ice-options:google-ice
a=sendrecv
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=rtpmap:100 VP8/90000
a=rtpmap:101 red/90000
a=rtpmap:102 ulpfec/90000
a=ssrc:1563041388 cname:ZXVf3drwG3fT+Wh5
a=ssrc:1563041388 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=ssrc:1563041388 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr10