Subject: RE: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 25 Jul 2006 10:31:11 -0400

Paul,

I am saying that although the PRACKs and UPDATES may advance the
*proposed* media states, they don't get committed until the INVITE that
started it is complete.  Otherwise, if you applied the same principles
as a re-INVITE on an original INVITE, you would be saying that the call
failed, but the media state is active instead of idle.

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Tuesday, July 25, 2006 9:07 AM
> To: Michael Hammer (mhammer)
> Cc: Christer Holmberg (JO/LMF); [email-masked]; 
> [email-masked]
> Subject: Re: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01
> 
> 
> 
> Michael Hammer (mhammer) wrote:
> > WOW!  What a discussion.  Sorry I didn't jump in sooner.
> > 
> > May I suggest a simple test to verify correctness:  An INVITE and a 
> > re-INVITE should be isomorphic.  By that I mean that the 
> result should 
> > be the same.
> > 
> > Some of the suggested "committed" states would leave an original 
> > INVITE transaction which got a >3xx response in a state 
> where the call 
> > failed, but the media succeeded.  Doesn't make sense to me.
> 
> Can you say more. I am not following your logic.
> 
> > My logic in all this is that while the initial INVITE succeeded
> > (200/ACK) and created stable call and media state, all the 
> subsequent 
> > re-INVITE/PRACK/UPDATE stuff was just haggling about the 
> next proposed 
> > state and in effect is just early media.  It doesn't become 
> committed 
> > call/media state until the re-INVITE gets 200/ACK.
> 
> I think you are agreeing with my position, but am not sure.
> 
> > The next suggestion:  If you want to commit call/media states in 
> > smaller steps, make sure you keep doing the 200(INVITE)/ACK 
> to commit 
> > before jumping to the next stable state.  In other words, 
> if all this 
> > ugliness hurts, don't do it. :)
> > 
> > My $.02 from the peanut gallery,
> > Mike
> > 
> > 
> >> -----Original Message-----
> >> From: Christer Holmberg (JO/LMF)
> >> [mailto:[email-masked]]
> >> Sent: Sunday, July 23, 2006 3:25 AM
> >> To: Paul Kyzivat (pkyzivat); [email-masked]
> >> Cc: [email-masked]
> >> Subject: VS: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01
> >>
> >> Hi,
> >>
> >>> There may be some value in looking at preconditions as
> >> introducing some
> >>> added requirements. But I think that can be left to 
> another day. (An 
> >>> example of when this might come into play is when using
> >> UPDATE (without
> >>> reinvite) to add a stream using preconditions, which will require 
> >>> multiple UPDATES.)
> >> As I wrote in another mail, an alternative to allowing 18x 
> responses 
> >> for a re-INVITE would be to use multiple UPDATEs instead. Then it 
> >> would be much easier to "keep control", because if an  
> UPDATE fails 
> >> there is no possibility that there may have been other 
> offer/answer 
> >> transactions between the UPDATE request and failure response.
> >>  
> >> Regards,
> >>  
> >> Christer
> >>  
> >>
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> >>
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP