ietf
[Top] [All Lists]

Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard

2017-03-21 14:52:19
Adam Roach <adam(_at_)nostrum(_dot_)com> writes:
To be clear (and this is an easy mistake to make, since the sections and 
their contained steps are huge), Pete is referring to the long-form 
version of step 6 in section 16.7 here. See RFC 3261, page 111.

Ah, there's a tension between this paragraph:

         The stateful proxy MUST choose the "best" final response among
         those received and stored in the response context.

and this one:

         3-6xx responses are delivered hop-by-hop.  When issuing a 3-6xx
         response, the element is effectively acting as a UAS, issuing
         its own response, usually based on the responses received from
         downstream elements.  An element SHOULD preserve the To tag
         when simply forwarding a 3-6xx response to a request that did
         not contain a To tag.

But if many implementations take "choose the best final response" to
mean only re-sending the response code, we have a problem.

OTOH, it's quite possible to reserve a *set* of 6xx response codes to
carry the decline-type.  The only allocated 6xx responses are 600
(generic), 603, 604, and 606.

Dale

<Prev in Thread] Current Thread [Next in Thread>