Subject: [sipcore] Source address selection in SIP

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 6 Nov 2016 10:18:07 +0100

Hi!

Paul and I had a conversation about source address selection in SIP on the SIP Forum IPv6 list that I wanted to move here.

An IPv6 interface by default has multiple addresses. Today’s computers also quite frequently have multiple interfaces.
A modern SIP stack has many IP addresses to select from.

In many cases applications let the operating system handle address election and set the IP packets sender IP address to the
one that matches the interface and the selected destination address (by using DNS as an example).

In SIP we have multiple addresses in the SIP message. Much can be simplified by using fqdn in the messages
and a GRUU with a SIP domain in the contact. In fact most of the examples in RFC 3261 use FQDNs.

But it’s not how SIP is implemented out there in the wild…

I tried to find any words in RFC 3261 or RFC 3263 about selection of interfaces and addresses but found nothing.
Having said that, it’s not easy so if anyone on sipcore can point me to the right section I will be grateful.

If not, I think we may need a clarification on Transaction layer handling of IP address selection in
the SIP protocol. Given a specific target, how do we handle multiple interfaces and multiple addresses
per interface - which address do we put in the SIP messages - like in via’s, record-route, SDPs and contacts.

We have been testing at SIPit with multiple ULAs attached to a network and a proxy on one of the ULAs.
No one could connect to that proxy properly (sadly for me not even Kamailio itself, which brags about having
IPv6 support from day one).

IPv6 source address selection is covered here:
https://tools.ietf.org/html/rfc6724

Quoting RFC 6724:

"The IPv6 addressing architecture [RFC4291] allows multiple unicast
   addresses to be assigned to interfaces.  These addresses might have
   different reachability scopes (link-local, site-local, or global).
   These addresses might also be "preferred" or "deprecated" [RFC4862].
   Privacy considerations have introduced the concepts of "public
   addresses" and "temporary addresses" [RFC4941].  The mobility
   architecture introduces "home addresses" and "care-of addresses"
   [RFC6275].  In addition, multi-homing situations will result in more
   addresses per node.  For example, a node might have multiple
   interfaces, some of them tunnels or virtual interfaces, or a site
   might have multiple ISP attachments with a global prefix per ISP.

   The end result is that IPv6 implementations will very often be faced
   with multiple possible source and destination addresses when
   initiating communication.  It is desirable to have default
   algorithms, common across all implementations, for selecting source
   and destination addresses so that developers and administrators can
   reason about and predict the behavior of their systems.”

Executive question summary: Does the current set of SIP standards cover IP address
selection for the *sender* when we have multiple IP interfaces (IPv4, IPv6)
or just one interface with multiple addresses?

If not, should we do something about it?

/O

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 6 Nov 2016 13:34:02 +0100

> or just one interface with multiple addresses?

IMO, the OS makes the choice and the app just finds out what it is and print
it last-minute in the message being sent out. This seems more an implementor's
choice rather than protocol standardization, doesn't it.

-jiri

p.s. https://github.com/kamailio/kamailio/blob/master/forward.c
get_out_socket() does that as an example.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Nov 2016 09:59:36 +0100

> On 06 Nov 2016, at 13:34, Jiri Kuthan <[email-masked]> wrote:
> 
Maybe. Like with other stuff, we may need a note to implementors so they
get it right. May note be an IETF document though.
> get_out_socket() does that as an example.
Which is code that doesn’t do IPv6 source address selection right when we
tested ;-) Thanks for pointing me to the proper file!

/O

---

From: Simon Perreault <[email-masked]>
Date: Mon, 7 Nov 2016 09:21:09 -0500

> If not, should we do something about it?

Even ignoring all implementation and real-world constraints, what do you
think would be the theoretically perfect UA behaviour? Let's start with
measuring how big is the gap between theory and practice?

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Nov 2016 09:50:55 -0500

This is the same problem as selection of IPv4 vs IPv6 or UDP vs TCP when
running behind firewall.

What we typically do is run a STUN server on the same protocols, IPs and
ports as our SIP proxy. Client would enumerate local interfaces and send a
STUN BIND request to DNS results of the server name resolution. Once we
find the STUN request that received the response, we would start the SIP UA
on that interface and register. The whole process is very similar to ICE
candidate nomination. If keep-alive on the connection fails due to client
migration to another network or DHCP lease expiration, we would restart the
whole process with STUN BIND requests and re-registration.

Another alternative is to use SIP OPTIONS request for the same purpose as
STUN BIND. This uses more resources, but does not require STUN.

Final option is simply do the UDP connect from the unbound socket to the
server IP and then get the socket address. This would give you the local
address which has the route to the server. This does not guarantee that SIP
request will actually be delivered over that route, especially if client on
some kind of VPN, but it does give you the most likely local interface.
Even in the previous two cases we normally start with this interface when
sending connection verification requests.

Given that STUN BIND support is already required for UDP keep-alive
messages by sip-outbound, and that it is typically already supported by SIP
Proxies, we have preferred the STUN based implementation.

Bottom line is there are independent SIP UAs for each of the local
interfaces. Correct SIP UA to be used for connection to a specific server
is determined by sending a test STUN or SIP request.

Regards,

_____________
Roman Shpount

On Mon, Nov 7, 2016 at 9:21 AM, Simon Perreault <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Nov 2016 16:17:18 +0100

> On 07 Nov 2016, at 15:50, Roman Shpount <[email-masked]> wrote:
> 
> This is the same problem as selection of IPv4 vs IPv6 or UDP vs TCP when running behind firewall.
Yes and no. When you want to communicate with something in the same network you may have
multiple addresses available to use
IPv4
IPV6 global
IPv6 global temporary
IPv6 ULA

Is it crystal clear for a SIP developer which one to use? 
I think this may be a generic issue for all IP applications, but wanted to open the discussion to
see if I missed something.

We have seen problems with this at SIPit so this is something a lot of developers have not 
implemented correctly in their SIP implementations.

> 
> What we typically do is run a STUN server on the same protocols, IPs and ports as our SIP proxy. Client would enumerate local interfaces and send a STUN BIND request to DNS results of the server name resolution. Once we find the STUN request that received the response, we would start the SIP UA on that interface and register. The whole process is very similar to ICE candidate nomination. If keep-alive on the connection fails due to client migration to another network or DHCP lease expiration, we would restart the whole process with STUN BIND requests and re-registration.
STUN would not work in many of these cases.
> 
> Another alternative is to use SIP OPTIONS request for the same purpose as STUN BIND. This uses more resources, but does not require STUN.
So who decides what to put in the VIA of the SIP Options??
> 
> Final option is simply do the UDP connect from the unbound socket to the server IP and then get the socket address. This would give you the local address which has the route to the server. This does not guarantee that SIP request will actually be delivered over that route, especially if client on some kind of VPN, but it does give you the most likely local interface. Even in the previous two cases we normally start with this interface when sending connection verification requests.
I think that’s what the code that Jiri pointed to does. But we still have the issue with multiple ULAs. Maybe
the O/S have fixed that now.

> 
> Given that STUN BIND support is already required for UDP keep-alive messages by sip-outbound, and that it is typically already supported by SIP Proxies, we have preferred the STUN based implementation.
You assume we have an inside and an outside, based on the IPv4 NAT model. Think IPv6 for a while :-)
> 
> Bottom line is there are independent SIP UAs for each of the local interfaces. Correct SIP UA to be used for connection to a specific server is determined by sending a test STUN or SIP request.
Food for thought.

/O
>  
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Mon, Nov 7, 2016 at 9:21 AM, Simon Perreault <[email-masked] <mailto:[email-masked]>> wrote:
> https://jive.com <https://jive.com/> | +1 418 478 0989 ext. 1241 <tel:%2B1%20418%20478%200989%20ext.%201241> | [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Nov 2016 12:03:02 -0500

> measuring how big is the gap between theory and practice?

I think we need to first clarify what we mean here.

Does this choice necessarily impact *anything* in the outgoing sip 
message? If so, what?

The most likely thing that it would affect is Via. It is reasonable to 
assume that the Via header has the same address that goes into the 
sender field of the IP packet. 3261 doesn't exactly say that, but 
section 8.1.1.7 does say:

    The Via header field indicates the transport used for the transaction
    and identifies the location where the response is to be sent.  A Via
    header field value is added only after the transport that will be
    used to reach the next hop has been selected (which may involve the
    usage of the procedures in [4]).

which is pretty close.

But that only needs to work for routing of the transaction response. So 
as long as the next hop can get back this way all should be good. It 
isn't necessary for the UAS to be able to route to this address.

Is there some thought that this choice affects anything else in the 
outgoing message? (What to put in the Contact header is a different 
question. I trust that isn't part of the current question.)

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Nov 2016 12:31:59 -0500

> multiple addresses available to use

My suggestion was to use the same procedures as the ones defined when
collecting base candidates for ICE. These should be fairly well defined and
tested with things like WebRTC.

> STUN would not work in many of these cases.

Why would not it work? This is the same procedure as ICE -- send a STUN
bind message over UDP or TCP from each potential client address (gathered
through interface enumeration) to each potential server address (gathered
through DNS resolution). If the server is running STUN on each protocol
(including TCP and TLS), address and port it exposes for external calls,
this check will work if communications are possible.

> So who decides what to put in the VIA of the SIP Options??

 In this case client starts a SIP UA on each potential local address and
sends a SIP OPTIONS request to each potential server address from each SIP
UA. Each SIP UA is bound to the specific address, so it should be clear
which address to put in the VIA.

> the O/S have fixed that now.

This code works often enough. Issues that we saw with just doing this are
related to clients who are connected via a VPN to a corporate environment
that block SIP. Another issue is deciding when to use UDP vs TCP when
behind firewall. This code provides no indication that UDP is blocked.

> Think IPv6 for a while :-)

Once again, what I am proposing is not that different then full ICE with
ICE lite communication. This is known to work with IPv6 :-).

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Nov 2016 12:35:18 -0500

On Mon, Nov 7, 2016 at 12:03 PM, Paul Kyzivat <[email-masked]> wrote:

> outgoing message?

The only other issue this affects is delivering SIP response to a message
when client IP changes in the middle of the SIP transaction. You either
need to accept that the transaction can fail or come up with a mechanism to
recover a SIP transaction on the new client local IP or use something like
TURN to always tunnel SIP messages through the same IP/port in the cloud
(resource intensive).

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 7 Nov 2016 20:00:34 +0000

i- For UDP, shouldn’t the reply sent based on “received” parameter? (RFC3261 18.2.2)
This should take care of the IP Address issue IMHO.

ii- For the port, “rport” would provide a solution but it is not defined in RFC3261 but in RFC3581 (IMHO it is a good idea for the sender always add the “rport”, and even in its absence I think there is no harm for the receiver to assume that it has been received and hence use the port value in the packet header for response routing).

iii- I don’t think “routing responses during failover without failing the transaction” is a widely required/implemented strategy. By and large, such transaction fail and are retried.

I am not saying that populating Via header with the actual packet source IP/port is a bad idea but I think there is nothing much broken from protocol mechanics perspective if it is not done. In practice, it may cause “false alarms” as far as presence of a NAT device is concerned.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, November 07, 2016 12:35 PM
To: Paul Kyzivat <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] Source address selection in SIP

On Mon, Nov 7, 2016 at 12:03 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
Is there some thought that this choice affects anything else in the outgoing message?

The only other issue this affects is delivering SIP response to a message when client IP changes in the middle of the SIP transaction. You either need to accept that the transaction can fail or come up with a mechanism to recover a SIP transaction on the new client local IP or use something like TURN to always tunnel SIP messages through the same IP/port in the cloud (resource intensive).

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Nov 2016 15:14:34 -0500

Just a side note: received and rport are generally useless for TCP or TLS
based transactions. Responses are supposed to be sent over the same TCP/TLS
connection.

For UDP, when sending a message you can safely put 127.0.0.1 in the VIA
address and include rport. The response will get to the right place. I
agree that always adding rport by the receiver is a good idea.

Not implementing transaction fail-over when devices migrate from one IP to
another typically causes about 1-2% call drops. If you are running a
service with long average call duration, such as call conferencing service,
this percentage becomes much higher. You can typically implement some sort
of call recovery by using INVITE with Replaces to work around such dropped
calls.

Regards,
_____________
Roman Shpount

On Mon, Nov 7, 2016 at 3:00 PM, Asveren, Tolga <[email-masked]>
wrote:

> ii- For the port, “rport” would provide a solution but it is not defined
> in RFC3261 but in RFC3581 (IMHO it is a good idea for the sender always add
> the “rport”, and even in its absence I think there is no harm for the
> receiver to assume that it has been received and hence use the port value
> in the packet header for response routing).
>
>
>
> iii- I don’t think “routing responses during failover without failing the
> transaction” is a widely required/implemented strategy. By and large, such
> transaction fail and are retried.
>
>
>
> I am not saying that populating Via header with the actual packet source
> IP/port is a bad idea but I think there is nothing much broken from
> protocol mechanics perspective if it is not done. In practice, it may cause
> “false alarms” as far as presence of a NAT device is concerned.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* sipcore [mailto:[email-masked]] *On Behalf Of *Roman
> Shpount
> *Sent:* Monday, November 07, 2016 12:35 PM
> *To:* Paul Kyzivat <[email-masked]>
> *Cc:* SIPCORE <[email-masked]>
> *Subject:* Re: [sipcore] Source address selection in SIP
>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 07 Nov 2016 20:28:36 -0500

"Olle E. Johansson" <[email-masked]> writes:
> An IPv6 interface by default has multiple addresses. Today's computers
> also quite frequently have multiple interfaces.  A modern SIP stack
> has many IP addresses to select from.

> I tried to find any words in RFC 3261 or RFC 3263 about selection of
> interfaces and addresses but found nothing.  Having said that, it's
> not easy so if anyone on sipcore can point me to the right section I
> will be grateful.
>
> If not, I think we may need a clarification on Transaction layer
> handling of IP address selection in the SIP protocol. Given a specific
> target, how do we handle multiple interfaces and multiple addresses
> per interface - which address do we put in the SIP messages - like in
> via's, record-route, SDPs and contacts.
>
> We have been testing at SIPit with multiple ULAs attached to a network
> and a proxy on one of the ULAs.  No one could connect to that proxy
> properly (sadly for me not even Kamailio itself, which brags about
> having IPv6 support from day one).

It seems to me that the relevant texts are:

RFC 7984 section 4, "Clarification of Interaction with RFC 6724"
RFC 6157 section 5, "Contacting Servers: Interaction of RFC 3263 and RFC
3484"
RFC 6724 section 5, "Source Address Selection"

In the case where the client's one IPv6 interface has a number of
global-scope addresses, only one of which can talk to an outgoing
router, and the destination has one IPv6 address (that can only be
reached in the global scope), processing seems to progress as follows:

Destination address selection is trivial, as there's only one
destination address.

Source address selection starts with all of the client's IPv6 addresses.
RFC 6724 section 5's source address prioritization rules are performed
as follows:

Rule 1 makes no choice.
Rule 2 makes no choice because all of the interface addresses have
global scope.
Rule 3 makes no choice because (I assume) no addresses are deprecated.
Rule 4 makes no choice because (I assume) we are not using IPv6
mobility.
Rule 5 makes no choice because the destination address is not one of the
client's addresses.

Rule 5.5 is:

   Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
   If SA or SA's prefix is assigned by the selected next-hop that will
   be used to send to D and SB or SB's prefix is assigned by a different
   next-hop, then prefer SA.  Similarly, if SB or SB's prefix is
   assigned by the next-hop that will be used to send to D and SA or
   SA's prefix is assigned by a different next-hop, then prefer SB.

Now since there is only one next-hop router, the next-hop is
well-defined.  And that router has assigned the prefix of exactly one of
the interface's addresses.  Rule 5.5 prioritizes that source address
above all the other addresses.

Since that step prefers one address over all others, the remaining rules
are not significant.

Thus, the client should be using the source address which links to the
proxy.  Which is what you would expect.

Interestingly, this logic is supposed to be incorporated into the
getaddrinfo() function, so the SIP implementation shouldn't need to
contain specific logic to handle it if the implementation invokes
getaddrinfo().

However, that section has this qualifier:

      Discussion: An IPv6 implementation is not required to remember
      which next-hops advertised which prefixes.  The conceptual models
      of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
      have no such requirement.  Hence, Rule 5.5 is only applicable to
      implementations that track this information.

Interestingly, I've been having problems with my browser (an old edition
of Firefox) when I got IPv6 service, and it is exactly this problem!

> Executive question summary: Does the current set of SIP standards cover
> IP address selection for the *sender* when we have multiple IP
> interfaces (IPv4, IPv6) or just one interface with multiple addresses?

RFC 6724 section 5 clearly deals with all addresses of all interfaces at
the same time, so I think that issue is properly handled.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 8 Nov 2016 08:38:58 +0000

I am surprised that calls fail because of IP address migration. This seems to be more of an application issue rather than related with the SIP protocol. SIP has retransmissions for transactions. I think applications need to be updated/corrected for the scenarios you mention.

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Monday, November 07, 2016 3:15 PM
To: Asveren, Tolga <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Source address selection in SIP

Just a side note: received and rport are generally useless for TCP or TLS based transactions. Responses are supposed to be sent over the same TCP/TLS connection.

For UDP, when sending a message you can safely put 127.0.0.1 in the VIA address and include rport. The response will get to the right place. I agree that always adding rport by the receiver is a good idea.

Not implementing transaction fail-over when devices migrate from one IP to another typically causes about 1-2% call drops. If you are running a service with long average call duration, such as call conferencing service, this percentage becomes much higher. You can typically implement some sort of call recovery by using INVITE with Replaces to work around such dropped calls.

Regards,
_____________
Roman Shpount

On Mon, Nov 7, 2016 at 3:00 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
i- For UDP, shouldn’t the reply sent based on “received” parameter? (RFC3261 18.2.2)
This should take care of the IP Address issue IMHO.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Roman Shpount
Sent: Monday, November 07, 2016 12:35 PM
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Cc: SIPCORE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Source address selection in SIP

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 08 Nov 2016 17:07:09 -0500

> So who decides what to put in the VIA of the SIP Options??

And also, how does it get put there?  In many cases, it seems that the
underlying network stack will send the request with the "right" source
address, but the SIP client first has to extract from the network stack
what the source address will be, then insert it into the Via header, and
then send the request...  I suppose this isn't an interesting question
of protocol design, but it is probably an annoyance to implementers.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 08 Nov 2016 17:19:53 -0500

> having IPv6 support from day one).

Thinking more about this, it seems that a very similar problem occurs in
IPv4:  Consider a SIP client with two IPv4 interfaces, only one of which
is on a network with a gateway router to the global Internet.  When the
client sends a message, it specifies the destination IPv4 address.  The
client's network stack consults the "route table" to find the IPv4
address of the global gateway and the interface with which to contact
the gateway.  The network stack uses the source address of that
interface.  Everything works as you would like.  The only detail that is
not covered is arranging for the Via to contain an address, host name,
or rport such that the response can route back to the client.

Approximately the same thing should happen in the IPv6 case that Olle
cites:  The underlying network stack will, by default, execute the IPv6
source selection algorithm based on the destination IPv6 address, and it
will identify the IPv6 interface and the source address that can contact
the gateway.

However, Olle reports that the requests fail.  I do not see how that
could happen -- the default behavior of the network stack should cause
the request to be sent in a way that will succeed.

So I hope that Olle can supply more information regarding exactly how
this failure happens.  I suspect that the failure is more complicated
that it initially appears.

Dale

---

From: Adam Roach <[email-masked]>
Date: Wed, 9 Nov 2016 17:08:49 +0900

[as individual]

Can you give a little more detail about the nature of the failures? It's not immediately clear what would fail here. As was pointed out elsewhere, for UDP, responses are routed per received address; and for TCP, they're sent back on the connection from which the request arrived.

/a

> On Nov 6, 2016, at 18:18, Olle E. Johansson <[email-masked]> wrote:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 Nov 2016 10:23:05 +0100

> On 09 Nov 2016, at 09:08, Adam Roach <[email-masked]> wrote:
> 
> [as individual]
> 

1. DNS for a server has ULA address
2. Client with a hole set of IPv6 addresses - link local, global and multiple ULA resolves DNS
3. Client fails to select ULA address as source to reach server

/O

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 Nov 2016 10:25:57 +0000

Isn't this more an issue on OS-level, that it fails to select ULA as the source when destination is ULA?

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Olle E.
> Johansson
> Sent: Wednesday, November 09, 2016 4:23 AM
> To: Adam Roach <[email-masked]>
> Cc: SIPCORE <[email-masked]>; Olle E Johansson <[email-masked]>
> > Can you give a little more detail about the nature of the failures? It's not
> immediately clear what would fail here. As was pointed out elsewhere, for
> UDP, responses are routed per received address; and for TCP, they're sent
> back on the connection from which the request arrived.
> 
> 2. Client with a hole set of IPv6 addresses - link local, global and multiple ULA
> resolves DNS 3. Client fails to select ULA address as source to reach server
> 
> /O
> >
> > /a
> >
> and a proxy on one of the ULAs.
> >> No one could connect to that proxy properly (sadly for me not even
> >> Kamailio itself, which brags about having

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 Nov 2016 11:34:59 +0100

> On 09 Nov 2016, at 11:25, Asveren, Tolga <[email-masked]> wrote:
> 
Could be an O/S level issue, but the report indicated that most O/S has sorted out these problems in regards to IPv6.

Which means that we need to make sure that implementations do the right thing and use the right
source address in the SIP message. Easy to test in the SIPit network - maybe some of you can set something
up for the IETF hackathon coming up?

This failed miserably when we tested with many implementations. 

I think the question for this group really is whether this is something that needs some extra specification,
as the current set of RFCs (as far as I can see) is pretty silent about selecting IP address from a set 
to choose from. Seems like most of the text is based on one single IP per device.

In addition we have the issue with changing IP during a call where there’s no guidance for developers
in the current set of documents. Outbound doesn’t really handle in-dialog situations and there seems
to be a set of different solutions out there.

I am still not sure there’s a problem that requires additional RFCs or updates from this wg or if it
just something we should publish another SIP Forum developer document about...

/O

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 09 Nov 2016 11:18:06 -0500

"Olle E. Johansson" <[email-masked]> writes:
> I think the question for this group really is whether this is
> something that needs some extra specification, as the current set of
> RFCs (as far as I can see) is pretty silent about selecting IP address
> from a set to choose from. Seems like most of the text is based on one
> single IP per device.

It seems to me that the existing RFCs provide sufficient guidance, as my
long-winded analysis a few days ago detailed.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 09 Nov 2016 11:20:38 -0500

"Olle E. Johansson" <[email-masked]> writes:
>> Can you give a little more detail about the nature of the failures?
>> It's not immediately clear what would fail here. As was pointed out
>> elsewhere, for UDP, responses are routed per received address; and
>> for TCP, they're sent back on the connection from which the request
>> arrived.
>

It would help if you listed all the addresses involved, or at least gave
a generic description of what source address the client did select.

Also, what version of Kamailio(sp?) was involved, and what was the OS
that it was running on?  Does Kamailio do source address selection
itself or does it allow the OS to choose the source address?

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 11 Nov 2016 10:19:50 +0100

> On 09 Nov 2016, at 17:20, Dale R. Worley <[email-masked]> wrote:
> 
I have no idea what address the clients selected - I just got no messages
to my server. 
> itself or does it allow the OS to choose the source address?

I guess at that time it was Kamailio 4.0 - I test the dev code in github
so there’s no version number really.  This was SIPit 31 in Nice, France.

There was a link to Kamailio’s code for doing this earlier in this thread.
I haven’t gone through the details, but I think we’re opening a socket
to the target and check what address the O/S selects. 

Will try to set up more tests so I can file a bug report. :-)

/O

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 11 Nov 2016 10:30:55 -0500

> Will try to set up more tests so I can file a bug report. :-)

It seems to me that there are two groups of possible causes.  One group
is fairly simple code failures, the OS is choosing the link address as
the source address, Kamailio is choosing the wrong destination address,
or something like that.  That group has the property that you can point
to some piece of code that is behaving incorrectly (out of
specification).

The other group comes from this clause in RFC 6724:

It's possible that the OS is selecting a global source address but not
one that the gateway router sees, because the source address has a
prefix that the router isn't using.  And it seems from "Discussion" that
the OS is *not* required by existing RFCs to pick the global address
with the prefix that will actually get gatewayed globally.

How to go about fixing that is an interesting question.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Nov 2016 12:44:48 -0500

One issue we saw was clients using VPN, with VPN taking them to a business
network which blocks SIP.

This is why we added addresses enumeration and STUN checks similar to ICE
to verify which address actually has internet access.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 15 Nov 2016 21:56:41 -0500

[email-masked] (Dale R. Worley) writes:
> Part of the trouble is that you can send to a single destination address
> through more than one interface.  I wonder if the address selection
> system provides for a way for an application to say "send all global
> traffic through interface X"?

Looking at RFC 6724, it looks like the "policy table" (section 2.1) can
be used to instruct the implementation to send SIP traffic destined for
certain prefixes using certain source addresses (which map to
interfaces).  And it looks like the glibc version of getaddrinfo() uses
a file /etc/gai.conf to provide policy table services.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Tue, 15 Nov 2016 22:17:23 -0500

Typically doing a UDP connect with unbound local socket and then looking at
the socket address works quite well for determining local policy.
Unfortunately local policy can lie. For instance end point can be behind
the VPN that sets the default route to something (office network) that
blocks SIP. There is an option to be aggressive and send connectivity
checks from all available interfaces or, alternatively, implementation can
follow the local policy and fail to connect. The implementation needs to
decide what is more important -- following the policy or establishing the
connection.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 15 Nov 2016 17:29:08 -0500

> to verify which address actually has internet access.

Interesting... that's not fixable as an ordinary source address
selection problem.

It's really a sort of Happy Eyeballs problem, where one interface has
global SIP access and one doesn't but the client has no way to determine
the right interface without trial because both interfaces have outgoing
routers.

We're working on a "Happy Eyeballs for SIP" draft, but the current
version explicitly doesn't address this sort of problem:

   A dual-stack host normally has one physical interface, and all
   network access is done via IPv4 and IPv6 addresses assigned to that
   interface.  However, a dual-stack host might have additional physical
   interfaces or additional logical interfaces (e.g., because of a VPN).
   Additional Happy EarBalls considerations for optimal operation with
   additional physical or logical interfaces is for further study and is
   outside the scope of this document.

Perhaps we should add some guidance in this area, either in this cycle
of work or in a future one.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Nov 2016 10:59:56 -0500

Roman Shpount <[email-masked]> writes:
> There is an option to be aggressive and send connectivity

Within the conceptual framework of Happy Eyeballs, it's clear that the
optimal strategy is to consider the alternative source interfaces (or
perhaps source addresses) as connectivity alternatives in much the same
way that destination addresses are.  Then, use the local policy to
determine the order in which to check the possibilties, but (in general)
use the most policy-preferred alternative that actually works.  The
details to do this well are probably messy, though.

As we expand the scope of the Happy Eyeballs draft, please remind us to
address this issue at some point.

Dale