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

From: Klaus Darilion <[email-masked]>
Date: Thu, 20 Jul 2006 18:28:55 +0200

btw: openser fully supports RFC3263: NAPTR+SRV (although failover to 
multiple announced SRV entries in yet not supported)

regards
klaus

Jean-Francois Mule wrote:
> 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

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