Hi Robert, On 09/13/2010 07:19 PM, Robert Hoffmann wrote:
> 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? It seems to me that the logical purpose of hop-by-hop replies or request methods is to elicit acknowledgment or communicate receipt from all network elements in the signaling path, regardless of whether they are proxies or UAs, in situations in which that information is desirable to know from the point of view of semantics and the state machine. So, for example, the standard envisions that it is useful to know that a proxy has itself received and processed a negative reply, even if the issuing UAC has gone away or something like that. Hop-by-hop CANCEL is more or less a mandatory requirement of forking, as you mentioned, since in many cases the proxy is the conceptual target of the CANCEL request because the transaction is being presented to UAC opaquely as a single branch, while there are lots of branches on the other side to the management of which a CANCEL must be applied/translated. The 100 Trying response exists mainly to dampen retransmissions by telling the UAC that the request has been received and is being worked on. Sometimes, there are unpredictable sources of latency that arise at this stage of call setup if a proxy is involved, as, for example, due to: - High database load / response time. - High end-to-end network latency physically. - Additional latency involved in serial forking through successively failing branches (common in wholesale PSTN routing scenarios). Any one of these or other causes can cause Timer T1 to throw before an upstream 100 Trying from a UAS is received and forwarded, and cause undesirable retransmissions or premature failover. So, 100 Trying is a way of telling the UAC, "All right, I got your request, now just be patient and wait, because there might be some latent operations involved before I can give you any other provisional or final replies." -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
