More about congestion

D. Willis and B. Campbell in “Session Initiation Protocol Extension to Assure Congestion Safety”, (expired) Internet-Draft, October 13, 2003 examine:

UAC may require that any proxy processing its requests must transmit those requests over a transport protocol providing congestion management
- with a "Proxy-Require: congestion-management" header field
In turn the UAS receiving these requests can be required to respond in similar fashion
If a proxy finds that it has no route supporting congestion management it may reject the request with a 514 response (“No available route with congestion management”)
If the request would be fragmented, the proxy can reject it with a 516 response ("Proxying of request would induce fragmentation")
If the originating request did not require congestion-managed transport, then a UAS may reject a request that would result in a response that requires congestion-managed transport.

Slide Notes

Willis and B. Campbell, Session Initiation Protocol Extension to Assure Congestion Safety, Internet-Draft, October 13, 2003, Expired: April 12, 2004, draft-ietf-sip-congestsafe-02, http://tools.ietf.org/html/draft-ietf-sip-congestsafe-02

Transcript

[slide475] So, what could we do? Well, in Willis and Campbell's expired draft, they talk about the fact that the UAC can ask its proxies for information. What's the advantage of asking the proxies? Well, you ask your nearby proxies, and they can gather information from other sessions that are taking place, and if things are improving, or good, then say, hey, now's a good time to resume. If the statistics look bad, adding another session to it isn't going to make it better. So, if the proxy finds no route supporting congestion management, [it] can reject the request, etc.