To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=91012
User hi changed the following:
What |Old value |New value
================================================================================
Status|VERIFIED |CLOSED
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Wed Sep 10 14:23:36 +0000
2008 -------
.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mailthod but not another.
- A B2BUA may only support an option if the device on the other
side also supports it. The device on the other side can change
over time.
> *So, for inter-operatablity reasons, should all the application have
> same options in Require and Supported header or not?*
I think, *when you can*, you should list all the options you support all
the time.
> *Secondly, *I had discussed the scope of options mentioned in
> Require/Supported header, in an earlier debate regarding this (whether
> it applies to a transaction/dialog) in this mailing list long back. As
> per my understanding, from RFC3261 the scope of Require/Supported header
> seems to be a transaction only. If we go by this assumption, once
> session in established using 100rel and precondition (as per 3gpp
> call-flow), a re-INVITE request can be sent without both these options
> (if for example the UAC realizes that no QoS establishment would be
> required).
> However, I got a feeling that most of the implementions go by the
> assumption that Require/Supported extension apply through out the dialog.
This is an area that needs some clarification. Some people think the
scope of Supported/Require is a transaction, some a dialog, some for as
long as not changed, ... There is no great clarity on this in the specs.
Its more a matter of observation based on what behavior is called for in
various specs defining options.
> Can you let me know in your opinion, what is the general consensus on
> this. *Are most SIP implementations prepared to handle change in
> Require/Supported options in re-INVITE request (They ofcourse can still
> reject such a re-INVITE by sending 420 Bad Extension/421 Extension
> Required)?*
I don't have data on this. Maybe there is some from SIPit.
Note: this isn't really just about Require/Supported. There are other
headers with similar issues:
Accept, Accept_Encoding, Accept-Language, Allow
Thanks,
Paul
> Regards,
> Vineet.
>
>
> On Tue, Sep 9, 2008 at 9:38 PM, Paul Kyzivat <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
>
> Vineet Gupta wrote:
>
> Hi,
> I have a small doubt related to use of Supported and Require
> header. While from RFC 3261 it is clear the Require header is
> used by the UAC and UAS to enforce the extension implemention
> for a particular session, while the Supported header is mostly
> used by UAC to express the extensions which can be enforced by
> UAS through the Require header.
> My doubt is that, is it *mandatary that every extension that is
> present in Require header must be present in Supported header
> *in the request? According to me, presence/absence of Required
> extensions in Supported header does not make any impact on UAS
> handling. *Even if it is not mandatory, what is the preferred
> approach?*
>
>
> This is pretty loosely defined.
>
> For one thing, Require doesn't necessarily apply to a "particular
> session". The most that can be said with certainty is that is
> applies to a transaction. Often it applies longer, but how long
> isn't well defined.
>
> Second, there is some asymmetry in Supported/Require, but this
> varies based on the option. Require from a UAC states what it
> requires of the UAS, but doesn't necessarily imply that a Require
> for the same option, coming the other way, would be supported.
>
> Also, Supported and Require are often used together to do a negotiation:
> Supported in a request is paired with Require of the same option in
> the response to negotiate its use.
>
> In most cases there is no requirement to include Supported in
> requests. The main place it is essential is in a 420 response.
>
> Thanks,
> Paul
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
