[reSIProcate] rfc 3311 update in confirmed dialogs

[Scott Godin]

FYI - I'm pretty sure I came across one implementation that did not accept
offer/answer in an UPDATE, even though it advertised UPDATE support.  If
this becomes more of a concern we could add a profile option to always use
re-invite for mid-dialog SDP exchanges - to try an deal with these
non-compliant endpoints.  Technically if an endpoint advertises UPDATE
support then is must support SDP offer/answer in UPDATE mid-dialog, despite
the RFC recommending that it not be used.

 

Scott

 

From: Justin Matthews [mailto:jmatthewsr at gmail.com] 
Sent: July-05-07 9:14 PM
To: 'Scott Godin'; resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] rfc 3311 update in confirmed dialogs

 

Thanks Scott. For correctness I believe the section in RFC4028 is 7.4.  

 

There is no use case or failed scenario, the question was just in regards to
generally accepted behavior.  The main concern is vendors support for the
UPDATE method to modify the sdp as opposed to re-INVITE.  With the recent
change to add UPDATE as a default supported method, there is some, albeit
small, concern over this. To date we have not used UPDATE.

 

RFC3311 does not show that it is updated by 4028 on ietf.org and it seems
4028 is written in the spirit of session refreshes where it is desired to
eliminate superfluous information.  Although, 4028 at the end of 7.4 does
mention that UPDATE or re-invites not intended as session refreshes have the
same effect as session refreshes.  Maybe 4028 should be listed as updating
3311.

 

Thanks for the clarification, I'm sure we will find that UPDATE when listed
as a supported method is fully functional by all UA's we encounter.

 

Thanks,

 

-Justin

 

 

  _____  

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Thursday, July 05, 2007 4:21 PM
To: Justin Matthews; resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] rfc 3311 update in confirmed dialogs

 

DUM behaves the way it does due to recommendations in RFC4028 (7.1) -
preferring UPDATE as opposed to re-INVITE for session timers.  

 

Do you have a use case where user interaction is required for a re-invite
that would make using a re-invite a requirement for DUM SDP negotiations?

 

Scott

 

From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of Justin
Matthews
Sent: Thursday, July 05, 2007 3:33 PM
To: resiprocate-devel at list.resiprocate.org
Subject: [reSIProcate] rfc 3311 update in confirmed dialogs

 

Section 5.1 of 3311 states: "Although UPDATE can be used on confirmed

   dialogs, it is RECOMMENDED that a re-INVITE be used instead.".  

 

It looks like DUM will send an UPDATE in the connected state
(InviteSession::provideOffer).  Should DUM, by default, use UPDATE in early
dialogs and use re-INVITE for confirmed dialogs?

 

Thanks,

 

-Justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070705/85454159/attachment.htm>