I think your interpretation is mostly correct except that I think there is a
slight possibility where this need not be a do-or-die situation. The RFC has
only a SHOULD strength on UAC and/or UAS behavior once the invitation timer
expires. And its only a MAY strength for stateful proxies.
If you're the IVR UAS developer you can probably take your chances and keep
doing early-media. If the UAC or a Proxy decides to CANCEL the call then
you're out of luck. But if either of these entities are quiet then it seems
that the UAS has discretion on what it wants to do.
Below are the relevant sections from RFC 3261. Pls. note the SHOULDs and
MAY:
UAC Behavior:
The UAC MAY add an Expires header field (Section 20.19) to limit the
validity of the invitation. If the time indicated in the Expires
header field is reached and no final answer for the INVITE has been
received, the UAC core SHOULD generate a CANCEL request for the
INVITE, as per Section 9.
UAS Behavior:
1. If the request is an INVITE that contains an Expires header
field, the UAS core sets a timer for the number of seconds
indicated in the header field value. When the timer fires, the
invitation is considered to be expired. If the invitation
expires before the UAS has generated a final response, a 487
(Request Terminated) response SHOULD be generated
Proxy Behavior:
A stateful proxy MAY generate CANCEL requests for pending INVITE
client transactions based on the period specified in the INVITE's
Expires header field elapsing. However, this is generally
unnecessary since the endpoints involved will take care of signaling
the end of the transaction.
Rajnish
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Andreas Byström
> Sent: Thursday, July 13, 2006 5:57 PM
> To: [email protected]
> Subject: [Sip-implementors] "override" expires in Inivte requests?
>
> Hi all,
>
> I have a question about the Expires header in an Invite. If a
> UA receives an invite (in my particular case the UA is an IVR
> application) and the UA wants to start sending and receiving
> voice without sending a 200 OK it can do so by responding
> with say 180 or 183 that includes the SDP answer to the offer
> in the Invite. Now if the incoming invite included an Expires
> header with value 25, and the UA wants to keep the "early
> media" for a longer time (still with no 200 OK "answer"), is
> there something the UA can do? I checked the RFC and to me it
> looks like the Expires is setting how long time the offered
> session is available, and there has to be a final response
> within that time. Maybe I did misunderstand the RFC or is
> there some other way to only use provisional response? Any
> help is appreciated
>
> Regards,
> // Andreas
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
