| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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] 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 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 |