Brett Tate wrote:
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Kyzivat
>> Sent: Thursday, November 15, 2007 9:24 AM
>> To: Amit Lobo
>> Cc: [email protected]
>> Subject: Re: [Sip-implementors] How to know active call
>> status,using SIP
>>
>> If I understand you the IPPBX is sitting in the middle of the
>> call, between the two endpoints and wants a way to verify
>> that the two endpoints continue to function. Right?
>>
>> If the IPPBX is a B2BUA then it may, at any time after the
>> call is established, send a request to either of the ends.
>> This could be OPTIONS, reINVITE, UPDATE, ...
>
> Since I haven't heard anyone recently mention using OPTIONS to check
> dialog/call state, what should be returned if the dialog does not exist?
> (I'm assuming you were indicating sending OPTIONS within the dialog.)
Yes, I was.
> RFC 3261 section 11.1: "An OPTIONS request received within a dialog
> generates a 200 (OK) response that is identical to one constructed
> outside a dialog and does not have any impact on the dialog."
>
> Based upon the above text, I wouldn't think a UAS is obligated to return
> a failure response when the dialog does not exist.
I guess it would be good to get Robert Sparks' opinion here.
IMO if the request has a to-tag, then it should be matched to an
existing dialog id. If there is none it should result in a 481 response.
But the receipt of the 481 cannot be tied to any particular dialog
usage. Technically it only affects the transaction itself.
However, the sender of the message might infer that this means there
aren't any usages and so decide it should give up on the call. But this
could be dangerous because there is so much confusion about these
behaviors. And receiving a 200 might not be conclusive evidence that
there is a functioning invite usage.
So in retrospect I take back any suggestion to use OPTIONS for this
purpose. To test an invite-usage you should use a message that is
associated with the invite usage: INVITE, UPDATE, (INFO?).
> Since rfc5057 reiterated that the 481 was an inappropriate OPTIONS
> response since OPTIONS does not belong to any usage,
I don't see anything in there that says it is an inappropriate response.
It only talks about what inference you can draw from receiving the
response. The tables say it should impact the *usage*, while the text
points out that it isn't associated with any usage, so that it won't be
affecting one.
> is there an RFC
> which recommends sending an OPTIONS response to release the dialog? And
> if so, which response is recommended? (RFC 5057 just mentions those that
> could be used and none seem applicable.)
I take it back. Sorry.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
