Subject: RE: [Enum] Using ENUM for SIP Applications

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 18 Feb 2002 04:42:27 -0600

I think these are exactly the respects in which SIP and ENUM are, to a small
degree, competitive. ENUM could be used to provide service-specific URIs
through more specific and detailed 'protocol' or 'resolution service'
subfields of the service field. SIP of course has its own way of figuring
out where requests should be directed and what communications services
should be invoked for a session,. Where does ENUM stop and SIP begin when
you're trying to figure out how to communicate? This is the entire question
explored by our draft, which has a good amount of analysis of the two
protocols, but I'll speak briefly to this point here as well.

Agreed that if you have more than one SIP URI in ENUM, then if no means of
differentiation are provided, then this leads to a potentially awkward and
slow mechanism of selecting a proper NAPTR record. This could lead one to
draw one of two conclusions: 1) that you need differentiation of service
fields, or 2) that you should use only one SIP URI in ENUM. This is the
issue on which the people who are implementing ENUM for SIP must arrive at
consensus.

ENUM works best, I think, if, before you send a SIP request to a remote
endpoint, you already know what kind of session you want to have - presence,
instant messaging, telephony, video, etc. However, SIP does not require you
to decide on a communications service before you send an INVITE. Rather, it
lets you express your capabilities in an INVITE, and then to negotiate with
the target user which set of those communications services, if any, you
should employ for a session. I think it is in fact when you have multiple
"kinds" of service that SIP's capability negotiation really has an
advantage. 

Agreed that it is possible to have a single communications service in mind
(like, say, instant messaging) you would like to employ before you send a
SIP request. Some would argue that many SIP devices support only a single
communications service (although I believe the most common one today
supports many such communications services by default). But even if you get
particular communications services from different service providers, SIP has
its own mechanisms for properly directing requests for communication that
provide, in my estimation, a bit more sophistication than is available from
the service fields of NAPTR records. In a previous note I talked a bit about
the benefits of managing devices at a real-time location service rather than
in the DNS. It is because of the loss of these real-time features, and the
full capability negotiation services of SIP, that it has been argued by some
people in the SIP community that composing services this way in ENUM
actually deprives SIP of capability. 

If you discover that a particular communications service is available
through an ENUM service field, SIP still needs to do further capability
negotiations that will ultimately determine how and if a session can be
established with the target of a URI. For example, if we learned that a URI
supported voice from a hypothetical E2VOICE record, we still wouldn't know
what codecs are supported, and further SIP negotiation is required to
determine whether or not we have any in common (without an 'E2VOICE-G711'
resolution service and all the permutations that would entail). It is also
problematic to express multiple communications services simultaneously in
the service field (video streams will commonly be negotiated simultaneously
with voice streams - if all of the possible concurrent combinations of
communications services need to be flagged simultaneously in the service
field, interpreting the field could become quite complex and the IANA
registry quite lengthy). Similarly, support for extensions (the
Required/Supported) mechanisms determines whether or not two endpoints can
communicate, but expressing extension support in the service field probably
isn't feasible. Incorporating this into ENUM would be very difficult, but
fortunately it is totally unnecessary if you defer request routing and
capability negotiation to SIP. I'm afraid we may only build partial overlap
with SIP, rather than new features, into ENUM by creating complex service
fields.

A more detailed exploration of these points is given in the draft,
especially in sections 3.4 and 3.5.

Finally, let me say that I am only arguing that the above applies for SIP -
I have no idea if this sort of argument makes sense for other protocols that
are brokered by ENUM.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Sunday, February 17, 2002 1:04 AM
> To: Peterson, Jon; Peterson, Jon; 'Kevin McCandless'; [email-masked]'
> Subject: RE: [Enum] Using ENUM for SIP Applications
>
[snip] 
> 
> MY personal immediate reaction is that it would be good for the client
> looking up NAPTR records to know what SIP URI is used for 
> each family ofservices.
> 
> For example: I (as a person) might have one SIP URI for presence
> information, one used for gaming, and one for telephony -- simply because
I
> buy/get these services from different service providers, and just like
with
> email, that implies different domain names in the URI.
> 
> So, a client which is only interested in presence stuff, why open SIP
> connections to SIP URI's before knowing that SIP URI is not 
> interesting at
> all?
> 
> In some cases of course one "SIP" definition is enough, BUT, as soon as
you
> have more than one "kind" of service and more than one SIP URI, I think
> more information in the flag is needed for faster call setup.
> 
>     paf
> 

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

---

From: "Robert H. Walter" <[email-masked]>
Date: Mon, 18 Feb 2002 12:21:01 -0500

Hi Jon,

I would also like to thank you and the authors for a well written
Internet draft...

[snip]
> issue on which the people who are implementing ENUM for SIP must arrive at

If I understand you correctly, you are recommending option "2" and that
all SIP communications service discovery be performed via the SIP protocol.
This approach simply moves the "awkward and slow mechanism" of selecting the
appropriate communications service into the SIP protocol or limits the
ability of SIP to support multiple service providers for a single telephone
number.

Certainly the requesting application knows the type of communications session
it wishes to establish (i.e. Voice, Instant Messaging, etc.) prior to sending
the SIP request.  The "ENUM Resolution Protocols and Services" I-D proposes
a solution for unambiguously locating a SIP communications service from
multiple service providers through the definition of new ENUM resolution
services like E2VOICE, E2IM, etc.  This prior knowledge can be used to avoid
an "awkward and slow mechanism" and quickly establish the AoR associated with
the communications service.  Establishing the service provider specific AoR
prior to the SIP request greatly facilitates SIP based capability negotiation
between two interested parties that's more likely than not, to result in a successful
session.

For those of you who have not read "ENUM Resolution Protocols and Services"
it is available at:

http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt

Bob Walter
NetNumber, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 18 Feb 2002 21:28:35 +0100

--On 2002-02-18 04.42 -0600 "Peterson, Jon" <[email-masked]>
wrote:

> Finally, let me say that I am only arguing that the above applies for SIP
> - I have no idea if this sort of argument makes sense for other protocols
> that are brokered by ENUM.

Probably many.

This is one of the strongest arguments why I think separate documents which
talk about each one of the protocols.

I only have one input to your text: I think it will be impossible to tell
people to only have one SIP URI in ENUM. Reason for that is because one
will probably have access to more than one SIP server (one private and one
in the office for example) and I bet that some operators refuse to add
information about the other.

I.e. I have more than one email address, and will probably have more than
one SIP URI.

Hmmmm....I think I already have three when thinking about it out of which
only one is reachable over the public Internet ;-)

So, I would like to rephrase what you wrote by asking: If one have two SIP
URI's, should there be any differentiation between them in the NAPTR? Not
even if they are used for different "services" (whatever that means)?

   paf