Re: [Sipping] Liaison Statement on offer/answer procedures

[Paul Kyzivat <[e-mail]>]

Sanjay,

If the reasoning you lay out actually prohibits use of UPDATE in a 
reINVITE, then it must also prevent use of PRACK in a reinvite. And it 
doesn't distinguish between reINVITE and initial INVITE, so that would 
be true there, breaking reliable provisional responses.

But section 28 is not normative, so we shouldn't take it too seriously.

	Paul

Sanjay Sinha (sanjsinh) wrote:
> Christer,
> 
> One comment inline ... 
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Christer Holmberg
>> Sent: Friday, June 06, 2008 2:35 PM
>> To: Ian Elz; Paul Kyzivat (pkyzivat)
>> Cc: Elwell, John; sipping List; Gonzalo Camarillo; Mary Barnes
>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>>
>> Hi,
>>
>>> As one of the one or two people who actually care about Preconditions 
>>> (Paul's email of 4 June 2008). I have been watching the 
>> conversation with interest.
>>> My comments are included below: 
>>>
>>> Paul Kyzivat wrote on 06 June 2008 14:35: 
>>>
>>> I think we are coming to something that seems workable to me. Let me 
>>> try to summarize:
>>>
>>> - If a reINVITE fails, the media session state reverts to whatever it 
>>> had been just before the reINVITE was sent, just as if the 
>> reINVITE had 
>>> not been sent.
>>>
>>> [Ian Elz ] sounds fine
>>>
>>> - If an UPDATE (inside or outside of a reINVITE) fails, any 
>> o/a in the 
>>> UPDATE has no effect on the media session state.
>>>
>>> [Ian Elz ] OK, but how will we determine if an UPDATE is 
>> inside or outside a re-INVITE? 
>>
>> [Christer] I assume that any stateful entity must know whether 
>> it has a pending re-INVITE transaction for a specific call or not.
> 
> But is a UA allowed to send UPDATE while re-Invite transaction hasn't
> completed? 
> 
> It is not clear whether it is legal or not because of conflicting text
> in RFC 3261.
> Here is text from sec. 14.1, which suggests this is legal:
> 	
>    However, a UA MAY initiate a regular transaction while an INVITE
>    transaction is in progress.
> 
> And according to the following text from sec. 28, this call flow is
> illegal.
> 
>    o  RFC 2543 was silent on whether a UA could initiate a new
>       transaction to a peer while another was in progress.  That is now
>       specified here.  It is allowed for non-INVITE requests, disallowed
> for INVITE.
> 
> Sanjay
> 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP