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

From: [email-masked] (Patrice Calhoun)
Date: Tue, 16 Feb 1999 07:29:46 -0800

>Ahah! Finally back on track.
>
>Pat Calhoun asked
>> Steve Donovan said:
>> >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)
>>
>
>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?

Oh, I agree that there is a problem. I am just not sure that the solution 
proposed is the best one. I suppose I need to really understand why the INVITE
approach cannot work to setup soft-state along the proxy chain. you state that
P4 never sees the REGISTER, but I think that the INVITE/ACK is sufficient
for the proxies to build state. Am I wrong?

PatC
>Thanks,
>--
>Dean Willis

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