Subject: [Sip] comments on sip-outbound-04

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2006 18:28:29 -0400

>  such detection takes time and leaves a window of opportunity for
>    missed incoming requests, this mechanism allows the UA to use
>    multiple flows to the proxy or registrar.  This mechanism also uses a

multiple flows to multiple proxies or registrars

> Edge Proxy: An Edge Proxy is any proxy that is located topologically
>       between the registering User Agent and the registrar.

nit: topological in what sense? Certainly not in the IP sense. Its only 
in the SIP sense. SHould be clarified.

>   outbound-proxy-set A set of SIP URIs (Uniform Resource Identifiers)

Missing colon after outbound-proxy-set.

>  is power cycled.  Each UA can register multiple times over different
>    connections for the same SIP Address of Record (AOR) to achieve high

over different flows for the same...

> The registrar can use the reg-id label to
>    recognize that a UA is registering after a reboot or a network
>    failure.

reg-id is not just needed for reboots; its needed to differentiate 
different registrations to the same instance for purposes of high 
availability

> When a proxy goes to route a message to a UA for which it has a
> 
> 
> 
> Jennings & Mahy         Expires December 27, 2006               [Page 5]
> 
> Internet-Draft     Client Initiated Connections in SIP         June 2006
> 
> 
>    binding, it can use any one of the flows on which a successful
>    registration has been completed. 

this paragraph really applies to a home proxy. I think you should 
clarify that, and then summarize edge proxy procedures too.

> The registrar saves the instance-id
>    ("urn:uuid:00000000-0000-0000-0000-000A95A0E128") and reg-id ("1")
>    along with the rest of the Contact header field.  If the instance-id
>    and reg-id are the same as a previous registration for the same AOR,
>    the proxy uses the most recently created registration first. 

it uses it first when processing incoming requests. The rest of the 
paragraph is talking about processing register requests, and this 
summary sounds like its implying that you would delete the previous 
registration.

> When the proxy goes to forward a request to a given target,
>    it looks and finds the flows over which it received the registration.

this uses flows as plural, but the use case is talking about a single 
flow being registered at a time. So, I think you mean that the proxy 
looks and finds the flow over which it has received the most recent 
registration from that instance.

> If the proxy has multiple flows that all go to
>    this UA, it can choose any one of registration bindings for this AOR
>    that has the same instance-id as the selected UA.  

sure - but in this example section you've been talking about a single flow.

> hosts that can perform the outbound proxy/registrar function for the
>    domain.  Reliability is achieved by having the UA form two TCP
>    connections to the domain.

two flows

> The UA is configured with multiple outbound proxy registration URIs.
>    These URIs are configured into the UA through whatever the normal
>    mechanism is to configure the proxy or registrar address in the UA.

I think we are looking at several options which aren't the 'normal 
mechanism' for configuration. Indeed I think it shouldn't be the normal 
configuration mechanism at all. Can we just say that the UA is 
configured with multiple URI and the means is outside the scope of this 
specification.

> The domain also needs to ensure that a request for the UA sent to
> 
> 
> 
> Jennings & Mahy         Expires December 27, 2006               [Page 8]
> 
> Internet-Draft     Client Initiated Connections in SIP         June 2006
> 
> 
>    host1 or host2 is then sent across the appropriate flow to the UA.
>    The domain might choose to use the Path header approach (as described
>    in the next section) to store this internal routing information on
>    host1 or host2.

I don't understand the Path reference here. Path is useful if there is a 
physically distinct EP, which there isn't. For this particular use case 
(co-located outbound proxy/registrar and dual flows), I think that the 
proxy, when doing the registration lookup, will find two registrations. 
It needs to select the one corresponding to the flow that it knows 
about. Somewhere in the normative text also we need to say this.

> When a single server fails, all the UAs that have a flow through it
>    will detect a flow failure and try to reconnect. 

No, they won't try to reconnect, at least not immediately. You point out 
later that this is done gradually to avoid avalance restart, but this 
sentence in particular contradicts that. I would suggest:

When a single server fails, the UAs that have a flow through it will 
eventually detect failure of that flow. The clients themselves will need 
to reconnect in order to re-establish the flow. If clients attempted to 
reconnect immediately, this would cause a flood of connection attempts 
at around the same time, a situation known as avalanche restart. To 
avoid this condition, if a UA has multiple flows, and one of the servers 
fails.....

>   restart.  If a UA has multiple flows, and one of the servers fails,
>    the UA delays the specified time before trying to form a new
>    connection to replace the flow to the server that failed.  By

new flow

>   When used in this fashion to achieve high reliability, the operator
>    will need to configure DNS such that the various URIs in the outbound
>    proxy set do not resolve to the same host.

this statement is fine but doesn't belong in an overview of operation 
section i think.

>  Some SIP deployments use edge proxies such that the UA sends the
>    REGISTER to an Edge Proxy that then forwards the REGISTER to the
>    Registrar.  The Edge Proxy includes a Path header [RFC3327] so that
>    when the registrar later forwards a request to this UA, the request
>    is routed through the Edge Proxy.  There could be a NAT or firewall
>    between the UA and the Edge Proxy.

you don't show the NAT in any of the other two use cases and certainly 
they can be there too. THis makes it sound kind of like you need an EP 
in cases where there is a NAT, which is not the case.

>   These systems can use effectively the same mechanism as described in
>    the previous sections but need to use the Path header.  When the Edge

this is kind of weasely text. I'd suggest:

In this topology, the same mechanism as described in the previous 
section is used, with the addition of the Path header.

>  registrar succeeds, it allows the Edge Proxy to indirectly check the
>    user's authentication information via the registrar.  The identifier
>    SHOULD be placed in the user portion of a loose route in the Path
>    header.  If the registration succeeds, the Edge Proxy needs to map

normative statements do not belong in overview sections. see rfc4485.

>  For connection-less transports, a flow definition could change
>    because a NAT device in the network path reboots and the resulting
>    public IP address or port mapping for the UA changes.  To detect
>    this, requests are sent over the same flow that is being used for the
>    SIP traffic. 

stun requests are sent over the same flow

>  cycles of the device.  The Instance ID MUST NOT change as the device
>    moves from one network to another.

suggest also saying that the instance ID MUST NOT vary across different 
network interfaces that the device has. There has been some confusion 
about whether a multi-homed device would have different instance IDs on 
each network interface.

>   The UA SHOULD include a "sip.instance" media feature tag as a UA
>    characteristic [RFC3840] in requests and responses.  

in the very next section, you say that inclusion of sip.instance media 
feature tag in a registration is a MUST. So, these are not consistent.

Also, you never actually say that this value is the UA instance URN 
you've been talking about in the previous paragraphs.

>  The value of this parameter MUST be a URN [RFC2141].  One case where
>    a UA may not want to include the URN in the sip.instance media
>    feature tag is when it is making an anonymous request or some other
>    privacy concern requires that the UA not reveal its identity.

..may not want to include its instance identifier URN in the 
sip.instance....

>    UAs obtain at configuration time one or more SIP URIs representing
>    the default outbound-proxy-set. This specification assumes the set
>    is determined via any of a number of configuration mechanisms and
>    future specifications may define additional mechanisms such as using
>    DNS to discover this set.  How the UA is configured is outside the
>    scope of this specification. 

I think the term 'configuration' is a bit loaded here, and others I think
have commented on this too. I'd suggest, instead:

UAs obtain, through some means outside the scope of this specification, 
one or more SIP URIs representing the default outbound-proxy-set.

>  URIs.  For each outbound proxy URI in the set, the UA MUST send a
>    REGISTER in the normal way using this URI as the default outbound
>    proxy. 

the word 'normal' concerns me here. What does this mean? Per rfc3261 
procedures? Thats not really right, since we are updating those 
procedures here. Suggest:

For each outbound proxy URI in the set, the UA MUST send a REGISTER 
using the procedures defined here (which augment those defined in 
RFC3261) using this URI as the default outbound proxy.

>    These ordinary registration requests MUST also add a distinct reg-id
>    parameter to the Contact header field. 

remove 'ordinary'

You also need to define 'distinct'. What you mean is that the value must 
be distinct across all other flows to be concurrently registered by the 
same instance.

> The
>    reg-id sequence does not have to be sequential but MUST be exactly
>    the same reg-id sequence each time the device power cycles or reboots
>    so that the reg-id values will collide with the previously used
>    reg-id values.  This is so the proxy can realize that the older
>    registrations are probably not useful.

This text is very confusing, especially the first sentence which says 
that a sequence of something doesn't have to be sequential. I'd suggest:

Furthermore, if the UA will be using N simultaneous flows, the N values 
of the reg-id that are used MUST be reused in subsequent refreshes or 
brand new registrations made at a later time. As a consequence, the 
reg-id forms a sort of sequence number, giving a persistent identifer to 
each of the N concurrent registrations that the UA will make. Indeed, 
one perfectly valid choice for the reg-id is to use a monotonically 
increasing sequence number from 1 to N, however this is not required.

>  The UAC MAY examine successful registrations for the presence of an
>    'outbound' option-tag in a Supported header field value.  Presence of
>    this option-tag indicates that the registrar is compliant with this
>    specification.

this is meaningless unless you specify something that the client does 
differently based on the presence of this header field.

Also, this section doesn't talk about how a UA determines whether or not 
the registrar supports the contact header field extensions and new 
mechanisms defined here. It needs to do that.

> The UA performs normal DNS resolution on the next hop URI (as
>    described in RFC 3263 [RFC3263]) to find a protocol, IP address, and
>    port.  For non-TLS protocols, if the UA has an existing flow to this
>    IP address, and port with the correct protocol, then the UA MUST use
>    the existing connection.  For TLS protocols, there must also be a
>    match between the host production in the next hop and one of the URIs
>    contained in the subjectAltName in the peer certificate.  If the UA
>    cannot use one of the existing flows, then it SHOULD form a new flow
>    by sending a datagram or opening a new connection to the next hop, as
>    appropriate for the transport protocol.

I'm pretty sure that this text would fundamentally require UA changes 
for any mid-dialog failover solution to work. I'm still noodling over 
whether there is a better matching algorithm that is more likely to work 
with future mid-dialog failover mechanisms.

> The time between keepalive requests when using UDP-based transports
> 
> 
> 
> Jennings & Mahy         Expires December 27, 2006              [Page 14]
> 
> Internet-Draft     Client Initiated Connections in SIP         June 2006
> 
> 
>    SHOULD be a random number between 24 and 29 seconds while for TCP-
>    based transports it SHOULD be a random number between 95 and 120
>    seconds.  These times MAY be configurable.

you need to clarify that you redraw the random number each time you send 
a keepalive, not just once on startup. ALso, the bit thats configurable 
are the ranges (24-29, 95-120). Also should specify that the random 
number is uniformly distributed.

> If the parameter is present, the UA needs
>    to periodically perform keepalive checks by sending a STUN [I-D.ietf-
>    behave-rfc3489bis] Binding Requests over the flow.

you should point to the binding keepalive usage specifically in 3489bis.

>  These three times MAY be configurable in the UA.  The three times
>    are:
>    o  max-time with a default of 1800 seconds
>    o  base-time-all-fail with a default of 30 seconds
>    o  base-time-not-failed with a default of 90 seconds

the formula doesn't include the variables 'base-time-all-fail' or 
'base-time-not-failed'. It just has 'base-time'. Suggest:

      o base time with a default of 90 seconds if there are other 
non-failed flows, and 30 seconds if all other flows have failed

>   When an Edge Proxy receives a registration request with a reg-id
>    header parameter in the Contact header field, it MUST form a flow
>    identifier token that is unique to this network flow.  The Edge Proxy
>    MUST insert this token into a URI referring to this proxy and place
>    this URI into a Path header field as described in RFC 3327 [RFC3327].
>    The token MAY be placed in the userpart of the URI.

It also needs to remember the flow and associated it with this token.

>  Algorithm 1: The proxy base64 decodes the user part of the Route
>       header.  For a TCP-based transport, if a connection specified by
>       the file descriptor is present and the creation time of the file
>       descriptor matches the creation time encoded in the Route header,
>       the proxy forwards the request over that connection.  For a UDP-
>       based transport, the proxy forwards the request from the encoded
>       file descriptor to the source IP address and port.

you need to specify the conditions under which a 410 is sent. You do 
that for algorithm 2 but not here.

> For a binding
>    with an instance-id, the registrar still stores the Contact header
>    field value URI with the binding, but does not consider the Contact
>    URI for comparison purposes. 

I think you mean:

For a binding to an instance-ID and reg-ID, the registrar still stores....

Also, you may want to clarify handling when there is an instance-ID but 
no reg-id, and reg-id but no instance ID.

You also need to point out here quite explicitly that it is very likely 
that there can be registrations for the same AOR that have difference 
instance ID and reg-IDs, but the same contact URI. This happens when the 
client is behind NAT and includes a private IP address in the contact 
URI, such as sip:10.0.1.1:5060.

>  In addition to the normal information stored in the binding record,
>    some additional information MUST be stored for any registration that
> 
> 
> 
> Jennings & Mahy         Expires December 27, 2006              [Page 18]
> 
> Internet-Draft     Client Initiated Connections in SIP         June 2006
> 
> 
>    contains a reg-id header parameter in the Contact header field value.
>    The registrar MUST store enough information to uniquely identify the
>    network flow over which the request arrived.  For common operating
>    systems with TCP, this would typically just be the file descriptor.
>    For common operating systems with UDP this would typically be the
>    file descriptor for the local socket that received the request, the
>    local interface, and the IP address and port number of the remote
>    side that sent the request.

this is only for registrars co-located with edge proxies. Need to 
clarify that.

>    o  The proxy MUST NOT populate the target set with more than one
>       contact with the same AOR and instance-id at a time.  If a request
>       for a particular AOR and instance-id fails with a 410 response,
>       the proxy SHOULD replace the failed branch with another target (if
>       one is available) with the same AOR and instance-id, but a
>       different reg-id.
>    o  If two bindings have the same instance-id and reg-id, the proxy
>       SHOULD prefer the contact that was most recently updated.

here is where you need to add words that in the co-located EP/home proxy 
case, the reg-id corresponding to the flow held by that EP is used. Also 
I think generally more guidance is needed on selection of registrations 
when there are multiple reg-id. For example, if you are using 
geo-redundancy, the home proxy would use the reg-id received from teh EP 
in its own region.

> Additionally, when the
>    proxy forwards a request to a binding that contains a reg-id, the
>    proxy MUST send the request over the same network flow that was saved
>    with the binding.

only applies to the EP -should be clear on that.

> 7.1.  STUN Processing
> 
>    This document defines a new STUN usage for connectivity checks.

no no. Firstly its not 'connectivity check', as thats something 
different entirely. This is binding keepalive usage. I think we should 
define the usage in rfc3489bis, and merely specify here that this usage 
is applied to sip.

The only thing that needs to be in here is the keepalive=stun bit. 
Everything else in this section is already in rfc3489bis.

> The simple case is when there are no edge proxies.  In this case, the
>    only time an entry can be added to the routing for a given AOR is
>    when the registration succeeds.  SIP already protects against
>    attackers being able to successfully register, and this scheme relies
>    on that security. 

attackers can be authenticated too. The scheme in here does not assume 
that attackers are unauthenticated.

>  This section registers a new media feature tag, per the procedures
>    defined in RFC 2506 [RFC2506].  The tag is placed into the sip tree,
>    which is defined in RFC 3840 [RFC3840].
> 
>    Media feature tag name:  sip.instance
> 
>    ASN.1 Identifier:  New assignment by IANA.

If memory serves me correctly, in the end with rfc3840 I had to pick the 
ASN.1 identifiers.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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, 7 Jul 2006 09:54:35 +0300

Hi,

>> When a UA is about to send a request, it first 
>> performs normal processing to select the next hop URI.

>> The UA performs normal DNS resolution on the next 
>> hop URI (as described in RFC 3263 [RFC3263]) to 
>> find a protocol, IP address, and port. For non-TLS 
>> protocols, if the UA has an existing flow to this
>> IP address, and port with the correct protocol, then 
>> the UA MUST use the existing connection.  
>
>I'm pretty sure that this text would fundamentally require 
>UA changes for any mid-dialog failover solution to work. 

Mid-dialog failover is not the only case for which the
referred piece of text has a problem. It also contains
a clear bug at least when used literally for registration
refreshes.

For outbound to work correctly, UA must send the registration
refresh over the same flow that was created when sending
the initial registration to be refreshed. Currently the
draft fails to mention this as I have earlier pointed out.

RFC 3263 procedures DO NOT guarantee that when UA resolves
once again the URI of the next hop (of the outbound proxy),
it would result the same IP address which was received
when resolving the same URI previously. If it is different
IP address then another flow will be used, perhaps towards
a totally different proxy as used earlier.

UA should cache the DNS RRs it received when it resolved the
URI the first time, so the problem is not whether the DNS
server returns the same values or not. The failure can 
happen if the domain has a number of SRV records with
the same transport and priority values, but different
weights (for load balancing reasons).

a) RFC 3263 states that to resolve a SIP URI without a
   transport or port parameter, the UA will have to use
   NAPTR, SRV and address queries to get the IP address.

b) RFC 2782 defines the weight for SRV RR as follows:

        A server selection mechanism.  The weight field specifies a
        relative weight for entries with the same priority. Larger
        weights SHOULD be given a proportionately higher probability of
        being selected. The range of this number is 0-65535.  This is a
        16 bit unsigned integer in network byte order.  Domain
        administrators SHOULD use Weight 0 when there isn't any server
        selection to do, to make the RR easier to read for humans (less
        noisy).  In the presence of records containing weights greater
        than 0, records with weight 0 should have a very small chance of
        being selected.

        In the absence of a protocol whose specification calls for the
        use of other weighting information, a client arranges the SRV
        RRs of the same Priority in the order in which target hosts,
        specified by the SRV RRs, will be contacted. The following
        algorithm SHOULD be used to order the SRV RRs of the same
        priority:

        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.

        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority.

When processing the SRV records as per RFC 3263, the UA may select
different record each time, due to the randomness involved for
selecting the order of SRV records to try. Even if the UA would
cache the DNS records itself, nothing requires it to cache the
ultimate result of RFC 3263 processing, so the result may be
different IP address each time. 

For legacy SIP this has not been a problem. The registrar (not to
mention the proxy) could not care less if the registration refresh
was routed over different edge proxy each time. However for outbound
this would not cause the desired behaviour. I can identify at least
two issues:

1. It is not clear how the UA should handle the flow related 
   to a registration if it swaps from one proxy to another.

2. If the UA has one primary and one secondary flow, it might
   happen that when refreshing the primary flow, the UA would
   accidentally move it to the same proxy towards which the
   secondary flow is going to. So redundancy would be lost.

P.S. I tried to raise this issue already twice but because I
did not get any clear response, I now do it once again as I will
be out of office for the next few weeks. I hope that this time
I was able to formulate the problem statement clearly enough
for you to get the point.

Regards,

Erkki