> From: Ravindranath Gummadidala > > I am trying to understand how "forking" works. Say the proxy receives > the INVITE from user 1 and after querying the location > service gets back > 5 contact > address (all with same weight/priority). It decides to fork > the INVITE > creating 5 branches. From RFC3261, it appears that the proxy > maintains a > response > context for the forked INVITE and when it gets a response from any > branch, it uses some logic to determine whether to install > this response > in the response > context (which can hold only one response). After some time, it sends > the response stored in the response context (terminating the server > transaction; and > sending CANCEL's on all branches from which no response has yet been > received). My question is: how does the proxy know how long > to wait before > sending a response back to originator?
In RFC 3261, see section 16.6 item 11, section 16.7 item 2, and section 16.8 in regard to "Timer C". > How does proxy know > what logic to > use to pick a response? Say on one branch the INVITE yields some 4xx > response and on another branch it gets a 5xx response. How does proxy > pick one of these responses? See section 16.7 item 6. > Also lets say on one of the branches the > UAS rings > for a while and then callee answers generating a 200OK but > say the proxy > has already seen some failure final response from other > branches. If this > 200OK arrives at the proxy after the proxy has decided its > time to send > the best response seen thus far back to originator, then > there is no server > transaction at proxy anymore hence what does proxy do with > this 200OK? The proxy sends it upstream in a stateless manner. See the first two paragraphs of section 16.7. > Another question, say I get a INVITE and I am the proxy > server for the > domain serving the callee. I consult location service, find no match. > Should > I send 404 (not found) or 604 (does not exist anywhere)? You should send a 404. Because the request URI that you received might be from one fork of the original request URI. A 604 means that there are no contacts for the *original* request URI, but you have no way of knowing that, as you do not necessarily receive the original request URI. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
