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

["Dean Willis" <[e-mail]>]

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?

Thanks,

--
Dean Willis