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

From: "Jonathan Rosenberg" <[email-masked]>
Date: Mon, 2 Oct 2000 01:17:41 -0400

I agree that the notion of the caller delivering all kinds of media to the
called party, before the call is "answered", worries me a lot. Particularly
if you want the called party to modify some aspect of the "early media
session". Security is definitely a problem here. You can argue that the
called party shouldn't return a 183 with SDP containing a sendrecv parameter
if it didn't know the caller. But, this imposes an unreasonable burden on
the called party.

I think the problem is related to people's coupling of a session with
answering a physical telephone device. To me, the example with the alarm
clock is clear - a session has most definitely been started.

Allowing re-invites before a session is established is complicated. Take the
simple case of a normal phone call. Does the UAS need to collect all these
invites, and then answer them all once it accepts the call? If it accepts,
does it send a 200 OK to the first, then reject the rest, 200 OK to all of
them? WHat happens if one of those transactions doesn't complete? The
primary complexity is really holding on to those reinvites, and then
responding to all when the call is answered. This is quite a pain.

-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: hammer michael [mailto:[email-masked]]
> Sent: Friday, September 29, 2000 1:27 PM
> To: Doug Harbert; Simon Barber
> Cc: Jonathan Rosenberg; 'Tom-PT Taylor'; 'sip'
> Subject: Re: [SIP] Re-direct of Media During Ringing
>
>
> 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
>
>
> At 05:59 PM 09/28/2000 -0600, Doug Harbert wrote:
> >Simon Barber wrote:
> >
> > > > > 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.
> > > > >
> > > >
> > > > 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
> > >
> > > 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.
> >
> >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.
> >
> > >
> > >
> > > >
> > > > 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.
> > >
> > > 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.
> > >
> >
> >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.
> >
> >
> > >
> > > >
> > > > 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.
> > > >
> > >
> > > 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
> >
> >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
> >
> >
> >_______________________________________________
> >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: Henning Schulzrinne <[email-masked]>
Date: Mon, 02 Oct 2000 09:08:00 -0400

It is also not clear why we need these pseudo/half/semi/virtual sessions
in SIP. We can transfer sessions if we need to or use re-INVITE; billing
and such should be handled at a lower layer, not the SIP layer. In
general, I think it would be much better to label the 200 OK response
with some informational indication what kind of session this is ("this
is a robot speaking" or "you're not speaking to the party you dialed,
but rather an automated failure announcement") rather than going down
the 183 route for all but the most primitive PSTN legacy services. 
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Simon Barber" <[email-masked]>
Date: Mon, 2 Oct 2000 10:44:49 -0700

> if it didn't know the caller. But, this imposes an unreasonable burden on

It would be unreasonable to expect every terminal to include this kind of
policy decision. In the normal case calls coming from unknown callers will
pass through a proxy that is part of the called party's domain. The called
party's proxy should provide this filtering policy for incoming calls.

> responding to all when the call is answered. This is quite a pain.

This comes back to a thread from several weeks ago - I believe the initial
INVITE transaction should not extend over the 'ringing' period, but should
complete immediately to signify 'ringing'  (with a disposition indicating
this). Then a subsequent re-invite with a disposition 'answered' would
signify the change in the session when a call is answered.

---

From: "Simon Barber" <[email-masked]>
Date: Tue, 3 Oct 2000 16:08:39 -0700

Another scenario where re-invite during ringing is needed:

I am a user connected to the internet by a modem. My bandwidth is limited,
so I can only receive one stream at a time.

I am talking to a user with a pre-established session.

I want to consult with another person.

I place my established session on-hold.

I call the new person.

I hear an announcement through early media - 'you are in a queue and will be
answered in 20 minutes'

I want to return to talking to the first person while I wait for the second
call to be answered. Because I am on a modem I must put the new call on hold
(I don't have the bandwidth to receive media from 2 sources). Here I need to
send a re-invite during early media, to put the media on hold.

Not allowing re-invite during ringing is an artificial restriction imposed
by a design flaw in the SIP protocol.

Simon Barber.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, October 01, 2000 10:18 PM
> To: 'hammer michael'; Doug Harbert; Simon Barber
> Subject: RE: [SIP] Re-direct of Media During Ringing
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Oct 2000 19:18:12 -0400

The problem is treating waiting in queue as early media - it's a session
and should be treated as such. It's a call when you call the airline,
say, even with steamphones. As I said earlier, the whole early media
stuff is a kludge. The less we use it, the better. Trying to fix the
kludge just adds layers upon layers of double complexity, once for
"real" sessions and once for "pseudo" sessions, for no good reason. With
a real VoIP system (as opposed to one that tries to imitate the analog
phone system), you wouldn't get a voice stream for queueing, it would
just be a 18x message, with no bandwidth difficulties. 
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Doug Harbert <[email-masked]>
Date: Tue, 03 Oct 2000 18:59:48 -0600

> > > >callee to pick it up if he/she wants to.

Simon:
    In this example, you need not receive a media stream to know that you are
in a queue, you should receive a 182 response which may give further details.
However, if you do wish to hear the recorded message, you could after listening
to the message, cancel the initial invite and issue a new invite, this time
refusing the early media stream. You can accept the stream when the farend
answers.
   Another possible way to handle the above example would be for the farend to
actually answer the call, thus establishing a session. Then either side could
issue a reinvite to place the other side on hold. The session is established
but no media is being transferred.

    I still believe that any time you have media flowing, there should be an
established session. This way, both parties have some ability to modify the
media parameters. In the above example, if the farend didn't have sufficient
bandwidth to produce the stream for 20 minutes, it's only option would be to
refuse the call. It could not issue a reinvite prior to answering the call.

Doug Harbert

---

From: Billy Biggs <[email-masked]>
Date: Thu, 5 Oct 2000 09:46:39 -0500

Henning Schulzrinne ([email-masked]):

> [...] As I said earlier, the whole early media stuff is a kludge. The
> less we use it, the better.

  What is the status of the 183 draft?  It  seems like even more of a
kludge if you don't have reliable provisional responses to negotiate the
session.

  Are there any situations where early media is an absolute requirement?
I guess there can't be, since you can always just put your SDP in the
ACK and avoid it altogether.  I strongly believe that its use should be
discouraged in general, because of all these problems.

-- 
Billy Biggs                    [email-masked]
http://www.div8.net/billy/           [email-masked]