Subject: RE: [SIP] Re-direct of Media During Ringing

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2000 23:09:59 -0400

I don't follow the scenario. Can you elaborate?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, September 25, 2000 4:02 PM
> To: sip
> Subject: [SIP] Re-direct of Media During Ringing
> 
> 
> The consensus expressed in Pittsburgh was that additional 
> transactions could
> be opened before the final response to the initial INVITE has 
> come back.
> Section 4.2.1 forbids the issuance of re-INVITEs under these 
> circumstances.
> I have a case (blind call transfer) where I don't want to 
> interrupt the
> alerting being provided to the called subscriber, but I do 
> need to change
> the media path.  Do we really need the restriction on re-INVITE?
> 
> Tom Taylor
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Simon Barber" <[email-masked]>
Date: Tue, 26 Sep 2000 21:33:17 -0700

I see the restriction on re-invite during ringing as dangerous. Media
delivered during ringing might not be simply "ringback" to the caller, but
might also include media delivered to the callee. This might be used, for
example for:

Audio paging to a telephone/telephones
Delivering video of the caller early
Delivering any push media channel, where the user wants to receive the
channel without or before explicitly accepting the call.

I think there are many possible services that could be created using this
facility (obviously the user must have privacy controls for this type of
call). Because of the range of services that might use push delivery without
explicit acceptance it could potentially be dangerously limiting to not
allow re-invite during ringing.

Example service:

Morning alarm clock, calls me on my SIP phone, connecting early inbound
media first to a quiet internet radio station (the phone plays this on its
speaker, instead of ringing), then if unanswered after 2 minutes, re-invite
the early media to a thrash metal sample from an RTSP server. When the call
is answered connect me to a message telling me what's on my to-do list
today, and reminding me it's my girlfriend's birthday.

Simon Barber

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Tuesday, September 26, 2000 8:10 PM
> To: 'Tom-PT Taylor'; 'sip'
> Subject: RE: [SIP] Re-direct of Media During Ringing
>
>

---

From: Doug Harbert <[email-masked]>
Date: Wed, 27 Sep 2000 10:50:14 -0600

> > > the media path.  Do we really need the restriction on re-INVITE?

The applications you describe here sound like sessions. In fact, any time one
party delivers media to another party, there is a session and there should be
explicit agreement between parties to form this session. Perhaps what is needed

here is a way for your sip phone to automatically answer calls from your alarm
clock, or for your pager to automatically answer calls and perform the page.
These devices could modify their behaviors depending upon the application
requested for the session, low level alarm, high level alarm, page.

The recipient of the call or his/her agents (phones, pagers,...) must have the
authority to decide whether or not to accept the session, and receive media.

Doug Harbert

---

From: "Simon Barber" <[email-masked]>
Date: Wed, 27 Sep 2000 14:26:22 -0700

> explicit agreement between parties to form this session. Perhaps

By this notion there should be no re-invite at all - changing the media at
all would be counted as a new session, requiring the user explicitly accept
the new session. I do not accept this at all.

> requested for the session, low level alarm, high level alarm, page.

Automatically answering calls is different from delivering media before the
answer. If you automatically answer a call there is no possibility for the
callee to later really answer the call. For example the alarm clock servive
I proposed would not be possible - the service is terminated by the callee
answering the call, listening to a message, and hanging up.

> authority to decide whether or not to accept the session, and

Certainly the recipient of the call should have good control over what
sessions they accept, and these control should include controls over
sessions delivering media before the call is answered. These controls may be
partly provided in the UA and partly in the proxy servers that forward the
call to the user's UA.

Simon Barber

---

From: Doug Harbert <[email-masked]>
Date: Thu, 28 Sep 2000 17:59:59 -0600

> the new session. I do not accept this at all.

No, re-INVITE during an established session is ok. The above example indicates
a re-INVITE before the session has been established. Possibly a better method
would be to CANCEL the current INVITE and issue a new INVITE to establish a
different session.

> answering the call, listening to a message, and hanging up.

If your SIP phone has automatically answered the call because it recognizes
that it is from your alarm clock, then the session is established. There is no
need to tear it down just because a person wants to talk. Your phone as an
intelligent endpoint could recognize the off hook, and if necessary issue a
re-INVITE to modify the session parameters for the voice call.

> partly provided in the UA and partly in the proxy servers that forward the

Delivery of media to the callee before the session has been completely setup
worries me somehow (I picture telemarketers sending their spiel into my living
room). But I suppose that since the callee can accept or reject this media via
the SDP in the 183 then that allows sufficient control. This may be useful if
the endpoint can recognize the caller and allow or disallow receipt of the
media according to who is calling. Though if the SIP phone can do this, it
should be able to accept the call for call screening purposes, and allow the
callee to pick it up if he/she wants to.

Doug Harbert

---

From: hammer michael <[email-masked]>
Date: Fri, 29 Sep 2000 10:27:20 -0700

Simon,

I would not rely on being able to identify the calling party (long live 
anonymity???).  As I have noticed on the telephone network, telemarketers 
are very good at not identifying themselves ("out of area" on my caller id 
box) and can be expected to do the same on the net.

Mike