IMO the requirement that OPTIONS be answered as an INVITE would be is
bogus historical baggage. For one thing, it ignores devices that don't
handle INVITE at all.
It makes reasonable sense to respond with the basic device capabilities
that would be taken into account when handling an INVITE - what options
are supported, what codecs, etc. But responding busy or not depending on
whether an INVITE would is probably carrying things too far. We could
take a survey - I bet not many UAs do that.
Thanks,
Paul
Patrick Cadogan wrote:
> As per Section 11.2 (Processing of OPTIONS Request) in RFC 3261:
>
> "The response code chosen MUST be the same that would have been chosen
> had
> the request been an INVITE."
>
> Following this rule is okay if the device receiving the OPTIONS request in a
> SIP device such as a UA but what should happen when a SIP gateway (to a PSTN
> or ISDN network for example) receives an OPTIONS request. If the gateway
> cannot determine the readiness of a PSTN or ISDN end-user to accept a call
> as defined in the OPTIONS request without initiating a call to the PSTN or
> ISDN end-user how can it respond to the OPTIONS request as if it had been an
> INVITE?
>
> Currently my implementation will automatically respond to any OPTIONS
> request with a 200 OK response and but this does not guarantee that an
> INVITE request with the same parameters as the OPTIONS will generate the
> same response.
>
> I will probably modify my implementation so that the OPTIONS request is
> examined in greater detail and an appropriate response is given based on
> that but I don't think I can reply to any OPTIONS request with a knowledge
> of how the PSTN or ISDN end-user would reply it had it been an SETUP message
> (translated from the INVITE request).
>
>
> [EMAIL PROTECTED]
>
>
>
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
