Subject: [MMUSIC] ICE-10: Streams with zero port value

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 7 Sep 2006 10:30:13 +0200

Hi,

Maybe it's obvious, and/or maybe I've missed it in the spec, but I can't
find any wording about the handling of streams with zero port value. I
assume no STUN requests (connectivity check or keepalive) will be sent
on such streams. 

I also guess a stream with zero port value should not be considered
"active" (eventhough the direction attribute may be "sendrecv").

Regards,

Christer
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Sep 2006 12:34:14 -0400

Its not in the spec, but should be. You are right, checks should not be 
done for streams with port 0, because that is how we signal rejection. 
However if a stream is just a=inactive then the checks would be done.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Sep 2006 14:02:17 -0400

Can't do checks for c=0.0.0.0 either. But that should be obvious.

	Paul

Jonathan Rosenberg wrote:
>> Maybe it's obvious, and/or maybe I've missed it in the spec, but I 
>> can't find any wording about the handling of streams with zero port 
>> value. I assume no STUN requests (connectivity check or keepalive) 
>> will be sent on such streams.
>>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 7 Sep 2006 21:39:55 +0200

Hi, 

>Can't do checks for c=0.0.0.0 either. But that should be obvious.

What if someone still uses c=0.0.0.0 to do a call hold? Should
keepalives still be sent (assuming the actual address hasn't changed)?

Regards,

Christer

> > Its not in the spec, but should be. You are right, checks 
> should not 
> > be done for streams with port 0, because that is how we 
> signal rejection.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Sep 2006 13:12:52 -0700

> keepalives still be sent (assuming the actual address hasn't changed)?

Yes, you need to send some kind of keepalive traffic, in both 
directions, otherwise the NAT bindings will timeout.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Sep 2006 17:47:39 -0400

Hmm. Well, ICE is basically requiring that the a=candidate line match 
the m/c-line for media and checks to generally be sent during the 
lifetime of the call (it can be sent briefly during call setup when they 
don't initially match, waiting for the reinvite). So, right now I think 
ICE would probably stop keepalives in this case. RFC 3264 specifies 
better ways to do hold (namely a=inactive).

My inclination would be to have ICE not address this case, and work only 
in the a=inactive mode. Do folks think there would be endpoints that are 
ICE capable *and* not supporting a=inactive??

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Sep 2006 17:50:50 -0400

> keepalives still be sent (assuming the actual address hasn't changed)?

You mean continue sending keepalives to the old address that has been 
changed to 0.0.0.0?

Remember, the recipient can't tell if this is being done for hold or for 
some other reason. Once the address has been changed there is no 
guarantee that it will ever be changed back, or that the old address 
isn't now being used for some other purpose.

Because of the way reinvites work, the old address is till in play from 
the beginning of a reinvite until it completes. (If it fails then the 
call reverts to the old address.) So during that time the keepalives 
should continue.

But once a reinvite has completed successfully, all traffic on the old 
address should cease.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 8 Sep 2006 09:17:11 +0200

Hi, 

>You mean continue sending keepalives to the old address that 
>has been changed to 0.0.0.0?

Yes.

>Remember, the recipient can't tell if this is being done for 
>hold or for some other reason. Once the address has been 
>changed there is no guarantee that it will ever be changed 
>back, or that the old address isn't now being used for some 
>other purpose.
> 
>Because of the way reinvites work, the old address is till in 
>play from the beginning of a reinvite until it completes. (If 
>it fails then the call reverts to the old address.) So during 
>that time the keepalives should continue.
> 
>But once a reinvite has completed successfully, all traffic 
>on the old address should cease.

I agree with what you are saying. So, if we add some text saying that
nothing is sent on a 0.0.0.0 stream, we could add some words saying that
0.0.0.0 should not be used for hold. I know it is already generically
said in RFC3264, but we would say what the impacts from an ICE
perspective would be.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 8 Sep 2006 09:21:19 +0200

Hi, 

>Hmm. Well, ICE is basically requiring that the a=candidate 
>line match the m/c-line for media and checks to generally be 
>sent during the lifetime of the call (it can be sent briefly 
>during call setup when they don't initially match, waiting 
>for the reinvite). So, right now I think ICE would probably 
>stop keepalives in this case. RFC 3264 specifies better ways 
>to do hold (namely a=inactive).
> 
>My inclination would be to have ICE not address this case, 

It is important that there are also 0.0.0.0 use-cases defined elsewhere
(3PCC for example), so I think it would be a good idea to add a few
lines of text.

>and work only in the a=inactive mode. Do folks think there 
>would be endpoints that are ICE capable *and* not supporting 
>a=inactive??

I think it's enough that ICE requires the support of inactive. Then, if
"ICE compliant" endpoints still don't support it the ICE spec doesn't
need to fix those cases...

Regards,

Christer