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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adam Roach <adam@xxxxxxxxxxx> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]