Subject: A Question about SIP

From: [email-masked]
Date: Thu, 23 Jul 98 20:47:17 +0900

Dear Authors of SIP,

I am an engineer at Iwatsu Electric, PBX manufacturer in Japan.

When I read SIP filed as draft-ietp-mmusic-sip-07c.ps, I have a question about
message redirection.

Before asking my question its assumptions need to be explained.

The environment:
1. There is a domain that has a firewall.
2. All IP packets to the domain are supposed to go through the firewall.
3. The firewall has SIP proxy so that the proxy processes all SIP packets in addition
to IP packets conveying voice.
4. There is a secondary firewall especially for SIP, because voice over IP is very CPU intensive.
    Role for the secondary firewall is that if main SIP proxy becomes overloaded, the secondary
  SIP proxy in the secondary firewall takes successive calls for avoiding them to be failed.

Question:
In this environment I think of 3 ways to redirect the calls to the secondary SIP proxy.

1. Register 2 firewalls to DNS.
   A caller client could find out available SIP proxy based on the preference values of DNS resource records.
  But ICMP does not say "Port Unreachable" for the main firewall.
  So I do not know how the client knows the main SIP proxy is busy.
  This method is based on description on page 11.

2. Use 302 Moved temporally message for the response of INVITE message.
  The client surely knows which proxy can guide it to the callee.
  However I think this is not adequate because the callee is not moved in this case. I just want
to have the client use the secondary proxy.
  This method is based on description on page 13.

3. Use 503 Service Unavailable message with alternative server address for the response of INVITE message.
  I think the meaning of the response is correct but I do not know the 503 can convey Location header.
  If it can convey the header, does that mean there is an alternative server you can try ?
  This method is based on description on page 52.

Please let me know which one is correct way to do this.
Am I missing something ?

Thanks in advance.
Best Regards,

Hiroaki Takagi.

+---------------------------------------------+
 Hiroaki Takagi
 Iwatsu Electric Co., Ltd.
 Software Development Dept.

 Address: 7-41, Kugayama 1-Chome Suginami-ku, 
          Tokyo, Japan
 Phone:  +81-3-5370-5239 FAX:+81-3-5370-5193
 Email:  [email-masked]
+---------------------------------------------+

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Jul 1998 10:07:35 -0400

[email-masked] wrote:

>   This method is based on description on page 11.

I think a better way to do load sharing here would be to set the SRV
records to have equal preference, and rely on round robining from the
DNS server to (roughly) distribute the load equally across both proxies.
This won't work as an overload mechanism, of course. Even in light loads
both servers will get half the requests.

>   This method is based on description on page 13.

I think this works fine. The fact that the callee has not actually moved
seems irrelevant. You could just use a different reason phrase if you
like, such as "Alternate Server".

>   This method is based on description on page 52.

I don't think this is the right approach, as the intention with this
response is that you should recontact the same server later on.

> Please let me know which one is correct way to do this.

There is no one right answer. Usage of a 300 response code or DNS work
fine. As an additional alternative, you could just proxy the request
from the busy server to the secondary server. This way, the usage of the
extra server is hidden from the caller (unlike the 300 case).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Jul 1998 10:09:59 -0400

>   This method is based on description on page 11.

It could return a status message '503 Service unavailable'. A smart
client would then choose the next on the list. (We haven't done this,
but I wonder if we should allow a Location field indicating an alternate
server in this case?)

>   This method is based on description on page 13.

This would still work: Let's say we have proxy servers proxy1.foo.com
and proxy2.foo.com, with a call (To and Request-URI) of
[email-masked]:

INVITE sip:[email-masked] SIP/2.0
To: [email-masked]
From: [email-masked]

Proxy2.foo.com returns 302, with Location: @proxy2.foo.com. According to
the rewrite rules, the Location header becomes the Request-URI (and the
destination for the next request), while the To and From fields remain
unchanged. Thus, proxy2.foo.com will get an INVITE with

INVITE sip:@proxy2.foo.com SIP/2.0
To: [email-masked]
From: [email-masked]
...

and should be able to do the right thing. (Maybe the rule for outgoing
proxies should be something like: If request-URI is yourself, check
user-id and use it for forwarding. If no user-id, use To. If other
domain, use Request-URI for forwarding. The latter rule is necessary to
avoid loops. Consider the following example:

INVITE sip:[email-masked]
To: sip:[email-masked]
From: sip:[email-masked]

getting redirected (during Alice's vacation) to 

302 Moved temporarily
Location: sip:[email-masked] (Alice's vacation substitute)

which would trigger according to standard rules:

INVITE sip:[email-masked]
To: sip:[email-masked] (so that Bob knows he's answering a call really
meant for Alice)
From: sip:[email-masked]

If you continue to forward based on the To: header (i.e., Alice), you'd
get a loop, with no escape.)

>   This method is based on description on page 52.

See above.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs