Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt

From: <[email-masked]>
Date: Mon, 3 Apr 2006 09:46:00 +0300

Hi !

I made up two proposals based on DNS for the UA to find
out proxies supporting outbound within the domain of SIP
AOR of the user or the domain got from DHCP:

1. Define a few new NAPTR service types for Outbound, 
something like:

   "SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U"

2. If the service resolved is e.g. "SIP-O+D2U" then the UA
could open a separate connection towards the preferred proxy
at each priority level of the SRV records for the service.

Later on I agreed that a separate I-D could be created:

> Anyway since the proposed DNS procedures would impact the
> contents of RFC 3263 (new service types) a separate draft
> could be a reasonable approach. 

I am now planning to put together an I-D for those proposals
as an update to RFC 3263. It may take some time, but hopefully
not too long. Please tell me if you have any serious comments
for those proposals, that I should take into account.

Regards,

Erkki

>-----Original Message-----
>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 01.April.2006 01:53
>To: Juha Heinanen
>Cc: [email-masked]; Niemi Aki (Nokia-NRC/Helsinki); Dean Willis
>Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt
>
>On 3/29/06 10:47 PM, "Juha Heinanen" <[email-masked]> wrote:
>
>> Cullen Jennings writes:
>> 
>>> As we agreed in the meeting, I would rather have these is separate
>>> documents since we can move forward with the what you do 
>with it now and
>>> solve the many possible way beyond configuration how you 
>might find it
>>> later. 
>> 
>> it is fine to have a separate document describing how SIP UA finds
>> outbound-proxy-set, but that separate document MUST be 
>referenced in the
>> outbound I-D in the same way as rfc3263 is referenced by 
>rfc3261.  there
>> is no point to publish a document where the only standards 
>based way to
>> configure outbound-proxy-set is manually, because no regular user is
>> able to do it correctly.
>
>I think you and I mean different things by the word 
>"configuration". I was
>not suggesting that end users would be typing several URIs into a phone
>using a 9 digit key pad - I completely agree with you that 
>this would never
>happen in any scaleable way.
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: <[email-masked]>
Date: Fri, 21 Apr 2006 14:34:27 +0300

Hi,

>AOR of the user or the domain got from DHCP ...
>
>not too long.

The promised I-D is now available:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Discovering Proxies Supporting SIP Outbound
	Author(s)	: E. Koivusalo
	Filename	: draft-koivusalo-sip-outbound-discovery-00.txt
	Pages		: 17
	Date		: 2006-4-20
	
   This document describes modifications to DNS procedures used to
   resolve a SIP Uniform Resource Identifier (URI) into the IP address,
   port, and transport protocol of the next hop to contact.  These
   modifications enable the SIP User Agent to discover those proxies,
   within the domain of the SIP URI, that support SIP extensions
   described in draft-ietf-sip-outbound document.  The introduced
   mechanisms update behavior defined in RFC 3263.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outbound-discove
ry-00.txt

I would appreciate for anyone interested to review this spec
and provide me with comments.

Regards,

Erkki

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 21 Apr 2006 17:46:36 +0300

erkki,

thanks for writing the i-d.  i have one comment.

in case SRV query returns more than one record with equal priority and
weight value,  i would suggest that server should then be selected
randomly.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 21 Apr 2006 18:53:25 +0300

i forgot to ask the list, why are outbound proxies classified as
primary and backup?  last time when i asked, no-one came up with a
justification.

i would like to get rid of that classification, because with it, one
would need four proxy hosts for load-balanced, resilient configuration,
when without, only two would suffice.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 21 Apr 2006 19:43:49 +0200

Erkki,

To me the draft too easily discards the "this is not scalable" argument. It 
really is not scalable, and stacking features on DNS like this feels wrong.

RFC2915 hints at an alternative approach in the description of the usage of 
the "U" flag: "[...] there may be applications that use NAPTR to also lookup 
aspects of URIs". You could use a regular expression including a flag that 
denotes outbound support.

Regards,

Jeroen

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 21, 2006 1:34 PM
Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

Hi,

Regards,

Erkki

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 21 Apr 2006 13:46:29 -0400

> weight value,  i would suggest that server should then be selected

I haven't read the I-D, but I'm fairly familiar with DNS SRV.  Isn't the
idea to pick one proxy of the lowest available priority?  In that case,
it seems like the right algorithm is to choose one randomly, weighted by
the weight values, as one would do during ordinary DNS SRV processing.

Actually, is there any reason to specify any of this behavior?  Once
NAPTR has found a DNS name to use, the processes for using DNS names are
already specified.

One nit:  In section 5, I see the phrase "as specified above, in the
description of Weight in "The format of the SRV RR" Section", but there
doesn't seem to be any such section.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 21 Apr 2006 20:53:37 +0300

Dale R. Worley writes:

 > idea to pick one proxy of the lowest available priority?  

sure, but my point related to the case, where there are more than one
proxy with the same priority.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 22 Apr 2006 11:02:23 +0200

Erkki,

Another possibility: http://www.dns-sd.org/ServiceTypes.html lists the 
following TXT keys defined for the "sip" service (amongst others):

sip             Session Initiation Protocol, signalling protocol for VoIP
                  registrar     SIP registrar (see RFC3261)
                  proxy         SIP proxy (see RFC3261)
                  natproxy      SIP proxy for NATed clients
                  outproxy      outbound SIP proxy (see RFC3261)
                  stunserver    STUN server DNS name or IP address
                [Further TXT record keys may be added in the future.]

We could define a new TXT record key, say "outbound", and return that along 
with the result of a SRV lookup. In other words: use DNS-SD 
(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) for the purpose 
of outbound proxy discovery

Regards,

jeroen

----- Original Message ----- 
From: "Jeroen van Bemmel" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, April 21, 2006 7:43 PM
Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

> Erkki,
>
> To me the draft too easily discards the "this is not scalable" argument. 
> It really is not scalable, and stacking features on DNS like this feels 
> wrong.
>
> RFC2915 hints at an alternative approach in the description of the usage 
> of the "U" flag: "[...] there may be applications that use NAPTR to also 
> lookup aspects of URIs". You could use a regular expression including a 
> flag that denotes outbound support.
>
> Regards,
>
> Jeroen
>
> Subject: RE: [Sip] I-D 
> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt
>
>
> Hi,
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 28 Apr 2006 10:44:00 -0500

So, two questions to the list:

1) Are we basically happy with this approach?

2) Do we need to include a reference to this in Outbound? If so, is  
an informative reference adequate?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 28 Apr 2006 18:58:48 +0300

> 1) Are we basically happy with this approach?

at least i'm happy.
 > an informative reference adequate?

no, the reference MUST be at the same level as rfc3261 references
rfc3263.  there is no difference.

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 28 Apr 2006 12:27:54 -0400

Hi Dean,
To your first question, I'm not sure what the final approach is for this
draft.  I saw some emails debating using more NAPTR records vs. SRV service
types.  I don't care either way, but whatever the chosen mechanism there
must be a way for a service provider to provide outbound support without
confusion about whether UAs will do the outbound primary/backup
load-balancing scheme, if the provider wants a real primary/backup
(non-load-balance) scheme.

Right now the terms are actually misleading.  They're not primary and
backup, they're primary and primary - both from a registration and session
signaling perspective.  That has real implications for how service providers
size systems, manage and troubleshoot.  DNS is the only way for a service
provider to control that, since the outbound draft leaves it all up to the
UA to decide.

So to your second question I would say it would be normative (IF the UA does
DNS discovery, then it MUST do it as in XYZ).

-hadriel

> From: Dean Willis [mailto:[email-masked]]
> Sent: Friday, April 28, 2006 11:44 AM
> To: SIP WG

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 28 Apr 2006 12:30:56 -0400

Hi Juha,
IMHO it's an editorial error.  They're not primary/backup, they're
primary/primary.
BTW, why does the terminology mistake make you need four proxies?
-hadriel

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Friday, April 21, 2006 11:53 AM
> To: [email-masked]; [email-masked]

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 28 Apr 2006 19:37:21 +0300

> BTW, why does the terminology mistake make you need four proxies?

if one is primary and one is backup, then ua would always use primary as
long as it is alive, i.e., backup would be on hot standby.  so if
operator wants to have load balancing, there must be at least two
primaries and perhaps also two backups organized in such a way that if
one primary goes down. also the other needs to be brought down, because
otherwise there would be no load balancing.  

if all proxies are the same, then operaor can add a new one to the set
and it automatically receives also some of the load.

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 28 Apr 2006 12:38:27 -0400

Hi Erkki,
I am confused by one thing (well, for this topic): why did you choose to use
the SRV priority in that way? You said "choose one of each priority level".
If I understand the outbound draft correctly, there is no real distinction
between primary and backups - any one of them can get new requests at any
time, and the UA registers to all.  So they're really all primaries once the
UA chooses to create a flow to them.  Thus I would think it more logical to
have a UA which supports outbound connect to all servers of the same and
lowest SRV priority if the server supported outbound, and only connect to
higher ones upon failure of lower ones.

That way a higher priority really means "connect if lower one fails", as it
did for SRV before outbound.  No?

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 21, 2006 7:34 AM
> To: [email-masked]

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 28 Apr 2006 13:12:25 -0400

But I think no matter what it will be the UA which decides which one to use
for active signaling.  Even if you call them both primaries, the UAs would
probably just use the first one configured/discovered/bound for signaling.
If you specify they must choose it randomly then you could just say that
about the primary and backup terms. (although I agree the terms would be
highly confusing, as they already are for me)

In some ways that's already going to happen - the draft does not say the UA
must use the "primary" for new outbound requests, and the registrar has no
idea which one the primary is, so new requests going to the UA will be
pseudo-randomly chosen. (if anything, it would probably use the most
recently bound one, which ironically means the backup will be the first
used)

-hadriel

> Sent: Friday, April 28, 2006 12:37 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; [email-masked]

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 28 Apr 2006 13:33:32 -0400

> highly confusing, as they already are for me)

I haven't been following the discussion closely, but --

If you are going to allow specifying a prioritization of (whatever they
are), you should copy the system that is used in DNS SRV records -- a
priority and weight is given for each.  Of the (whatever) that the UA
can contact, the UA uses only the ones with the lowest priority number,
and among them, distributes traffic proportionately to weight.  This
covers most popular primary/backup and load-balancing schemes in a way
that parallels the existing DNS SRV infrastructure (which is implicitly
inherited by the DNS NAPTR infrastructure).

Dale

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 28 Apr 2006 13:49:57 -0400

Yup, see another email I sent which I said that as well. (although not as
directly)
-hadriel

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Friday, April 28, 2006 1:34 PM
> To: Sip

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 28 Apr 2006 20:51:17 +0300

Dale R. Worley writes:

 > Of the (whatever) that the UA
 > and among them, distributes traffic proportionately to weight.

exactly.  this is all that is needed.

-- juha