Hi there, a) I am not sure about what the practical benefit of hop-by-hop methods like CANCEL or ACK (for 3XX-6XX responses) is.
b) Also, why is 100 Trying a hop-by-hop response? Would it hurt to have it being end-to-end? c) Why don't we have end-to-end messages only? For example, UA1 sends a CANCEL and a proxy immediately confirms with 200 OK and crashes. UA1 will never know that the CANCEL has not been delivered to destination UA2. If it were an end-to-end request, UA1 would realize that sending CANCEL to the proxy yields no result (because the proxy died and cannot forward the 200 OK from UA2 - which does not exist anyway because it never got there). The only reason for hop-to-hop messages I see is to reduce the complexity of forking. I.e. when a proxy forks an INVITE to four locations and three locations answer with a non-2XX response, the proxy can ACK them directly. Then the proxy "keeps silent about it" in face of the requesting UA because these answers are worthless for the UA. Forwarding all those answers back to the UA would generate useless traffic. If the fourth location responds with a 2XX-response, that would be a response worth forwarding (end-to-end). Yes, I know this is described in RFC 3261 as "selecting the best answer" - but is THIS the true reson we have hop-to-hop requests? "Just" because it yields an optimal way to handle forking? Any input on the practical benefit of hop-to-hop methods would be highly appreciated. Thanks in advance, Robert _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
