Subject: RE: [Speermint] use of RFC 3263 for locating peer's SIP server

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 27 Jun 2006 13:11:01 -0600

Hi Rohan,

   Thank you for your input. 

You wrote:
[snip]
> Note
> that most of these proxies will be consulting ENUM records and will
> need to implement NAPTR anyway for ENUM.  I don't think RFC3263 is too
> much to ask for.

I did not think full support for 3263 was too much to ask for "on the
paper". But my question was geared towards best current practices,
existing implementations (3263 has been lacking for transport protocol
selection) and initial operators deployments (not showing up in
numbers).

So far, zero positive response for full support from service providers
based on the question, one operator nack for 3263 NAPTR.

Jean-Francois.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Monday, June 19, 2006 3:05 PM
> To: Jean-Francois Mule
> Cc: [email-masked]
> Subject: Re: [Speermint] use of RFC 3263 for locating peer's SIP
> server
> 
> Hi Jean-Francois,
> 
> To use full NAPTR and SRV lookups in a peering context, we are only
> really worried about a pair of SIP proxies (one for the initiating
> peer and another for the receiving peer) implementing NAPTR.  Note
> that most of these proxies will be consulting ENUM records and will
> need to implement NAPTR anyway for ENUM.  I don't think RFC3263 is too
> much to ask for.
> 
> thanks,
> -rohan
> 
> On 6/19/06, Jean-Francois Mule <[email-masked]> wrote:
> > Hi,
> >
> >    We have discussed the use of the DNS procedures specified in
> RFC3263
> > in speermint to resolve a SIP URI into a reachable host (IP address
> and
> > port), and transport protocol.
> >
> >    To document the best current practices, could you contact me if
> you
> > have any implementation or operational experience in field use of
> 3263
> > mechanisms (full 3263 or partial NAPTR/SRV)?
> >         - based on Robert Sparks' presentation in IETF#65 SIPPING on
> the
> > status of the implementation in sip interoperability testing events:
> >         40% of implementers showing up in SIPit do NAPTR,
> >         50% do SRV.
> >
> >         - when implemented on the products, how many folks use those
> > options? any feedback on the field use of 3263 for NAPTR lookup for
> SIP
> > transport protocol selection?
> > a) The RFC indicates that if the URI contains the transport
protocol,
> > then it should be used (no lookup): is this common? Should it be?
> > b) In a few publicly-available product administration guides I have
> > looked at, NAPTR lookup for transport selection can be turned on/off
> > when it exists as anyone would expect. Do service providers use it?
> If
> > no, what are the issues?
> > ==> I'm told that some service providers mandate one transport
> protocol
> > (say TCP) for SIP termination and therefore, the transport protocol
> to
> > reach a peering partner is often statically configured along with
> the
> > sip route. Is this common?
> > ===> some folks believe it is costly to do on a per query basis. Is
> this
> > a matter of recommending proper DNS caching and long enough TTL
> values
> > for those things?
> >
> >         - what about SRV? Same questions.
> >
> > If I get enough feedback, my goal is to provide a brief summary on
> the
> > above to the list, and possibly, draft one or two slides outline any
> > issues at IETF#66.
> >
> > Thanks,
> > Jean-Francois.
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >

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