Re: [reSIProcate] rfc 3311 update in confirmed dialogs
We will only send an UPDATE if the peer lists it as supported in the
response to the INVITE. Do you think this is still a problem? We will
not send UPDATE if the peer doesn't list it as a required or supported
method.
On 7/5/07, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:
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@xxxxxxxxxxxx]
Sent: Thursday, July 05, 2007 4:21 PM
To: Justin Matthews;
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
Behalf Of Justin Matthews
Sent: Thursday, July 05, 2007 3:33 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel