[SIPForum-discussion] [Sip-implementors] Offer/Answer question

Manpreet Singh msingh at ibasis.net
Mon Apr 14 13:41:46 UTC 2008


Agree with session refresh(without o/a in specific). Makes call flow simplistic and in lots of cases avoids interoperability issues caused due to o/a wth re-invites

Thnx

-----Original Message-----
From: Paul Kyzivat <pkyzivat at cisco.com>
To: Manpreet Singh
CC: brett at broadsoft.com <brett at broadsoft.com>; discussion at sipforum.org <discussion at sipforum.org>; sip-implementors at lists.cs.columbia.edu <sip-implementors at lists.cs.columbia.edu>
Sent: Mon Apr 14 09:30:57 2008
Subject: Re: [Sip-implementors] Offer/Answer question



Manpreet Singh wrote:
> That's one reason why I have seen most implementations use re-invites instead of updates for mid call changes. Why leave a possibility of 2 transactions when one can live with 1. But then its implementation specific :-)

Sometimes the call flow won't work right if a human delay is inserted in 
it. In that case UPDATE is ideal because it prevents that eventuality.

The 3pcc call flow RFC (I forget the number) is getting a bit long in 
the tooth now, but it it talks about some cases with that kind of 
constraint.

UPDATE is also useful without o/a for session timer refresh.

	Paul

> Thnx
> 
> -----Original Message-----
> From: Brett Tate <brett at broadsoft.com>
> To: Manpreet Singh
> CC: discussion at sipforum.org <discussion at sipforum.org>; sip-implementors at lists.cs.columbia.edu <sip-implementors at lists.cs.columbia.edu>
> Sent: Mon Apr 14 09:04:10 2008
> Subject: RE: [Sip-implementors] Offer/Answer question
> 
> I agree with Paul; however I'll highlight the rfc3311 section 5.2 text
> concerning UPDATE with SDP potentially triggering a 504.  Thus UAC
> receiving 504 for UPDATE with SDP should be aware that a re-INVITE might
> be needed to perform the SDP modification.
> 
> "If the UAS cannot change the session parameters without prompting the
> user, it SHOULD reject the request with a 504 response."
> 
> 
>> -----Original Message-----
>> From: sip-implementors-bounces at lists.cs.columbia.edu 
>> [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On 
>> Behalf Of Paul Kyzivat
>> Sent: Monday, April 14, 2008 12:34 AM
>> To: Manpreet Singh
>> Cc: Bob Penfield; discussion at sipforum.org; 
>> sip-implementors at lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Offer/Answer question
>>
>>
>>
>> Manpreet Singh wrote:
>>> Wasn't denying the use of update on confirmed dialog, just 
>> saying the 
>>> recommended use of UPDATE is for early dialog and not for confirmed 
>>> based on the spec.
>>>
>>> ""Although UPDATE can be used on confirmed dialogs, it is 
>> RECOMMENDED 
>>> that a re-INVITE be used instead. This is because an UPDATE 
>> needs to 
>>> be answered immediately, ruling out the possibility of user 
>> approval. 
>>> Such approval will frequently be needed, and is possible with a 
>>> re-INVITE.""
>> IMO the "denial" is a bit overstated. It is only pointing out 
>> that its inappropriate if the offer it carries will require 
>> an extended time for approval before being answered. If that 
>> isn't to be the case then there isn't any issue with using UPDATE.
>>
>> Note that the issue with immediate response also applies to 
>> an UPDATE used during an early dialog.
>>
>> 	Paul
> 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080414/14d056a8/attachment-0002.html>


More information about the discussion mailing list