Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt

From: [email-masked] (Patrice Calhoun)
Date: Thu, 11 Feb 1999 16:05:43 -0800

Well, perhaps I missed something fundamental here, but my understanding is that
what we have here is analogous to two telephones using the PSTN to get the
call endpoint established, and then completely ignores the PSTN. 

If this is the case, certainly the PSTN carrier can charge for the initial 
endpoint resolution information, but is not involved at all afterwards. So
an intelligent user could figure out what physical port on which switch to
contact to get to his mother, and completely bypass the IN.

My only concern here is how does the service provider offer a service *and*
make at least enough money to recover the capital costs (of course, certain
providers may want to cover many additional costs, which is outside the scope
of this discussion :).

PatC

DISCLAIMER: I have a funny feeling that I've missed something fundamental here.
Please feel free to correct my statement above if it is technically incorrect.

>At 16:49 1999-02-11 -0500, Jonathan Rosenberg wrote:
>>Patrice Calhoun wrote:
>>> 
>>> My understanding is that a SIP Client issues an Invite message to a SIP
>Server,
>>> which in turn forwards the request to a target SIP Client (or some GW or
>some
>>> sort). Once the ACK has returned to the originating client, I was under the
>>> impression that both SIP Clients send RTP packets directly to each other,
>>> bypassing the SIP Server (this is where I am unclear).
>>
>>Slight correction - ACK goes from caller to callee.
>>
>>But, in general, you are right. RTP bypasses the SIP servers.
>>
>>> 
>>> So if this is true, how will a SIP Server (stateful, or stateless)
>enforce any
>>> session timeouts? A malicious SIP Client can simply keep the session active
>>> for as long as it wishes, ignoring any messages from the SIP Server that
>may
>>> tell it to disconnect.
>>> 
>>> This, as far as I can see, could cause some serious problems if one
>wishes to
>>> deploy a service and still maintain some control over the sessions.
>>
>
>One wonders about the nature of the service you think to deploy. Where you
>want to maintain session control without control of at least one enpoint.
>
>>This is an excellent, excellent point, and is something I have been
>>considering since the whole timeout/DTMF/INFO issues came up. The
>>question you ask gets back to a more basic problem.
>
>>Since, unlike
>>traditional telephony, voice does not flow through the servers
>>(gatekeepers or SIP servers or MXCP call agents) in Internet telephony,
>>any sort of "control" a server would like to execute is based on an
>>assumption that the user agents (the ones sending/receiving the media)
>>would obey the servers.
>
>Indeed, in traditional telephony (at least the SS7 kind), voice does not
>flow through the control points. Control is maintained by having voice
>nodes that obey control nodes.
>
>In H.323 gatekeepers, the gatekeeper may route the control channels between
>the endpoints, and issue termination commands in each direction, on those
>channels. A gatekeeper may route the media through itself (although this is
>unlikely), or another entity. What you wouldchoose to do would depend on
>your trust of the level of control you exert on the endpoints, and the
>consequences of any lack of control.
>
>If you don't trust either endpoint, but must control the media session, or
>conceal the endpoints from each other, you may have to route the media
>through a Meter Box (tm), that you can trust. There are gateways that
>transcode media (G.711 to G.723.1 for example) and a similar mechanism,
>without transcoding, could be deployed.
>
>> Consider the example of call transfer. Lets say
>>we'd like to signal the service using DTMF, so a proxy subscribes to the
>>DTMF from the client. The client presses the appropriate buttons on the
>>phone, and the proxy decides to transfer. But, the media doesn't flow
>>through the proxy, so it has no way of actually transferring the call.
>>Rather, it will need to go back and tell the user agent to perform the
>>transfer, since only the user agent can affect where the media goes to.
>>In that case, why would the UA ask the network for the service in the
>>first place?  It can simply be invoked directly by the client. In a
>>network where voice transport is end to end, services based on changing
>>characteristics of that transport (coding, destination, etc), must also
>>be end to end. 
>>
>>Now, if the action the proxy asks to user to take is something the user
>>wants to do anyway, maybe thats OK. But, if its something less
>>cooperative, like forcing a hangup, or transferring to an operator,
>>there is simply no incentive for the user to accept this. 
>>
>>-Jonathan R.
>>-- 
>>Jonathan D. Rosenberg                       Lucent Technologies
>>Member of Technical Staff                   101 Crawfords Corner Rd.
>>High Speed Networks Research                Holmdel, NJ 07733
>>FAX: (732) 834-5379                         Rm. 4C-526
>>EMAIL: [email-masked]
>>URL: http://www.cs.columbia.edu/~jdrosen
>>
>>---------
>>This message came from the IETF IPTEL Working Group Mailing List.
>>
>
>
>Douglas
>

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Douglas Clowes <[email-masked]>
Date: Fri, 12 Feb 1999 12:44:47 +1100

At 16:05 1999-02-11 -0800, Patrice Calhoun wrote:

People talking about completely different subjects in the same thread is
possible - been there, done that, got the flame-broiled t-shirt.

>call endpoint established, and then completely ignores the PSTN. 

I don't think that the analogy quite fits.

In the PSTN world (which varies from country to country, if not county to
county) you have a {C|I}LEC which controls your access to services. Beyond
them is the long-distance carrier, which the LEC may control, or you may
have choices. Beyond that is the international carrier, and then ... the
terminating LEC. The LEC desires to control your choices all the way, and
only legislation prevents them from doing so, but only to the extent of the
long-distance carrier.

The IP world is different (in case you haven't noticed :), because (I
think) that once you have selected your LEC-equivalent access provider,
your carriers are fixed. You can, however, choose the services you use in
the IP world, just as you choose the numbers you dial in the PSTN world. IP
telephony is a service in the IP world.

The connection-broker and the carrier may be different in the IP world, but
not the PSTN world. You use the connection-broker to get the call
connected, and then the IP-carrier to continue the call. There will
possibly be connection-broker service providers who want to tie you in and
sell you a transport service that they don't provide, and you already pay
for to your ISP. Avoid them.

To extend the model, in cases where you are using a PSTN gateway to egreee
into the POTS world, there may be another service provider involved. This
is a service you may not be able to avoid.

If you use your POTS phone and an ingress gateway, there may be yet another
service provider involved. They will have more success in charging you for
transport, which they do provide, and egress, for which they have to pay.

>contact to get to his mother, and completely bypass the IN.

If your mother has an IP phone, and she tells you her IP address, go for
it. If you have to pay someone for it, keep it. If it's dynamic, you'll
have to get it each time ...

If your mother has a black phone, and her switch provider lets you do that,
go for it. I think they'll want to charge you, or her, for access.

>providers may want to cover many additional costs, which is outside the scope

Well, I think the terms "what the market will bear", and "supply and
demand" may come into effect here. The term "caveat emptor" should too,
because there are people out there who will ask you to pay for the air you
breath (some people call them "government").

The question I ask, is what service is the provider actually providing, and
what are the capital cost involved. Also, unless there is a healthy profit
margin, most entrepreneurs will take their capital somewhere that there is.

Your access provider (ISP) may charge you by the connect-second, by the
calendar-month, by the byte, or all of the above. They have to provide you
with access, and backbone transport, and that's about it. Is your ISP
charging $19.95/month flat-rate? A cable modem here will cost you $65/month
plus $0.30/Mb. Either way, we already pay for connection and transport.

What is the Internet Telephony Service Provider (ITSP) providing if you and
your mother both have NetMissing, and you use
DNS/LDAP/key-it-in-dotted-decimal as your connection broker? Well, if you
use a $0.20 per lookup LDAP service ...

No, the major service providers will be ingress/egress gateway service
providers. That's where your PSTN analogies become more real, and so does
the service providers control. And the egress GW service provider has to
pay the terminating LEC for access ...

And when the LEC offers egress GW service in their switch, and charge the
ITSP higher access charges ...

>Please feel free to correct my statement above if it is technically
incorrect.

Be carefull you correctly identify which services you provide.

Douglas

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Feb 1999 21:20:41 -0500

> providers may want to cover many additional costs, which is outside the scope

It comes back to the same question thats been brought up here on
numerous occassions - what are you billing for? SIP provides the setup
services, not the transport services. So, it makes sense for a SIP
server to charge for what it actually does - set the call up. It really
doesn't make sense, I don't think, to try to bill by the minute for the
SIP part of the call, since its really a transaction service. SIP is
only one part of the picture, though. There is also transport service -
diffserv prioritization, for example. A service provider can happily
charge by the minute,bit, packet, or whatever here.

-Jonathan R.

---------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Feb 1999 21:54:54 -0500

> charge by the minute,bit, packet, or whatever here.

One argument for a closer relationship between a transport stream and
signaling is that signaling may have access to information not (easily)
available to the lower layers, for example, customer-level strong
authentication. It could be argued that one should fix, say, RSVP to
include this information in the appropriate form since it may well be
needed for other, non-telephony services like media-on-demand.

Another point is that Internet telephony may well fail in more
interesting ways compared to telephones. For example, if I have an
architecture (as in the mbone tools) with separate audio/video media
agents and a signaling application, I may want to terminate the call if
any one of these components dies, as I may loose control over the rest. 
You could easily have the SIP call setup agent stay up (one would hope
so), with the audio agent hung and gone. The customer can't talk and
will demand a refund. Similarly, if the audio agent stays around (in the
background) and merrily sends receiver reports, but the SIP agent has
bid farewell in the French style, the customer also would want to not
pay for this useless session, even if the number called happens to be a
1-900 number with a continuous loop of the daily horoscope.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---------