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

From: "Khandpur, Gaurav" <[email-masked]>
Date: Fri, 6 Oct 2006 12:13:53 -0400

Thank you for your comments, Klaus. See inline [GKH].

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Friday, September 29, 2006 6:24 AM
To: [email-masked]
Subject: [Speermint] comments on
draftdraft-creighton-khandpur-speermint-srv-naptr-use-01

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).

[GKH] IMO the PeeringProxy (SBE as per the terminology draft) is
stateful. It can be transaction stateful call stateless , or, call
stateful aswell (like an SBC). So I was keeping it open to the Service
Provider to choose what to deploy. What are your thoughts?

>    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.

[GKH] I agree having 3 lookups makes sense and stating that these
lookups can be combined.

> 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.

[GKH] ACK. 

> 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.

[GKH] ACK.

>    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.

[GKH] TLS cannot be used for transit peering for SIPS only, SIP over TLS
is fine in transit peering case.
  
> 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?

[GKH] Good point. I can make recommendation in this BCP to use TLS as
preferred. What are your thoughts?

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.

[GKH] Yes, that was a typo from our side. It should be the domain prefix
for SRV. 

> 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.

[GKH] Agree. Before I begin this section, I will mention that if A
records are not known with SRV responses, then the following procedure
would apply.

> 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.

[GKH] 503 SHOULD work. 

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?

[GKH] Since this is the BCP for use of DNS SRV we should make
recommendations in this draft unless others have different views.

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)

[GKH] We can recommend T1 to be configurable on the SPP1 and recommend
an upper limit value in this BCP ? 

> 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.

[GKH] I agree its upto the SPP1 to cache DNS results or not. In the BCP
I only wanted to recommend the values for TTL of SRV and NAPTR, when
specified. So I will state that caching is not MUST in SPP.

regards
Klaus

-- 
Klaus Darilion
nic.at

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

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

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 10 Oct 2006 11:09:44 +0200

> Provider to choose what to deploy. What are your thoughts?

IMO using a stateless or stateful peering proxy is a design decision of 
the VSP and this should not be mandated by an RFC.

> is fine in transit peering case.

Yes, but SIP over TLS also uses NAPTR service type "SIPS+D2T". Thus for 
NAPTR lookups SIPS and SIP over TLS are identically.

> preferred. What are your thoughts?

Yes, TLS preferred is fine with me.

> an upper limit value in this BCP ? 

yes, thats fine.

> specified. So I will state that caching is not MUST in SPP.

ACK.

regards
klaus