Given the text in 3261 about responding to OPTIONS in the same manner as an
INVITE, it is reasonable to assume that a 481 to OPTIONS means that there is no
INVITE usage for the dialog. But that does not mean that there is no dialog at
all. There may be other usages that exist.
I would say that
Brett Tate wrote:
> If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent
> requests/responses to terminate the dialog, I'm sure some would like to
> use it within early dialogs, subscriptions, and elsewhere.
Whether 481 SHOULD/MUST be returned to the OPTIONS is one question.
Whether
Hi Robert,
Thanks for the response.
Within the archives, I found http://bugs.sipit.net/show_bug.cgi?id=400
which discusses OPTIONS within dialog.
Unfortunately I haven't found much concerning the topic within the old
email archives. Thus I'm not positive if all the objections to
returning 481 w
You got the question right.
And you got the right answer too. :-)
Thanks,
Paul
Robert Sparks wrote:
> So I've lost track of the question during the musing.
>
> I _think_ the fundamental question being asked is this:
>
> Is an endpoint required to reject (with a 481) an OPTIONS
So I've lost track of the question during the musing.
I _think_ the fundamental question being asked is this:
Is an endpoint required to reject (with a 481) an OPTIONS request that
arrives with at to-tag but does not match any existing dialog state.
(Assuming some earlier requirement hasn't f
[Including Robert in hopes of getting his insight on this.]
I certainly agree that receiving a 481 to an OPTIONS would not imply
that there is no INVITE-usage, or any other *particular* usage. It at
best would indicate that there is no *dialog*, and hence *no* usages of
that dialog can exist. I
> The ambiguous part has to do with whether
> an OPTIONS received with a dialog id should get
> a 481 response if the dialog doesn't exist.
Since OPTIONS defined within rfc2543 and rfc3261, many tried to get
OPTIONS approved (so workable if not actually desired) as a poor man's
dialog ping mecha
Brett,
The ambiguous part has to do with whether an OPTIONS received with a
dialog id should get a 481 response if the dialog doesn't exist.
I've always thought that dialog matching stuff was a "lower layer"
function before doing method-specific behavior, so that it would get the
481, and only
> > > Also in-dialog OPTIONS is used to verify the state
> > > of an existing dialog since the UAS is supposed to
> > > answer "200 OK" in case a dialog with that "To" tag exists.
> >
> > OPTIONS within a dialog is not a typical request within
> > dialog. It cannot be used to check dialog state
El Thursday 15 May 2008 16:01:44 Paul Kyzivat escribió:
> *If* it is known that the dialog only had a single usage (the normal
> case) then it provides *some* evidence of the continued existence of
> that usage. But it is in general impossible to know there was a single
> usage. For instance, a RE
Iñaki Baz Castillo wrote:
> El Thursday 15 May 2008 14:42:09 Brett Tate escribió:
>>> Also in-dialog OPTIONS is used to verify the state of an
>>> existing dialog since the UAS is supposed to answer "200 OK"
>>> in case a dialog with that "To" tag exists.
>> OPTIONS within a dialog is not a typic
El Thursday 15 May 2008 14:42:09 Brett Tate escribió:
> > Also in-dialog OPTIONS is used to verify the state of an
> > existing dialog since the UAS is supposed to answer "200 OK"
> > in case a dialog with that "To" tag exists.
>
> OPTIONS within a dialog is not a typical request within dialog. It
El Thursday 15 May 2008 14:42:09 Brett Tate escribió:
> > Also in-dialog OPTIONS is used to verify the state of an
> > existing dialog since the UAS is supposed to answer "200 OK"
> > in case a dialog with that "To" tag exists.
>
> OPTIONS within a dialog is not a typical request within dialog. It
> Also in-dialog OPTIONS is used to verify the state of an
> existing dialog since the UAS is supposed to answer "200 OK"
> in case a dialog with that "To" tag exists.
OPTIONS within a dialog is not a typical request within dialog. It cannot be
used to check dialog state. RFC 5057 section 5.
Hi Guys
Where i will get information about the Nortel in-house Hurricane tool,
Ameritec Crescendo/Fortissimo, Navtel
can anybody help me
Thanks in Advance
Regards
Jesi
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://li
Hi
Re-INVITE and UPDATE can be used to modify session parameters
A Re-INVTE can be sent only after establishing a session
Where as UPDATE can be sent in early dialog
-Regards Ramya
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Iñaki
Baz Castillo
Sen
hello friends,
we want to implement a SIP stack for voip ATA, we are new in this field as we
studied some specs about it, its mentioned in it SIP suppoting RFC
3261/62/63/64 specifications then whether the same support is required at other
end also for communication set up? or it mean somethin
El Thursday 15 May 2008 08:59:00 Robins George escribió:
> AFAIK
>
> the sip re-invite is used to make session alive.
> and re-invite is send by UAC/UAS(based on who sets the session refresh
> timer) when session refresh timer fires,
> which will happen before a session expires.
>
> the UPDATE meth
18 matches
Mail list logo
