Subject: RE: [SIP] Session-timer and REFER

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Wed, 21 Feb 2001 15:17:46 -0800

According to the Session refresh draft, if the one of the UA's were to
crash/reboot, if they were to receive such an INVITE (page 7 of the draft),
and they support Session Timer, they are supposed to respond back with a non
200 OK response and set the Session Expires time out to immediate expire
value to notify the far end that this call no longer exists..... that way
the sending UA knows such a reboot occurred and would tear the call down....

Venkatesh

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, February 21, 2001 3:11 PM
To: Venkatesh Venkataramanan
Cc: [email-masked]
Subject: Re: [SIP] Session-timer and REFER

Hi,

>As far as I know you shd be able to modify session refreshes timeout
>anytime, by sending a new INVITE with a higher/lower Session-Expires
timeout
>value.....
> 
>The second problem of the UA mistaking a refresh for a new call is not
>possible, the To: tag in the INVITE would give away.....

Yes, but the idea of using re-INVITEs for the refreshes is because it is
supposed to provide
a keep-alive mechnism, to re-establish the call if a SIP node on the
path has rebooted
(or otherwise lost the call). So, even if there is a tag the UAS would
probably still
try to re-establish the call, because since it rebooted it doesn't
remember it had a
call which it transfered to another user.

Regards,

Christer Holmberg
Ericsson Finland

> 
> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 2:30 PM
> To: [email-masked]
> Subject: [SIP] Session-timer and REFER
> 
> Hi,
> 
> More about the session-timer...
> 
> Assume user A establish a call with user B. A session-timer between A
> and B is also establish.
> 
> Then, B wants to transfer A to user C, using REFER. A will then send
> INVITE to C and establish a session. However, the session between A and
> B is still open (even if there is no media) so the session-timer will
> continue between them.
> 
> My first issue is that A (or B) may want to cancel the session-timer
> during the session with C, and then maybe use it again if the media is
> switched back to B at some stage. One solution would be for either A or
> B
> to increase the refresh timer during the A-to-C call, and then decrease
> it
> again if the A-to-B call continues, but is this possible?
> 
> The other issue is if B re-boots. Now, if A is sending the refreshes, B
> will think it's a new call, so the phone will ring - AND, may start
> sending media to B's RTP port specified in the SDP in the re-INVITE. So,
> when A is talking to C, he may suddenly start hearing announcements,
> ring tones, or even someone talking, from B. A's call control will not
> know about this, since it will receive a 200 OK for the re-INVITE in
> either case.
> 
> Comments?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Feb 2001 01:38:13 +0200

Ok, so then this only works for proxies, which I guess is ok, because a
user would probably notice if the remote party crashes because the media
disaperars.

I still think, however, that sending re-INVITEs, with all headers and
message bodies, is a littly clumsy. Instead there could be "lighter"
method (PING, or something), and if a 481 response is received THEN the
UAC could send a re-INVITE. After all, I don't think the proxies are
going to crash that often, compared to the number of bytes we are going
to send with INVITEs and ACKs... But, that's another issue :)

Christer Holmberg
Ericsson Finland