Subject: [Sipping] Invite with no ring

From: "SINGH VIKRAM" <[email-masked]>
Date: Mon, 26 Nov 2007 17:07:00 +0100

Hi All,

Is there any draft or common practice available to send an INVITE but
with preventing that phone ring (Alert).

What comes to mine mind is a Alert-info header with a wav file playing
nothing

Or I found one old draft
http://www.cs.columbia.edu/sip/drafts/mmusic/draft-dcsgroup-mmusic-resou
rce-00.txt
<http://www.cs.columbia.edu/sip/drafts/mmusic/draft-dcsgroup-mmusic-reso
urce-00.txt>  with No-Ring header

Please suggest whats the common practice

Thanks

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Nov 2007 13:21:53 -0600

It depends what you want to do.
 
See 12.1.1/http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-19.txt. This explains how to DELAY ringing until ready to send media. This is similar to that draft you quoted.
 
If you want to auto-answer instead  of ringing, look at http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-06.txt.

________________________________

	From: SINGH VIKRAM [mailto:[email-masked]] 
	Sent: Monday, November 26, 2007 08:07
	To: [email-masked]
	Subject: [Sipping] Invite with no ring

	Hi All,

	Is there any draft or common practice available to send an INVITE but with preventing that phone ring (Alert).

	What comes to mine mind is a Alert-info header with a wav file playing nothing

	Or I found one old draft http://www.cs.columbia.edu/sip/drafts/mmusic/draft-dcsgroup-mmusic-resource-00.txt <http://www.cs.columbia.edu/sip/drafts/mmusic/draft-dcsgroup-mmusic-resource-00.txt>  with No-Ring header

	Thanks

---

From: [email-masked]
Date: Tue, 27 Nov 2007 15:36:51 -0500

From: "SINGH VIKRAM" <[email-masked]>

I've never heard of a case where anyone would want to do that.  So I'd
be surprised if there was a "common" practice for it.

What is it that you are trying to accomplish?

Dale

---

From: Robert Sparks <[email-masked]>
Date: Tue, 27 Nov 2007 14:40:22 -0600

Are you perhaps looking for http://www.ietf.org/internet-drafts/draft- 
ietf-sip-answermode-06.txt?

---

From: "SINGH VIKRAM" <[email-masked]>
Date: Wed, 28 Nov 2007 17:04:39 +0100

Thanks Steve,
I am trying to implement legacy network service of not-dropping call if
called party hang-up and picks up phone within few seconds.

What I thought is once called party hangup during a call, user-agent
closes session and sends bye to app-server. App server will hold that
BYE for fixed duration and sends an invite back to called party with
no-ring, so that if called party picks up phone again then he can still
connect to the on-going call with calling party

So I don't want to delay ringing, actually I don't need ringing.

Thanks
=vikramsingh

-----Original Message-----
From: Carr, Steve (SNL US) [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2007 4:04 PM
To: Robert Sparks; [email-masked]; SINGH VIKRAM
Cc: [email-masked]
Subject: RE: [Sipping] Invite with no ring

Since the original request referred to the DCS work, he must be trying
to implement a 2-stage commit. Therefore the correct reference is to
Preconditions: 

RFC 3312 Integration of Resource Management and SIP
RFC 4032 Update to SIP Preconditions Framework
RFC 5027 Security Preconditions for SDP

Steve

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Nov 2007 11:17:02 -0600

> What comes to mine mind is a Alert-info header with a wav file playing

This was originally a requirement in the draft that became
draft-ietf-sip-answermode, but we realized early on that conflating the
auto-answer behavior with the alerting behavior would be even more
confusing than the complex model of auto-answer we were talking about.

The general use case is for a diagnostic loop-back call that happens
without interaction from the user. In this mode, the diagnostic systems
places a call to a target. The SDP indicates a loopback, a SIP extension
header (Answer-Mode) indicates automatic answering, and "something else"
indicates that the call proceeds without an "alerting" phase. The call
proceeds without the user of the called node knowing about it.

There has been a very rough consensus to use Alert-Info for this sort of
thing, and I believe Paul K made a proposal for using URNs to designate
certain standard alert modes, one of which could legitimately be a
"null" alert. I don't recall anyone ever putting this proposal into a
draft, but it would seem to be fairly straightforward.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2007 12:38:37 -0500

> draft, but it would seem to be fairly straightforward.

Yes, it has been bounced around but never written up AFAIK.

However a non-alerting auto-answer that enables a full duplex media path 
is an *immense* privacy violation!!!

This would be much more easily implemented in the UA itself. Then there 
would be no protocol issues at all, and no privacy issues. Since you are 
going to need special support in the device anyway, why not do it all there?

	Paul

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 28 Nov 2007 13:23:23 -0600

Thus spake Paul Kyzivat
> Dean Willis wrote:
>> SINGH VIKRAM wrote:
>>> Is there any draft or common practice available to send an INVITE
>>> but with preventing that phone ring (Alert).
>>>
>> draft-ietf-sip-answermode, but we realized early on that conflating
>> the auto-answer behavior with the alerting behavior would be even
>> more confusing than the complex model of auto-answer we were
>> talking about.
>>
>> without interaction from the user. In this mode, the diagnostic
>> systems places a call to a target. The SDP indicates a loopback, a
>> SIP extension header (Answer-Mode) indicates automatic
>> answering, and "something else" indicates that the call proceeds
>> without an "alerting" phase. The call proceeds without the user of
>> the called node knowing about it.
>>
>> There has been a very rough consensus to use Alert-Info for this
>> sort of thing, and I believe Paul K made a proposal for using URNs
>> to designate certain standard alert modes, one of which could
>> legitimately be a "null" alert. I don't recall anyone ever putting this
>> proposal into a draft, but it would seem to be fairly straightforward.
>
> However a non-alerting auto-answer that enables a full duplex media
> path is an *immense* privacy violation!!!
>
> This would be much more easily implemented in the UA itself. Then
> there would be no protocol issues at all, and no privacy issues.
> Since you are going to need special support in the device anyway,
> why not do it all there?

There are a couple other use cases for auto-answer.

1. Scenarios where the user notifies the server they want to place a call, 
the server calls the user's UA in auto-answer mode, and then connects the 
far end as normal.  This is probably better done with something like CSTA, 
but there are cases where that's not appropriate or the vendors haven't all 
implemented some non-SIP method to control the UA.

2. PBXs' traditional "intercom" and "paging" features.  Some users prefer 
ring-answer for privacy reasons, but others find that annoying and prefer 
auto-answer without any sort of tone.

We originally implemented "Alert-Info: auto-answer", with the UA being 
configurable whether to ring or not when acting on that -- and off entirely 
by default -- for the latter scenario.  We've found other vendors have 
abused it to do the former as well, which shouldn't have surprised us.

I'd much prefer a standard solution to this, and we'll take a look at the 
answermode draft.  I also think the idea of using URNs within the existing 
Alert-Info header is promising.  Either is a trivial parser change for us 
once the official solution is agreed upon and published, since the logic is 
already there.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: [email-masked]
Date: Wed, 28 Nov 2007 14:50:00 -0500

From: "Stephen Sprunk" <[email-masked]>

Why not use INVITE-with-Replaces or REFER to accomplish this?  It also
avoids many ugly race conditions (such as "the server calls back but a
different UA answers that call").

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2007 16:17:30 -0500

Inline...

> There are a couple other use cases for auto-answer.

Don't get me wrong. I do believe there are valid use cases for auto 
answer. Its just that IMO the above case isn't one of them.

> 1. Scenarios where the user notifies the server they want to place a 
> call, the server calls the user's UA in auto-answer mode, and then 
> connects the far end as normal.  This is probably better done with 
> something like CSTA, but there are cases where that's not appropriate or 
> the vendors haven't all implemented some non-SIP method to control the UA.

Dale spoke to this one. There are a lot of potential approaches to this.

> 2. PBXs' traditional "intercom" and "paging" features.  Some users 
> prefer ring-answer for privacy reasons, but others find that annoying 
> and prefer auto-answer without any sort of tone.

The latter are more appropriate (and safer) IMO. They have a lot in 
common with PTT - the answering device is *receive only*. You are thus 
subject to objectionable SPIT but not to being tapped.

	Paul

> configurable whether to ring or not when acting on that -- and off 
> entirely by default -- for the latter scenario.  We've found other 
> vendors have abused it to do the former as well, which shouldn't have 
> surprised us.
> 
> I'd much prefer a standard solution to this, and we'll take a look at 
> the answermode draft.  I also think the idea of using URNs within the 
> existing Alert-Info header is promising.  Either is a trivial parser 
> change for us once the official solution is agreed upon and published, 
> since the logic is already there.

The big issue with Alert-Info is one of trust: under what circumstances 
should you be willing to trust the Alert-Info sent to you by the caller?

Most of the use cases I have examined for this have a server acting as 
an agent for the callee. Alert-Info will most often be inserted by it, 
and in other cases it will screen the value. The UAS arranges so that it 
only receives calls via this server and then trusts the A-I from it.

That however begs the question if a caller initiated feature depends 
upon specifying a particular alert.

The use of URNs simplifies this somewhat because they can be 
standardized for both their semantics and rendition, and the UAS can 
choose to accept only those it understands and knows how to render.

So it can know that there are a set of alert URNs that are simply 
different *sounds* all of which will be recognized as alerts, which a 
caller may choose among. It can also know that a particular URN means 
"no alert" and that is should only be permitted in certain 
circumstances, or in conjunction with certain constraints. E.g. with "no 
alert" the microphone might always be shut off.

	Thanks,
	Paul

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 29 Nov 2007 03:31:15 -0800

> different UA answers that call").

I think Stephen is referring to a feature sometimes called
'click-to-call'.  The 'user notifies the server' in a way that doesn't
involve SIP (such as clicking on a web page).  In this scenario,
INVITE/replaces won't work since there is no dialog to replace.

A REFER would work, though.  The example in section 4.1 of RFC3515 is
essentially this scenario.

Michael

---

From: "Carr, Steve (SNL US)" <[email-masked]>
Date: Wed, 28 Nov 2007 07:03:50 -0800

Steve