Re: INFO Framework - one pakage per INFO
Anders Kristensen <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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