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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 24 Mar 2006 08:35:27 +0100

Hi,

I DID read your previous mail.

But, are you going to do the DNS lookup based on the AoR value of the
terminal (the value you normally put in the From header)? What if there
are different outbound proxies depending on the destination? What is the
outbound proxy belongs to another operator/domain (i.e. another "host
part")?

And, would you use some kind of dedicated private DNS for this?

Regards,

Christer

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 24. maaliskuuta 2006 9:26
To: Christer Holmberg (JO/LMF)
Cc: [email-masked]
Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt 

Christer Holmberg (JO/LMF) writes:

 > Now, if you want to use DNS, what are you going to do your DNS lookup
> on?

you didn't obviously read my earlier message on this.  in that i said,
that it must be enough to configure three thing in the UA:  username,
password and AoR.  the lookup of outbound-proxy-set is done based on
host part of AoR.

-- juha

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Fri, 24 Mar 2006 10:03:41 +0200

Christer Holmberg (JO/LMF) writes:

 > are different outbound proxies depending on the destination? 

i don't understand how register requests would have many destinations.

what comes to other (initial) requests, the default would be that the UA
sends them to the proxies in THE outbound-proxy-set (if specified).  if
your world is more complex, you can always provide any kind of other
(manual) configuration possibilities.

so what i'm trying to say that ietf must define DNS based
auto-configuration of outbound-proxy-set for the COMMON case, where
there is a single outbound-proxy-set that is used for all destinations.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 24 Mar 2006 15:32:11 +0200

[email-masked] writes:

thanks for your constructive email.

 > - Specify in the Outbound I-D that it would be possible to use
 >   multiple SRV records simultaneously, unlike RFC 2782 states.
 >   Similar handling could possibly be defined for DHCP SIP server
 >   option.

if it is allowed to append the tags to SRV result, then we might be able
to say that if some specific tag is associated with hostname of proxy,
then the proxy is an outbound proxy according to Outbound-ID.  otherwise
the proxies do not play Outbound game.  for example, there could be a
tag specifying is the proxy belongs to primary or secondary outbound
set.

 > - Specify a way to derive from the host part of AOR two different
 >   names to resolve with DNS e.g. using a predefined prefix or postfix
 >   to the original domain name to indicate SRV entries for backup
 >   servers.

this would also be possible, but it would be better to get everything
with a single query.  there may still be problem with the tags.

 > - Rely only to explicit configuration of those proxies e.g. with
 >   configuration framework. I do not like this option too much as
 >   it would cause extra trouble in deployment. Further it would 
 >   rely on a standard mechanism that is just not yet available 
 >   (or on a proprietary mechanism instead).

not good as you say yourself.

-- juha

---

From: <[email-masked]>
Date: Fri, 24 Mar 2006 15:14:58 +0200

Hi !

My 2 cents:

>outbound version 03 still doesn't address auto-discovery of the
>outbound-proxy-set.

>it must be enough to configure three thing in the UA:  username,

>there is a single outbound-proxy-set that is used for all destinations.

I must say Juha's request makes very much sense to me. This far
it has been possible to discover the outbound proxy by either DNS
SRV lookup base on the host part of the AOR or e.g. by using the
SIP server option of DHCP, to support the mobility case if the
IP connectivity to the proxy server of home domain is not enough.

>I don't think we can assume that the outbound proxy and the registrar
>are the same thing, or that they are located in the same domain/AoR.

Not in all cases, but I do not agree we should give up on creating
a solution that would support a very common case (proxies in the home
domain) just because it would be difficult to create one solution
that would support all possible scenarios / setups. We might well
have different mechanisms for different cases. Juha's use case could
be supported by DNS SRV query while DHCP could be used for finding
local proxies, if that is for some reason preferred.

While outbound promotes ways for using multiple connections towards
multiple proxies it does not yet address the problem of discovering
those proxies in a satisfactory way:

   The deployment here requires
   that DNS is configured with one entry that resolves to all the
   primary hosts and another entry that resolves to all the backup
   hosts.  Designs having only one set were also considered, but in this
   case there would have to be some way to ensure that the two
   connection did not accidentally resolve to the same host.  Various
   approaches for this are possible but all probably require extensions
   to the SIP protocol so they were not included in this specification.

Even if there could be two entries in the DNS for resolving primary
hosts and backup hosts, there is no hint given how the UA could find
or identify those two entries. Using the host part of the AOR according
to RFC 3263 leads the UA to possibly find multiple SRV records. However
according to RFC 2782 procedures only the preferred one (that responds)
should be selected and used.

So how to find those multiple proxies then ?

Any comments or better ideas ?

Regards,

Erkki

---

From: Fredrik Thulin <[email-masked]>
Date: Fri, 24 Mar 2006 16:06:06 +0100

On Friday 24 March 2006 14:14, [email-masked] wrote:
...
>   to the original domain name to indicate SRV entries for backup

I think this is the way to go for Outbound. The thing is that you might 
very well want clients in your domain to connect to different SIP 
servers than you want other domains trying to reach your users to 
connect to.

A real life example : I want people trying to reach my users to look up 
NAPTR/SRV for 'it.su.se' (naturally) but I want my clients to use other 
servers, currently indicated by NAPTR/SRV records for 'out.sip.su.se' 
because these other servers do stuff like Outbound, which the 
'it.su.se' servers does not.

/Fredrik

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 24 Mar 2006 10:16:32 -0500

It seems quite reasonable to me to discuss means by which a UA can
discover the outbound proxy it needs to contact its registrar,
especially in the context of an RFC regarding how to manage connections
out through such a proxy.

(Though in my experience, the bulk of SIP UAs are used in the internal
phone systems of organizations, and the "outbound" connection that is
troublesome is the "outgoing trunk" from the PBX registrar/proxy to the
rest of the world; communication between the UAs and the registrar/proxy
is usually open.)

But finding an outbound proxy seems to be inherently dependent on the
location of the UA -- If there was one single outbound proxy with a
globally reachable address that all UAs attempting to register for a
domain could contact, one would point the DNS SRV record for the domain
to that address.  So whatever mechanism is used to discover the outbound
proxy must return different answers to different requesters.

In practice, isn't the "outbound proxy" discovered implicitly by the
routing outward through the NATs of a packet addressed to the registrar
for the domain?  And the problem that needs addressing is how the UA can
become aware of these NATs and interact with them so as to allow
successful incoming communication?

Indeed, having used SIP phones both internally to an organization and
having a phone at my home connect out through a NAT to register with the
SBC that is the DNS SRV address for the organization's domain on the
public Internet, I've never had to configure an outgoing proxy.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 24 Mar 2006 17:40:22 +0200

> public Internet, I've never had to configure an outgoing proxy.

yes, and now we want the same ease to discover Outbound I-D outbound
proxies (and to automatically find out if outbound proxies really are
implementing Outbound I-D).

-- juha

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 29 Mar 2006 15:29:52 +0200

> 'it.su.se' servers does not.

This is a perfect example of the needs of current SIP installations. 
Probably a SIP service provider want to host different task on different 
machines, e.g:

- A: one (or more) SIP proxy for signaling to other domains (which does 
TLS, SPIT detection ...)

- B: one (or more) registrars/main proxy (which do client 
authentication, routing ...)

- C: one (or more) proxies which perform NAT traversal (outbound/edge proxy)

Thus, the same SIP AoR should resolve to different servers. E.g. 
sip:[email-masked] should resolve to proxies A if [email-masked] 
(external domain) calls me. On the other hand, my SIP client, which is 
also configured with sip:[email-masked] should automatically resolve 
to proxies C.

Taking a look at current implementations, some solve this proprietary. 
E.g. xlite utilizes SRV lookups for _outboundsip._udp.mydomain.com to 
detect the outbound proxies. Another example is Microsoft's LCS and the 
Live Communicator. The Live Communicator uses SRV lookups with 
_sipinternal._udp.mydomain.com to find the registrar whereas the LCS 
uses _sip.... to find other proxies.

We need a mechanism for detecting the respective SIP proxy. From 
personal experiences, and the above examples prove that there is need 
for addressing different SIP proxies depending on the tasks.

Using different SRV prefixes is one method. But it does not allow 
different transport preferences using NAPTR records for different proxy 
servers (e.g. if proxies A prefer TLS but proxies C prefer TCP).

Of course these problems can be solved by complex configurations in the 
client. But here I have to second Juha: Configuring of a SIP client 
should only require AoR, username and password.

regards
Klaus

---

From: iPekka Pessi <[email-masked]>
Date: Thu, 30 Mar 2006 17:39:26 +0300

Erkki,

"[email-masked]" <[email-masked]> writes:

Someone eats From line containing your nokia.com email.

>  Similar handling could possibly be defined for DHCP SIP server

Use multiple NAPTR records? ;-o

>Any comments or better ideas ?

As Aki said, use 3XX. If the route header in REGISTER does not
contain proper URI, the outbound proxy could respond with, say,
305 listing the alternatives. Likewise, the registrar/home proxy
could respond with 300 listing alternative registrars, and also
return appropriate Service-Route in 2XX response.

So, if we have Alice [email-masked] visiting vn.fi:

A->O REGISTER sip:hn.fi SIP/2.0 
     To: [email-masked]
     Contact: sip:invalid.;reg-id=1;+sip.instance=
        "<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     Supported: path
     Route: <sip:out.vn.fi;lr>

O->A SIP/2.0 310 Use Outbound Proxies
     Contact: <sip:ob1.vn.fi;lr>, <sip:ob2.vn.fi;lr>

A->O REGISTER sip:hn.fi SIP/2.0 
     To: [email-masked]
     Contact: sip:invalid.;reg-id=1;+sip.instance=
        "<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     Supported: path
     Route: <sip:ob1.vn.fi;lr>

Outbound proxy adds flow label to Path header:

O->H REGISTER sip:hn.fi SIP/2.0 
     To: [email-masked]
     Contact: sip:invalid.;reg-id=1;+sip.instance=
        "<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     Require: path
     Path: <sip:[email-masked];lr;keepalive=stun>

H->O SIP/2.0 311 Alternative registrars
     Supported: path, outbound, gruu, pref
     Contact: <sip:out1.hn.fi;lr>, <sip:out2.hn.fi;lr>, 
         <sip:out3.hn.fi;lr>

...

A->O REGISTER sip:out1.hn.fi SIP/2.0 
     To: [email-masked]
     Contact: sip:invalid.;reg-id=1;+sip.instance=
        "<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     Supported: path
     Route: <sip:ob1.vn.fi;lr>

O->H REGISTER sip:hn.fi SIP/2.0 
     To: [email-masked]
     Contact: sip:invalid.;reg-id=1;+sip.instance=
        "<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     Require: path
     Path: <sip:[email-masked];lr;keepalive=stun>

H->O SIP/2.0 200 OK
     To: [email-masked]
     Contact: sip:invalid.;reg-id=1;+sip.instance=
        "<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     Supported: path, outbound, pref
     Path: <sip:[email-masked];lr;keepalive=stun>
     Service-Route:<sip:[email-masked];lr;keepalive=stun>,
        <sip:[email-masked];lr;keepalive=stun>,

...followed by registrations via ob2.vn.fi to out2.hn.fi and 
via ob1.vn.fi to out3.hn.fi.

OK. Weaknesses and open issues:

- munging with route set is underdefined:
  what part of routes set the 3XX response replaces?

- if we have N alternative outbound proxies and M registrars, how
  to combine them?

- how to convert Path to Service-Route?

Hm. Perhaps DNS is better, after all.

--Pekka