Re: [reSIProcate] rfc 3311 update in confirmed dialogs
My concern is with the vendors that either mistakenly add UPDATE in the
supported header or rarely use UPDATE for updating the sdp. I'm sure there
are other vendors, similar to me, that to date have only used re-INVITE.
There is always a chance of something not working when changing a behavior
like this.
Eventually we will test the waters when we can use reliable 183 messages to
modify sdp in early dialogs. The best solution for us then would be to only
use UPDATE in early dialogs, where supported. The added feature that the
reliable 183/UPDATE would bring would allow us to confirm UPDATE is a
hardened feature before replacing re-INVITE with UPDATE completely.
Overly cautious, yes, but not worth causing problems with customers IMHO.
-Justin
-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf Of
Jason Fischl
Sent: Thursday, July 05, 2007 9:22 PM
To: Justin Matthews
Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: 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
>