You are missing the point. The issue is simply that a downstream entity wants to communicate that it can not accept the call because it is congested. This is not an an RFC 3263 issue. This a Layer-5 (SIP) issue. We need an L5 mechanism to communicate back to the proxy/UAC that an alternate route should be attempted.
On Mon, Mar 17, 2008 at 5:46 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote: > El Lunes, 17 de Marzo de 2008, Steve Langstaff escribió: > > > I was reading this from RFC 3263: > > > > Failure also occurs if the transaction layer times out without ever > > having received any response, provisional or final (i.e., timer B or > > timer F in RFC 3261 [1] fires). If a failure occurs, the client > > SHOULD create a new request, which is identical to the previous, but > > has a different value of the Via branch ID than the previous (and > > therefore constitutes a new SIP transaction). That request is sent > > to the next element in the list as specified by RFC 2782. > > > > Which says, to me, that transaction layer timeouts fire off a new > > request and... > > > > This from RFC 3261: > > > > 8.1.3.1 Transaction Layer Errors > > > > In some cases, the response returned by the transaction layer will > > not be a SIP message, but rather a transaction layer error. > > Maybe I'm wrong, but I understand that this "response returned by the > transaction layer" means the final response after trying all the IP's get via > DNS. > > > > When a > > timeout error is received from the transaction layer, it MUST be > > treated as if a 408 (Request Timeout) status code has been received. > > So, if an IP got via RFC3263 returned a SIP 408 (not socket/ICMP error) the > that is the definitive reply and for the client is means "can't connect with > destination". > > And if no one of all the IP's (RFC3263) returned a real SIP reply, then the > final response if a timeout, and the client behaviour should be the same as > if a final 408 reply was received. > > > > > > Which says, to me, that a 408 response and a transaction layer timeout > > must be treated the same. > > > > Maybe I made 2+2=5? > > In fact, I'm not sure at all of what I'm talking about XD > > -- > Iñaki Baz Castillo > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
