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

From: [email-masked] (Patrice Calhoun)
Date: Fri, 12 Feb 1999 12:45:31 -0800

>This is an interesting discussion, however I'm not sure that we are going to
>get answers to the questions that Pat is asking.  Only time will tell how
>services providers make money off of IP based telephony services.
>
>However, this is not the purpose of proposing the addition of the session
>timer to the SIP protocol.  The primary purpose is to give the stateful SIP
>Proxy Server a method of determining the validity of the individual sessions
>for which it is keeping state.
>
>Are there comments on the mechanisms proposed in the session-timer draft?

Yes, and I appologize for side-tracking the whole thread. Is there anyway
that we could have shorter INVITEs (perhaps the SIP Server can determine
the length of a session), and have the SIP Client re-register with the 
server periodically, such as:

   SIP Client --------- INVITE ------------> SIP Server
               (some stuff happens here)
   SIP Client < ------- ACK (3 mins) ------- SIP Server
   (2 mins 45 seconds pass, enough to allow for retransmissions)
   SIP Client ---------- FOOBAR -----------> SIP Server
   (where FOOBAR is some message that refreshes the session)

This would allow the SIP Server to have soft-state and time out any sessions
that have not been re-registered (or foobar'ed in the above example).

PatC
>
>Steve
>
>> -----Original Message-----
>> From:	[email-masked] [SMTP:[email-masked]]
>> Sent:	Friday, February 12, 1999 9:39 AM
>> To:	Jonathan Rosenberg; [email-masked]
>> Cc:	Donovan, Steven R. (MCI); [email-masked]';
>> [email-masked]'; Douglas Clowes
>> Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> 
>> >Patrice Calhoun wrote:
>> >> 
>> >> 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 :).
>> >
>> >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.
>> >
>> 
>> This is perhaps my mis-understanding. I have been working with the TIA
>> recently
>> and they have adopted MobileIP/DIAMETER for the next generation cellular
>> data networks. When one considers voice over IP using IP cellular phones,
>> one
>> quickly wonders how the charging will really work. Yes, it is true that
>> one
>> will charge for network access, but conceivably, one could also charge for
>> calls as well. This is especially true if these calls span providers.
>> 
>> Perhaps I have all of this wrong. I understand that charging for an LDAP
>> query cannot amount to much, and perhaps that is all bundled as part of
>> the
>> access charge. Are there any providers on this list that have an idea on
>> how
>> they will actually bill for these services?
>> 
>> PatC
>> 
>> 
>> ---------
>> This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 12 Feb 1999 22:22:01 -0600

Ahah! Finally back on track.

Pat Calhoun asked
> Steve Donovan said:

The problem with this approach is that the SIP server (read, proxy) to
which the client REGISTERs may well not be the one with the
state-keeping probem.

Some calls might be signalled:

C-P1-P2-P3-P4-P5-P6-S

Maybe C registers with P1 and S registers with P6. REGISTERS are
targeted at the proxy acting as a location server -- they don't get
proxied along the chain.

Assume P4 has to keep state, because it is a firewall and needs to know
when to tear the ports down. P4 never sees a register, just the
INVITE-OK-ACK sequence. Maybe P4 sees a BYE at the end of the call, or
maybe C and S just get turned off . . .

How does P4 know when to close the ports? It can't. The timer parameter
gives it a way to expire the sessions . . . alternative to probing the
endpoints.

I had earlier discussed an approach method using SUBSCRIBE/NOTIFY (P4
SUBSCRIBEs to time-mark NOTIFY events on call X from C and S when it
sees the final ACK of INVITE/OK/ACK for call X). Steve Donovan
counterproposed the INFO method and was kind enough to write an ID on
it.

Different solution, but the problem is the same . . .

Can we at least get some consensus that it IS a problem?

Thanks,

--
Dean Willis