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

[Henning Schulzrinne <[e-mail]>]

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.

Jarno Rajahalme wrote:
> 
> 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.
>

_______________________________________________
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 
[e-mail] with "subscribe" in the body.