Yes, the UAS only needs to keep transaction state for some bounded
period of time as defined by the RFC 3261 non-INVITE server transaction FSM.
Maybe Eric has in mind a UAS that responds to INFOs statelessly as per
3261 sec 8.2.7. I really don't think we need to worry about making that
kind of optimization impossible.
Anders
Hadriel Kaplan wrote:
Umm, wouldn't it only keep it for the duration of a transaction lifetime, which
is the same as it would have to do if it were to send it in an upstream INFO
request?
PUBLISH, for example, does this doesn't it? You don't respond to a PUBLISH
until you've fully processed the publish request, including all Event Package
body content. (and both request and response can have bodies for their event
package)
-hadriel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric
Burger
Sent: Monday, December 01, 2008 5:21 PM
To: Anders Kristensen
Cc: SIP List
Subject: Re: [Sip] INFO Framework - one pakage per INFO
What you are asking for is the UAS to keep state indefinitely on each
200 OK, because the UAC may or may not be there to retransmit the
first INFO request. That does not sound like an ideal design.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
