Subject: [Speermint] comments on draft draft-creighton-khandpur-speermint-srv-naptr-use-01

From: Klaus Darilion <[email-masked]>
Date: Fri, 29 Sep 2006 12:24:24 +0200

Hi Tom, Gaurav!

Following some comments.

> 3. Session Peering Setup 
>  
>    SIP systems are represented by user agents (UA).  In the diagram 
>    below, a user agent (UA1), hosted by a service provider SP1, 
>    initiates a call to a User Agent (UA2), hosted by service provider 
>    SP2.  The egress SIP server of SP1 is a SIP stateful Session Peering 

                                                  ^^^^^^^^^
IMO we should not require the PeeringProxy to be stateful (btw: 
transaction stateful or dialog stateful).

>    The figure below shows a high level SIP call flow setting up a SIP 
>    peering session between SP1 and SP2. All SIP signaling MUST go 
>    through the SPP1 and SPP2 as these are the ingress and egress points 
>    in SP1 and SP2 network. 
>     
>                  UA 1  SPP 1  DNS 1  DNS 2  SPP 2   UA 2 
>                   |      |      |      |      |      | 
>                   |INVITE|      |      |      |      | 
>                   |----->|      |      |      |      | 
>                   |     NAPTR Query    |      |      | 
>                   |      |----->|      |      |      | 
>                   |    NAPTR Response  |      |      | 
>                   |      |<-----|      |      |      | 
>                   |     SRV Query      |      |      | 
>                   |      |----->|      |      |      | 
>                   |   SRV+A Response   |      |      | 
>                   |      |<-----|      |      |      | 

I wonder why you combine SRV+A in one response. This depends on the DNS 
server. If you have a "simple" resolver, you have to ask for each record 
separate. If you have an "intelligent" resolver, you will get 
NAPTR+SRV+A in the same response (if SRV+A are cached or responded by 
the authoritative server).

Further it depends if SPP1 does cache DNS too. The SIP proxies I know 
will do 3 lookups (regardless if the additional section contains SRV and 
A or not) as they do not have a DNS cache.

Thus, I suggest to either draw 3 lookups in the figure 1. NAPTR, 2. SRV, 
3. A/AAAA or to draw only one lookup.

> 3.1 TARGET Determination 
>  
>    The target resource is identified with a SIP or SIPS URI.  This is 
>    the URI in the Route header, if present, or the URI from the request 
>    URI of the SIP INVITE received by SPP1.  

I would write "topmost Route header" just for clarification.

> 3.2 NAPTR Lookup 

I would add somewhere that NAPTR/SRV/A lookups must be skipped according 
to RFC 3263 [3] if transport/port/IP are already specified in the target 
URI.

>    DNS MUST return at least three records - one with "SIP+D2T", one 
>    with "SIP+D2U" and one with "SIPS+D2T" service type for the case of 
>    direct peering (section 4.3 in [6]). "SIPS+D2T" is not a MUST for 
>    indirect (transit) peering (section 4.4 in [6]) since domain validation 
>    as specified in section 26.3.2.2 of [1] for TLS at layer 5 will not work 
>    for indirect peering.

This sounds like TLS can't be used in transit peering. I would like to 
use TLS also in transit scenarios. IMO it would be better to remove 
layer 5 certificate validation (section 26.3.2.2 of [1] ) than removing 
TLS completely.

> 3.3 SRV Lookup 
...
>    Alternatively, if no NAPTR records are found, then SPP1 uses the 
>    preferred transport protocol and issues an SRV query for that 
>    specific transport using sips for SIPS URI and SIP URI with TLS and 
>    sip for SIP URI. 

IMO this sentence is not clear. What do you mean with "preferred 
protocol"? Is the preferred protocol somewhere defined or is it the 
preference of SP1?

Further I would write "_sips" instead of "sips" and "_sip" instead of 
"sip" to make it clear that you mean the domain prefix for the SRV lookup.

> 3.4 Using SRV Results 
>     
>    RFC 2782 describes the procedures on how to use and interpret the 
>    results obtained from the SRV query.  The target entry of the SRV RRs 
>    is looked up by querying the DNS for address records. The SRV response 
>    from DNS MAY also include A records with it which will cut down on round

Again - also the NAPTR lookup may already return the SRV and A record. 
Having a additional section in the DNS response is not limited to the 
SRV lookup.

> 4.1 SPP1 Fails to Reach SPP2 
>     
>    A 503 error response is reported by the transaction layer, or failure 
>    can occur at the transport layer due to TCP disconnect in connection, 
>    ICMP error in UDP or time out at transport layer or SIP layer timeout 
>    when its not receiving any SIP response.  In such situations, SPP1 
>    tries a new SIP request transaction to the next available server 
>    instance of SPP2 as determined by SRV RRs entry.  

This is against RFC 3261 which says in case of 503 it should not send to 
an alternate server:

21.5.4 503 Service Unavailable
    ...
    A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
    attempt to forward the request to an alternate server.  It SHOULD NOT
    forward any other requests to that server for the duration specified
    in the Retry-After header field, if present.

I further wonder about best practise for failover to another ingress 
point of SP2. UDP timeout can take up to 32 seconds. TCP timeout depends 
on the OS. IMO this is quite long time for failover.

1. Should this be described in this draft or maybe in the callfows draft?

2. What would be a good value until trying the next server? 32 seconds 
is too long. RFC 3261 allows redefinition of Timer T1. The default value 
is 500ms and should reflect the RTT to the next hop. Thus, if it is 
knows that the RTT to the ingress point is 100ms, setting T1 to 100ms 
allows faster failover (of course the Peering Proxy needs to support 
setting of T1)

> 5. Caching/TTL 
>  
>    SRV RRs have a TTL value based on which the SPP1 caches the entry for 
>    that duration and any further requests to the same TARGET domain are 
>    delivered to the cached server instance.  The TTL recommended for SRV 

This sounds like the SPP1 must cache DNS results. Usually applications 
does not caches DNS as the caching is done by SP1's resolving name 
server. IMO caching in the resolver must be fine too.

regards
Klaus

-- 
Klaus Darilion
nic.at

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint