Subject: Re: [SIP] How to ping Prxoy Server ?

From: Sean Olson <[email-masked]>
Date: Tue, 20 Jun 2000 09:39:00 -0500 (CDT)

<snip>
> Is there 
> any method/way available in SIP using which status of proxy server can be known in advance ?.
>  This  information helps the UAC in keeping track current active list of default 
> proxy server(s).
> 

The OPTIONS method provides a very crude sort of ping for SIP.
Combined with the Max-Forwards: header, you can ping various nodes along 
a call signalling path. But this may still not give you the information
you desire; just because a proxy responds to an OPTIONS request, doesn't
mean it is capable of handling calls.

> Thank You
> Rafi Assadi H.M.
> Silicon Automation Sysytems
> Bangalore, INDIA
>  

--
Sean Olson <[email-masked]>

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Jun 2000 18:15:09 -0400

A UA could also cache the fact that there was a failure; next time it
tries to contact that host, it can continue using the backup address. I
will note that rfc2543bis does actually forbid this behavior, though:

From 1.4.2:

> A client MAY cache a successful DNS query result. A successful query is one which contained records
> in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes
> to send a request to the same host, it MUST start the search as if it had just received this answer from the
> name server. The client MUST follow the procedures in RFC1035 [16] regarding DNS cache invalidation
> when the DNS time-to-live expires.

I don't remember why we made it a MUST to start the search from
scratch.... Henning?

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Jun 2000 10:53:33 -0400

The paragraph you quote refers to caching *DNS* query results, not
whether the host was contacted or not. The idea here is just to make
sure that SRV load balancing is observed. I don't think the text says
anything about caching addresses, but it does have the potential
drawback of bypassing load balancing. Since caching is likely only to be
useful for large servers with lots of traffic, this could be a problem.
You don't want AOL to always go to the same Earthlink server.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 11:44:34 -0400

Henning Schulzrinne wrote:
> whether the host was contacted or not. 

The quote indirectly says you shouldn't cache whether the host was
contacted or not; it says you should start the search afresh when
contacting the same host. To me, this means you are not allowed to
remember that you previously reached the host at address X.

The idea here is just to make
> You don't want AOL to always go to the same Earthlink server.

The cache would need to honor DNS TTLs, as the paragraph says, so it
would eventually time out. Not caching means you may increase call setup
times waiting to fail against servers you have been failing against for
the last hour...

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Jun 2000 19:41:13 -0400

> remember that you previously reached the host at address X.

I have no (serious) problem with caching results of failed requests, but
the paragraph cited is simply silent on this issue. It is not clear to
me whether this implementation decision needs to be specified, since the
"bad server" avoidance policy can be as complex as "if this is a
first-priority server, retry with exponential back-off every 5, 10, 20
seconds; if it is a lower-priority server, retry with some other delay".
I don't think that the DNS time-out is necessarily the optimal choice,
since validity of name translations and likely downtime durations are
not inherently related.

Might be useful to see if the MX record RFC (and RFC 821/822) says
anything about this. I believe SMTP MTAs have fairly sophisticated retry
algorithms for failed servers, but I'm not sure if these are for a
single message or per server. (Due to aggregation, probably makes no
difference.)