Subject: RE: [SIP] failure of proxy

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 02:42:00 -0500

-----Original Message-----
>From: Samorezov Vladimir [mailto:[email-masked]]
>Sent: Saturday, November 04, 2000 4:42 AM
>To: [email-masked]
>Subject: [SIP] failure of proxy
>
>
>Hi, all!
>Could you help me in my SIPs study?
>If proxy forwards a SIP request, it add Via header with its address. This
ensures responses >take the same path as the requests. OK!
>If one proxy along the path is failure, what upstream proxy must do to
route responses?   
>Thank you!
>Samorezov Vladimir.

This question is well timed. I've been having lots of private discussions on
just this subject, and I think we've got the solutions all worked out. There
are two cases here. One is routing of responses, and the other of subsequent
requests.

Regarding responses. The specific case is when proxy P1 forwards a request
to P2, and before the response comes, P1 fails. How does P2 forward the
response? This is related to what gets inserted into the Via header, and its
relation to the received param. Now, the current text states that if the
senders address is wrong, the proxy inserts the received param. However, if
the sent-by field in the Via contains a hostname that resolves to an SRV
record with many IP addresses, what is the meaning of "wrong"? The question
came up on a previous thread a long time ago, and the answer I gave was that
you would insert the received param if the source IP address in the request
didn't match any of the servers listed in DNS. I beleive now that this is
not the right solution. Rather, if the Via header contains a sent-by value
thats a domain name, the next hop should always insert a received param with
the source IP address.

Why is that? To deal with failures. P2 would sent the response to the
address in the received param. If it fails, P2 can instead take the hostname
in the sent-by field, and look that up in DNS to find an alternate server to
forward the response to. THis way, we can route responses around failures,
but under normal operation, ensure responses get routed back to the actual
server which forwarded the request. 

The second case is routing of subsequent requests. Lets say we send an
initial INVITE, and proxy P1 and P2 record-route. Now, midway through the
call, the proxy P2 fails. The caller sends a BYE. This hits P1. It sees a
Route header in the request (pointing to P2), pops it, and tries to send it
there. As this contains an maddr for P2, the request fails. In this case, I
would argue that P1 should then try the SRV procedure once more on the host
portion of the request URI, using the next server in DNS.

For things to work consistently, the SRV lookup process should be based on
the pseudo-random number generator I suggested in a previous thread; thats
the one based on a hash of the Call-ID, amongst other things. This gives us
consistent operation for SRV records in general.

Now, an interesting thing to note here. Lets say in this failure case, it
was the called party that hung up. The proxy downstream from P2 (say, P3),
pops its top Route, and tries to forward it to P2. But, that maddr (pointing
to P2), generates an ICMP error. So, it looks up the host portion of the
request URI in DNS and tries the SRV process from there. I will note that
this will only succeed if, and only if, *THE REQUEST URI ALWAYS REFERS TO
THE RESOUCE FOR WHOM THE REQUEST IS DESTINED*. Now, this relates to a
previous thread. The issue there was how a UAS would construct the Route
headers, and whether we should maintain this property that the R-URI always
refers to the entity for whom the request is targeted. I originally felt
this was critical, and was coming close to backing down. Now, it seems we
have another case to back up my original claim that maintaining this
property is important.

I'll make sure verbiage gets added to the spec on these failure handling
cases.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: James Undery <[email-masked]>
Date: Wed, 08 Nov 2000 11:02:04 +0000

> consistent operation for SRV records in general.

As I replied in a previous thread (with a bad example) this hash based method
gives us nothing in general it only works if you locally cache DNS for the life
time of a transaction, for each transaction (hence truly stateless proxy servers
do not work ;^) ). The reason for this is simple  for the hash method to work
the result from the DNS query MUST be identical even in ordering of the RRs each
time. As an example of why this may not happen I'll admit my short comings, the
first time I implemented SRV lookups I was lazy I found the lowest priority RRs
and picked the first one. If I was writing a DNS server I may expect other
people to do this, and in a more thorough moment may decide to shuffle the
results my server returned for SRV records (this wouldn't provide the same level
of load balancing but could help).

Also it's possible the zone file might have changed.

If you are going to suggest this hashing proposal I'd also think about sorting
the results of SRV lookups, although zone file changes will still break it.

James Undery