Subject: RE: one-way media with 183 Session Progress

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 01 Dec 1999 20:48:57 +0000

Dan,

When a gateway hands a call off to the PSTN, it has no way of knowing
whether or not the call will be answered, be busy or result in an
announcement.  Thus it has no way to determine whether the caller will get a
happy or sad result.

The additional status over a 100 Trying (actually, 100 Trying is a bad
example, as it could have come from an intermediate proxy) message is in the
fact that an early media request has been made.  This will tell the calling
UA to playback this early media instead of playing a ringtone (or some other
type of local alerting).

Steve

-----Original Message-----
From: Daniel G. Petrie [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 4:54 PM
To: David R. Oran
Cc: Matt Squire; Willis, Dean.; [email-masked]
Subject: Re: one-way media with 183 Session Progress

Dave:
I think that we are in agreement.  The problem is that the message may
indicate
a failure, queued, ringing or some other status.

Sorry  I should clearify my concern.  I do not object to early
media.  Handling the early media is not the problem.  The problem is that
183 Session Progress as it stands gives no indication of the meaning of the
message.  It contains little more status than a 100.  Will the user hear a
happy message or a sad one?  ;-)

One comment below:
Cheers,
Dan

"David R. Oran" wrote:

> Gee, I'm not conflicted by this early media stuff at all. Let's say
instead
> of an SDP in the 183 Session Progress the responder put a JPEG image, or a
> HTML page saying "thank you for using AT&T". Only AI level intelligence on
> the part of the initiating UA would give it enough information to know for
> sure what it ought to do with the content. All I see the early media as
> really meaning is "hey, listen to this while I'm trying to complete your
> call".
>
> I can even see uses for this outside of the PSTN gateway scenario. For
> example, I might want to supply music or audio status along with a 182
> QUEUED response - you know - "please stay on the line and an agent will be
> with you as soon as possible".
>
> The fact that this is the ONLY feedback sometimes available is an
> unfortunate consequence of legacy PSTN technology. The alternative is to
> implement full outbound-telemarketer tone/announcement recognition
> capability in every PSTN gateway. Not a tradeoff I'd like to force on the
> gateway vendors (since I "are" one :-) ).
>

I am not suggesting that every gateway need be full featured.  A simple
gateway
could always default to 180 Ringing or 182 Queued.  This signaling problem
exists
with the PSTN and/or Gateway interface.  I am suggesting that we leave it
there,

not propogate it through SIP.  Over time I would hope that the PSTN
signaling
and/or gateway capabilities will evolve to make it economically feasable to
fix
this interface, transparently to the rest of the SIP world.

>
> One point I did make in my comments on the original 183 draft was that we
> should keep the notion of early media, along with the QoS and Security
> advisories separate from the particular 1xx response type. I think the
> authors agreed to separate these things.
>
> I have one question for Dan, interspersed in his note below:
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Daniel G.
> > Petrie
> > Sent: Tuesday, November 30, 1999 4:07 PM
> > To: Matt Squire
> > Cc: Dean Willis; [email-masked]
> > Subject: Re: one-way media with 183 Session Progress
> >
> >
> > The problem that I see with early media is that there is not
> > enough sematics
> > in the response to allow the user agent to make any decisions on
> > what to do
> > with the call.  The user agent may not know whether the call is
> > forked and other
> > responses may come back.  It does not know that whether the message to
> > be played is "number you have reached is out of order" or "please
> > hold your call
> > is being transfered" (i.e. pending failure or setup).
> >
> > I understand that the gateway may not have the sematics either
> > (i.e. because it
> > is a simple gateway without signaling channels or it is blinded
> > by a PSTN switch
> > which is not sending signaling).  Passing this all the way through the
SIP
> > network
> > without a meaning in the early media message is only passing the
> > problem off. The
> >
> > UA is farthest from the source of the issue, how can you expect it to do
> > something
> > intelligent with it.  Enabling intelligence in the end point  is
> > one of the
> > greatest
> > strengths of SIP.  I do not want to pass more noise and confusion
> > to the end
> > user.
> > I want to filter it out.  Without any meaning to 183, the user
> > agent will be
> > forced
> > to either make dumb decisions or overload and confuse the user with more
> > messages.
> >
> > I can see two possible solutions:
> > 1) As Matt has suggested only allow a complete session setup.
> > This does not provide the UA with any more information to make a
decision.
> > It eliminates the decision.
> >
> > 2) Provide more meaningful response:
> > Minimally expand to 183 Session Pending and 184 Session Failing.
>
> Gee, if the gateway could tell that a session was failing it could
probably
> send back a final response directly and dispense with this stuff. As I
point
> out though, it isn't just failure notices that can come back in the audio.
> It's anything that the PSTN stuffs in-band rather than sending back
through
> out-of-band signaling.
>
> > This way
> > the abiguity is not transmitted in SIP.  The meaning of 183
> > Session Pending
> > being that it is likely, but not guaranteed to proceed.  If a
> > gateway is dumb
> > or blinded, it can default to 183.  Let's not make SIP blind as well.
> >
> > Regards,
> > Dan
> >
> > Matt Squire wrote:
> >
> > > I really don't disagree with anything you say except the conclusion:)
> > >
> > > As you state, the billing & QoS aspects are orthogonal to the goal of
> > > getting the "number you have reached is out of order" messages
> > back to the
> > > SIP client.  The 183 I-D says
> > >
> > > "   The only method in the current SIP specification that allows the
> > >    called UA to playback media is to set up a full SIP session. In
PSTN
> > >    interworking situations (and likely in end-to-end SIP sessions)
this
> > >    will cause a billing relationship to be established between
networks
> > >    for the session.  This causes a problem when the reason for setting
> > >    up the media session is to indicate a failure in the session
> > setup.  "
> > >
> > > This seems to indicate that billing is the major impetus for the
special
> > > handling of early media, and I don't think that's the case.
> > >
> > > If the QoS and billing are orthogonal, then the justification for this
> > > seems to be that there's a slight reduction in the number of
> > messages.  I
> > > believe the diagrams in the I-D are slightly misleading, as the
> > 183 has to
> > > be sent reliably, so there are implicit acknowledgement going
> > back that are
> > > not shown in the pictures.  The message savings are not as shown in
the
> > > draft.
> > >
> > > People have raised issues that arise when INVITEs get forked,
> > and you start
> > > playing some early media like "the number has been
> > disconnected" and then
> > > you actually get an answer (200 OK) from another branch.
> > Certainly we can
> > > just have each UA handle things as they see fit, but it
> > demonstrates some
> > > inconsistencies with these 'half-sessions.'
> > >
> > > Early media sessions are media sessions.  Changing the SIP behavior to
> > > accomodate billing/QoS doesn't seem necessary.  The message savings
seem
> > > minimal.  Forking can lead to inconsistent behavior.  The
> > message seems to
> > > be easily bastardizable (is that a word?) to signal 2-way media
> > or anything
> > > else for that matter.
> > >
> > > I just thought SIP had a 3way handshake to establish a media flow for
a
> > > reason.  Getting rid of it in special cases worries me.  But
> > I'm probably
> > > in the minority, so I'll shut up about it now.
> > >
> > > - Matt
> > >
> > > >The early media response is one of the few workable solutions
> > to getting the
> > > >"The number you have reached has been disconnected" messages
> > sourced by a
> > > >terminating LEC switch back to a SIP client accessing PSTN through a
> > > >gateway. The terminating switch never actually sends an asnwer
> > message back
> > > >to the gateway to get mapped into an ACK message, so the
> > originating client
> > > >has to know to "listen" without ever receiving an ACK. From a
> > phone company
> > > >perspective, this call was never completed. Once upon a time
> > the switches
> > > >cut through two ways, but once people learned how to talk
> > in-between the
> > > >rings or send phreak tones, we switched to a one-way cut
> > through towards the
> > > >caller.
> > > >
> > > >I believe this is a completely separable issue from
> > controlling the billing
> > > >aspects of the call, and from establishing QoS around the call.
> > > >
> > > >The issue with early media is that some people see a fraud
opportunity
> > > >tantamount to tricking the phone company into playing the
> > frauding message
> > > >INSTEAD of "the number you have reached" . . .
> > > >
> > > >For example, in the PSTN case one might want any traffic between an
IP
> > > >client and a gateway to have QoS. That's easy enough to do --
> > we just use
> > > >RSVP to set up the QoS like we would beween any other pair of
> > hosts. The DCS
> > > >issues around call clipping pretty much don't occur for IP->PSTN
calls,
> > > >because as the gateway is known BEFORE the digits are outpulsed to
the
> > > >switch, QoS can be set up during the PSTN-side post-dial-delay.
> > > >
> > > >Incoming PSTN->IP calls have a diffeent QoS problem, but they
generally
> > > >don't need to worry about (and perhaps shouldn't even accept
> > at the gateway)
> > > >early media signaling.
> > > >
> > > >--
> > > >Dean
> > > >
> > > >
> >
> >
> >
> >

---

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 01 Dec 1999 21:18:16 +0000

Matt,

The unfortunate reality is that SIP needs to interwork with the PSTN.  In
this interworking, there are scenarios where the eventual disposition of the
call is not communicated via a signaling message.  Instead, it is
communicated via a media session (usually a one-way media session).

It might be possible to set up a full media session in the SIP network for
carrying the early media information.  However, as discussed in the 183
draft, this introduces some other interesting problems.

For instance, there are also requirements that the SIP/PSTN interworking to
be able to properly map SIP signaling messages to PSTN signaling messages.
This is where some of the inter carrier billing discussion came into the 183
draft.  The ability to properly map the SIP signaling messages with the PSTN
signaling messages has a direct effect on the amount of money carriers
charge each other.  Billing may be a bad word when developing protocols, but
it is a reality in the PSTN that signaling events result in billing events.
As such, it is a requirement of the interworking design to make sure that
the signaling does not result in invalid billing events.  

As outlined in the 183 specification, it becomes difficult to address the
second problem without the use of early media sessions.  Not necessarily
impossible, but difficult.

Steve

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 4:15 PM
To: David R. Oran; Anders Kristensen
Cc: Daniel G. Petrie; Willis, Dean.; sip
Subject: RE: one-way media with 183 Session Progress

At 05:00 PM 11/30/99 -0500, David R. Oran wrote:
>> Well, Matts objection remains though: whether it would be "better" to
>> just establish a regular SIP connection right away, play the media, and
>> then possibly transfer the call later.
>>
>Then would you argue that the 182QUEUED response is unecessary as well?
>

I certainly do not argue that 182Queued is unnecessary.  Nor have I argued
that 183 is unnecessary.  Using 183 to establish preconditions (QoS,
security) for a media session is great.  I'm all for it.  

I just don't see a media session as a precondition for a media session.  If
the signalling response has semantics that can be interpreted by the
signalling layer, like 182, great.  If media is being sent back to a higher
layer that has to intepret the media and then filter some appropriate
actions back down the stack, then I'd say a media session was established.
A normal media session.  Not a half-session, not an early media session, an
honest-to-goodness media flow was established.  And I question why we need
to signal it in a different way.  

- Matt

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 02 Dec 1999 18:28:07 -0500

Steve -

I understand that there exist situations where call disposition is not
communicated via signalling and is carried via media...but why can't this
media be signaled like any other media?

I don't understand the billing argument.  There have to be measures
(authentication, accounting, billing) that exist outside of the Early
Media to prevent or cause charging for calls.  There are many reasons why
you may not charge for the call - changing signalling for one particular
reason seems wrong.  Besides, you still need those extra measures for the
Early Media.  What prevents my SIP phone from using an Early Media
response to play back an answering machine message so that I don't get
charged for that media?  Even worse, what prevents me from returning an
Early Media response to establish a 2-way call?  The authorization,
accounting, and billing arguments are orthogonal to the Early Media
response.  Accounting should always happen for the signaling events,
billing can happen later, and may or may not result in charges.  

I understand that your intended usage is for one-way media that contains
information about signaling disposition.  But there is no guarantee that
(a) the media is one-way, (b) the intent of the media is for signalling
information, (c) that the receiver will be able to decipher the intent of
the media and take appropriate signaling action.  This makes the whole
thing seem dangerous to me.  

Signaling disposition is a loose term.  If I setup a proxy at my home
that searches N locations for me while playing back media, "Hi, I'm not
here right now, searching for me at other locations, here's some music to
listen to while we search.."  This is early media with a signaling
dispotion, is it not?  Its just not from a PSTN gateway.  I'm assuming
this Early Media with signalling disposition should not be signaled in a
special way?  

And whose to say that the media is early?  There's no assurance that
other media will follow, this could be all the media you get.   

According to the draft, the reasons for the Early Media response over
just establishing a session are (a) message overhead, and (b) may result
in clipping in the fast answer scenario.  

For (a), since the 183 is reliable, the message overhead for the 'early
media' session is 3 sip messages for both, either INVITE,200-OK,ACK or
INVITE,183,RE-INVITE(for reliability).  If there is additional media, and
you have no guarantee that additional media is forthcoming, then the
second media session can be shortcut by a single message.  Instead of
INVITE,200-OK,ACK, its 200-OK,ACK.  So its half a round-trip *if* a
second session follows.  

For (b), I honestly don't know enough about the clipping issues to argue.
 All I know is that SIP potentially has general clipping problems that we
either need to accept or to fix, regardless of early, late, or normal
medial.  

With a regular SIP who's who as the author list on the 183 I-D, and with
you, Dean, and Dave all speaking for it, I'm sure I'll lose this
argument.  I understand your basic goals, and I agree that they need to
be solved.  

It just makes me a bit queazy to realize that the Early Media response
would allow one to establish an arbitrary media session *without*
establishing the SIP session.  This seems like a blatant and fundamental
violation of the architecture.    In my opinion, and to quote the famous
scholar Deputy Barney Fife, "Someone oughta nip it in the bud."  

- Matt

At 09:18 PM 12/1/99 +0000, Donovan, Steven R. wrote: 

<excerpt>RE: one-way media with 183 Session Progress 

<bigger>Matt,</bigger> 

<bigger>The unfortunate reality is that SIP needs to interwork with the
PSTN.  In this interworking, there are scenarios where the eventual
disposition of the call is not communicated via a signaling message. 
Instead, it is communicated via a media session (usually a one-way media
session).</bigger> 

<bigger>It might be possible to set up a full media session in the SIP
network for carrying the early media information.  However, as discussed
in the 183 draft, this introduces some other interesting
problems.</bigger> 

<bigger>For instance, there are also requirements that the SIP/PSTN
interworking to be able to properly map SIP signaling messages to PSTN
signaling messages.  This is where some of the inter carrier billing
discussion came into the 183 draft.  The ability to properly map the SIP
signaling messages with the PSTN signaling messages has a direct effect
on the amount of money carriers charge each other.  Billing may be a bad
word when developing protocols, but it is a reality in the PSTN that
signaling events result in billing events.  As such, it is a requirement
of the interworking design to make sure that the signaling does not
result in invalid billing events.  </bigger> 

<bigger>As outlined in the 183 specification, it becomes difficult to
address the second problem without the use of early media sessions.  Not
necessarily impossible, but difficult.</bigger> 

<bigger>Steve</bigger> 

</excerpt>

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 13 Dec 1999 15:05:11 -0600 (CST)

>I would think that messages sourced by providers such as 'this number is no
>longer in service' would require QoS.  Will companies really accept that
>these messages, which are really part of their customer interface, reach
>the customer as garbled junk?  
>    "Hi, you've reached XYZ.COM.  We are !#$%^& to *#^% *#(because of #@%*!"
>Can't imagine that going too well with corporate bigwigs.  

I beleive you may overestimate the importance of QoS for this
application. During the SIP bakeoff last week, I made a phone 
call across the public internet with *absolutely* no QoS guarantees. 
I broke out to the PSTN over 1,500 miles away, and called back to 
one of my co-workers.

We were at least two minutes into the conversation before
I revealed to the other party that I was calling him through
many, many routers on the public internet. He would not
have otherwise known that I wasn't calling him from a phone
directly connected to the same PBX.

This was at 5:30 in the afternoon -- one of the busiest periods
for the public internet.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA