Subject: [SIP] Rejected Email:

From: [email-masked]
Date: Sat, 06 Jan 2001 18:27:31 -0700

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "'SIP List'" <[email-masked]>
Subject: [SIP] Early media replacement.
Sender: [email-masked]
Date: Sat, 6 Jan 2001 17:26:16 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07848.D478F850
Content-Type: text/plain;
	charset="windows-1255"

Hi all,

I was reading the open issues from the last IETF BoF and was wondering what
people had in mind to replace early media:

Excerpt of
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.htm
:

---
2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What about post-dial delays? Reasons for wanting early media:
Billing issue for PSTN interworking. Not cutting off voice. QoS negotiation
(doing PRACK). If don't care about QoS negotiation, no need to do 183s.
...
Problem: for a lot of calls, dialed DTMFs are collected before the call is
officially up. Requires bi-directional media. 200Ok means bi-directional
media path has been established. It doesn't mean the call has been answered.
For bi-directional, send a 280.

--

[280?? I assume this is meant to say 180]

Ok 200 OK really simply means that session is active. However, for a long
time we have been conceptually/implicitly equatign this to mean that the
remote client/phone/person/terminal has "answered". Which is not necessarily
true. [This reminds of a discussion along time ago about a SIP alarm clock
which is an automated SIP device.] 

When the SIP is being used for establishing live communications channels (eg
session to a "terminal") rather than just as a session initiation protocol
(eg gaming servers), then is there a need to indicate the remote terminal
state? 

This seems to me to be the missing link in why it is so difficult to kick
the early media for VoIP (et al) applications - because there is no way to
differentiate session state from terminal state.

In the above suggestion where a one-way session is established and then a
re-INVITE is used to negiotiate the two-way session when the terminal
answers, SIP provides no mechanism (that I can see) for communicating what
is actually going on with the terminal, eg when to start billing. You could
say that you start billing when there is a two-way media stream but is this
the best way to go about it (ie, tied to media level info)? I don't think
so. For instance, you may want to start billing only when the remote
terminal user answers.

[This whole issue is obviously tied to billing but the solution should not
be aimed be at solving only that sub-space of the problem (IMO). I think the
terminal state information should provide the billing information and not
the other way around!]

Is this the right approach, ie, to separate SIP session establishment state
from implied terminal state?
Is this beyond the scope of the WG? [Since SIP is currently primarily used
for terminal based  communications, perhaps not.]
Is there already a "package" for describing generic terminal status that we
can use for SIP?

I'll be interested to hear what people think.

Regards,

Robert.

-- My opinions are my own and do not necessarily represent those of Nuera
Communications, Inc. -- 

------_=_NextPart_001_01C07848.D478F850
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN CLEANED.

REASON:
THE ATTACHMENT CONTAINED AN INVALID EXTENSION OF '.
'

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