Subject: [MMUSIC] draft-veikkolainen-mmusic-ice-suppress-checks

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2010 11:47:25 -0700

How does draft-veikkolainen-mmusic-ice-suppress-checks differ from both
endpoints running ICE-Lite?

-d

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 10:28:21 +0200

>endpoints running ICE-Lite?

The aim is to allow sending connectivity checks for some address candidates, but suppress them for others. An example would be a PSTN address candidate, for which no connectivity checks are done, plus a v4/v6 address candidate pair, for which connectivity checks would be done.

Simo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 09:15:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 22, 2010 1:28 AM
> To: [email-masked]; draft-veikkolainen-mmusic-ice-suppress-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-veikkolainen-mmusic-ice-suppress-checks
> 
> The aim is to allow sending connectivity checks for some address
> candidates, but suppress them for others.

Ok.  It would be helpful to add some text to the draft on that.

> An example would be a PSTN
> address candidate, for which no connectivity checks are done,

I haven't been following the draft that sends media over PSTN,
draft-ietf-mmusic-sdp-cs.

How would ietf-mmusic-sdp-cs and veikkolainen-mmusic-ice-suppress-checks 
handle the case where the PSTN can't make a call (the famous "BEEP BEEP 
BEEP, All Circuits Are Busy" on Mother's Day or Christmas).  

If ietf-mmusic-sdp-cs becomes popular, there will be a lot of calls
routed over the PSTN during an Internet path failure, causing a spike
of PSTN circuits being used.

> plus a v4/v6 address candidate pair, for which connectivity 
> checks would be done.

-d

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 08:58:31 +0200

>From: ext Dan Wing [mailto:[email-masked]]
>Sent: 22 October, 2010 19:16
>To: Veikkolainen Simo (Nokia-MS/Helsinki); draft-veikkolainen-mmusic-
>[email-masked]
>Cc: [email-masked]

We can add some text on this for sure.

>BEEP, All Circuits Are Busy" on Mother's Day or Christmas).

One way would be to have the application monitor the state of the CS call, and tear down the SIP session in case the CS call didn't go through. This is not however discussed in either of the drafts at the moment.

In sdp-cs draft, when the "DTMF correlation" mechanism is used, we discuss the possibility of making a "silent" call. Something similar could be done also for the case where we want to be sure that the CS call is successful. But, as I said, we don't have anything in the protocol to support this.

Simo