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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Oct 2000 15:02:10 +0100

And that may be the very reason why the kludges exist.

There will be implementations of SIP that will need to including charging
for the provision of a session, and for the provision of a media stream.
That aspect, and how such charging should be made, is entirely up to the
implementor. However, there may need to be an end-to-end flow, or at least
between the proxies, that says "charging is now valid", or some such, and
sent to the end user as "charging is now being applied", and this may be
different from the acceptance by the end user of either a media stream or
the session. Without that separation of charging from acceptance, then no
session or media stream can be accepted until charging is due to start, thus
resulting in this concept of "early media", which in essence is "before
charging starts".

Keith Drage

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Henning Schulzrinne[SMTP:[email-masked]]
> Sent: 	04 October 2000 13:49
> To: 	Mark Watson
> Cc: 	'Drage, Keith (Keith)'; Simon Barber; Jonathan Rosenberg; 'hammer
> michael'; Doug Harbert; Tom-PT Taylor; 'sip'
> Subject: 	Re: [SIP] Re-direct of Media During Ringing
> 
> Can we please remove the word "charging" from the discussion? SIP has
> nothing directly to do with charging or billing, as discussed numerous
> times on this mailing list. Tying SIP requests to charging in a
> PSTN-like way is only going to lead to convoluted, inflexible and
> bell-headed architectures.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

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

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Mon, 09 Oct 2000 00:44:32 +0200

Hi,

"During call setup, caller cannot change its SDP to receive early media".

I signaled a similar issue a few weeks ago, see the thread on:
         "[SIP] Media & Signaling inter-dependencies, issue with 183"

IMO, 183 and PRACK is a lot of complexity for a feature that is needed for 
PSTN legacy reasons.

A simpler solution would be to 200 OK the session early on and provide PSTN 
call progress info using re-INVITE. This probably requires some new header 
to explain
the progress cause (in-band-ringback, queued, connected, failed, number 
disconnected, charging starting...).

Jean-Hugues Robert

  At 03:01 PM 9/25/00 -0500, Tom-PT Taylor wrote:
>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
>

---------------------------------------------------------------------------
      "Don't kill the messenger!" - Sophocles 442 BC. Shakespeare 1598.
Sophia General Manager.
tel: (7)263
mailto:[email-masked]      - We serve providers -     "Think globally.
http://www.netergynet.com     - Hosted PBX solutions -        Act locally."

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 19 Oct 2000 09:52:12 -0500

Sorry to take so long to reply to this, but it was a nice vacation :-)  In
my particular situation I am not talking about early media.  Instead, it's a
matter of where media gets directed when the call is answered.  Here's the
primary call flow as I envisioned it:

UAC->UAS: INVITE(Call-Id=x, CRef=y; SDP)
UAS->UAC: 180 Ringing

Now the UAC finds it necessary to send new SDP.
UAC->UAS: INVITE(Call-Id=x, CRef=y+; new SDP)
UAS->UAC: 200 OK to the new INVITE
UAC->UAS: ACK

Now the called party answers:
UAS->UAC: 200 OK to the original INVITE
UAC->UAS: ACK

There is an obvious race condition where the called party answers before the
re-INVITE is processed.  No matter what approach we take, the called party's
initial greeting will be clipped in consequence, so the real issue is to
make sure that the call processing sequence is consistent with the general
spirit of SIP while meeting the requirements of the call. 

With the call flow above, the race condition is no problem for the call
processing.  From the UAS point of view, we end up with serial INVITEs
rather than nested ones.  It's slightly more complicated for the UAC -- the
order in which it receives the respective final responses changes.

One open issue in my mind is whether a second 180 Ringing interim response
has to be sent to indicate call state as a result of the second INVITE.

The alternative call flow is as follows:

UAC->UAS: INVITE(Call-Id=x, CRef=y; SDP)
UAS->UAC: 180 Ringing

Now the UAC finds it necessary to send new SDP.
UAC->UAS: CANCEL
UAS->UAC: 200 OK

UAC->UAS: INVITE(Call-Id=u, CRef=v; new SDP)
UAS->UAC: 180 Ringing

Now the called party answers:
UAS->UAC: 200 OK to the new INVITE
UAC->UAS: ACK

Again we have a race between called party answer and the second invitation.
This time it leads to trouble.  When the second INVITE comes along, the
application behind the UAS may perceive that the called party is busy and
refuse the call.  The calling party sees the call go from alerting to called
party busy state, and the called party answers a call with no one there.
The risk of this race occurring may be acceptable, but the matter is open to
discussion.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, October 02, 2000 1:18 AM
> To: 'hammer michael'; Doug Harbert; Simon Barber
> Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; 'sip'
> Subject: RE: [SIP] Re-direct of Media During Ringing
> 
> 
> 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'
> > 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
> > >
> > >