Why does the call need to go away, if INFO is rejected? Isn't INFO not supposed to affect call state(s)?
- Sanjay >-----Original Message----- >From: Robert Sparks [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 25, 2007 4:43 PM >To: Adam Roach >Cc: sip List; Dean Willis >Subject: Re: [Sip] INFO: A recap,sense of consensus and a >proposal for direction. > >I'm pretty (actually extremely) unhappy with the idea, but >I'll try not to throw myself on the tracks in front of it. > >Taking a tumble down the slope: > >These info packages need to be separate from event packages - >there may be some where you just derive an info package from >an event package with a trival rfc, but it will _not_ be the >case that it will make sense to throw any old event package's >payload into an INFO like thing like this (think of the mess >you'll get into with anything with a partial payload, and the >bigger mess when you get into the infrastructure of the >framework, including winfo and eventlists). > >And we'd need to specify quite concretely what happens when >one of these INFOs gets rejected. >In most cases, the call is going to have to go away, and I bet >that's going to make a lot of people unhappy. > >RjS > >On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: > >> On 10/24/07 2:18 PM, Dean Willis wrote: >>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>> RFC 2976. >>> >>> This RFC will document use of event bodies in INFO messages >>> exchanged in dialog usages established by SIP INVITE transactions. >>> This will include definition of the "Send-Events" and "Recv- >>> Events" header fields, use of those header fields in INVITE >>> transactions to provide an offer/answer exchange, definition and >>> use of a new option tag for this extension, and the needed changes >>> to the registry established by RFC 3265. >> >> >> I can support such a plan. >> >> I will continue to argue that the event packages and info packages >> should be independent of each other, but that's a minor detail. I >> generally agree with the larger picture. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.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 > > > >_______________________________________________ >Sip mailing list https://www1.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 > _______________________________________________ Sip mailing list https://www1.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
