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.
Sent: Thursday, May 15, 2008 1:20 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Reg. SIP reinvite, UPDATE and OPTIONS
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
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
Sent: Thursday, May 15, 2008 2:45 PM
Subject: [Sip-implementors] Reg. SIP reinvite, UPDATE and OPTIONS
Hi all,
Can anyone tell me the exact difference between the SIP- reinvite, UPDATE
method and OPTIONS method? And the situations where each method is used and
preferable over the other
Hi all,
Can anyone tell me the exact difference between the SIP- reinvite, UPDATE
method and OPTIONS method? And the situations where each method is used and
preferable over the other methods?
Thank You,
Padmaja
___
Sip-implementors mailing list
Sip-imp
15 matches
Mail list logo
