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