Subject: [SIP] DHCP option for SIP vs. for all SRV types in general

From: Jarno Rajahalme <[email-masked]>
Date: Mon, 19 Mar 2001 15:31:27 -0800 (PST)

Hi,

In the DHC meeting today I proposed defining a generic SRV DHC option,
rather than separate DHC option for all services using DNS SRV records.
In my opinion this would save a lot of work in future with new
protocols, as there would not be any need to define new DHC options.

In
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt
the SIP DHC option is proposed. It is defined as simply:

<option code> <length> <string>

Where string can be e.g. 'server.example.com'.

RFC 2782 defines the DNS SRV resource records.

A more generalized solution would be to define the option code for SRV
('SRV' for now), and include the service and protocol with the domain
name, for example:

<SRV> <n> <_sip._udp.server.example.com>

Note that the string is exactly the string to be used with the DNS SRV
query. The server could be configured with an arbitrary number of these
options and return multiple of these to the client.

The client could ask for these with the same option, but including a
matching prefix, e.g.:

<SRV> <n> <_sip>    ; want all SIP SRV entries

or

<SRV> <n> <_sip._sctp> ; want all SIP SRV entries with SCTP transport

or simply

<SRV> <n> <>    ; want all SRV entries

Additionally, the client could include multiple of these options, for
example to ask for SIP and HTTP proxies, but not for anything else:

<SRV> <n> <_sip._sctp> ; want all SIP SRV entries with SCTP transport
<SRV> <n> <_http>      ; want all HTTP proxy entries

In my opinion this solution would be as simple as the SIP-only DHC, but
more generic, and would help other services to benefit from the same
DHC option without any adverse effect to clients or servers.

With regards,

     Jarno Rajahalme

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Mar 2001 18:56:54 -0800

We've kind of been there before, many iterations of the SIP-DHCP
proposal ago. There are two problems that I can see:

- DHCP allows clients to request specific option numbers, but has no
other means of selecting which instances it wants (as far as I know);
thus, it would always have to retrieve all SRV options.

- SIP systems generally need both UDP and TCP SRV options, and possibly
others (SCTP) in the future. Again, this makes it likely that the client
would just have to get the whole set.

Whether this is a problem depends on what number of SRV records we
anticipate.

In addition, this does not work well if the SIP server does not have an
SRV entry. (While I would like all of them to have one, this is often
not the case today.) Thus, this wouldn't quite satisfy the SIP
operational requirements.