Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Mar 2003 15:12:34 -0500

Let me try to clear up a few things here.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Friday, March 07, 2003 4:27 AM
> To: Jon; Richard; Rudi
> Cc: [email-masked]
> Subject: VOVI draft 'voice:sip' enumservice
> 
> 
> Hi Folks,
>    (Thread re-named - I assume that this is the issue ?)
> 

The issue is with any enumservices that identify capabilities of SIP URIs,
presumably for the benefit of some sort of SIP-based client.

> How does the enumservice 'voice:sip' in the vovi draft break SIP?
> I'm bemused, as it works for me - I've used it.
> 

This is an important point. There is no question that there are numerous
cases in which this enumservice could be deployed in which it will work, and
break absolutely nothing. The most obvious is when it is the only SIP
enumservice record in an ENUM resource record set, and the only device(s)
you have just do voice and register at that URI. That is, if you have one
record that identifies 'voice:sip', then when a client acquires it, provided
it supports voice capability, it will place a request to the resulting URI,
and everything works.

One case in which this doesn't work (though there are others, some of which
I've discussed earlier): if, for whatever reason, you boot up on IM client,
and register it at your SIP address of record (the one represented by a
'voice:sip' record in ENUM), then your AoR now effectively has an IM
capability, at least for the moment. If someone who only had SIP IM
capability subsequently downloaded your ENUM record, though, they would not
find an 'im:sip' record, and subsequently they would assume they are unable
to contact you. This is breakage for SIP - when I register a device, I
expect people to be able to reach it. The user would presumably also have to
put an 'im:sip' record in the DNS when they register the IM device under
their AoR in order for this ENUM-based capability negotiation scheme to
work. Then we begin to get into the differences between real-time
registrations and DNS publications, synchronization between SIP and ENUM,
etc.

The only way to rectify this for AoRs is to apply a policy contraint at a
register than prevent registration of non-voice devices under the AoR
identified by the 'voice:sip' enumservice. That seems unenforceable to me
for several reasons, and even if it were enforceable it would also be
breakage for SIP.

The conclusion has to be that one cannot publish an AoR associated with a
'voice:sip' ENUM resource record; it has to be a contact address, not an
AoR. And THAT is the real problem - the publication of contact addresses in
ENUM. More on that below...

> My SIP hard 'phone is a single function device; it can be plugged in
> pretty much anywhere and registers itself with a SIP Service Provider.
> In the "real world", for some of the voice services provided, they
> expect to be paid. As Scott Petrack discovered, "the IETF doesn't do
> Business Relationships", so consider this an aside to explain why I
> have two service-specific accounts.
> 
> My VirtualPC fires up and handles only IM - it doesn't have a microphone
> connected so it doesn't support RTC. It registers itself with another
> SIP Service Provider; this fine bunch don't have my credit card info.
> Until I can fathom out how to get a microphone and RTC working in
> VirtualPC, the capability of the device(s) behind this SIP registration
> is not going to change soon either.
> 

Again, I invite you to sign up for FWD or iptel.org, two free and painless
SIP services that will accept whatever registrations you'd like.

And thus I still don't understand why you need to have two service-specific
accounts, why your devices for one capability need to register in one
places, and devices for another capability need to register in another
place. If you only -want- certain capabilities to be available at certain
identifiers for you, that makes sense - but then, why put both identifiers
in ENUM, and make them all available for everyone there? Either you want
people to be able to reach these devices or not.

The point being, your devices are not forced to register anywhere, and
registrars are not rejecting cross-domain subscriptions, or something - and
even if they were, you can just put both your AoRs under a single iptel.org
AoR, if you want both to be available in SIP (go back to the first bullet
point in my original mail in the thread for more about this). Obviously,
this is orthogonal to whether or not your VirtualPC can support voice or
not; there's no technical or policy impediment to registering both of your
devices under a single AoR.

> These *ARE* single function devices - whilst there are a lot of people
> "out there" with multi-function devices (e.g. .NET Messenger with RTC
> and IM support), those of us with hard 'phones have a defined service
> profile; this will not change short of re-flashing the 'phone. This is
> not a highly dynamic entry, at least not anytime soon.
> 

I also have a hard phone, yes, and it is similarly just a phone. That's not
a point of contention - there are single function devices in the world. The
fact that there are multi-function devices is an important part of overall
puzzle about the SIP enumservice, but is unrelated to the specific points
we're discussing here.

> Note that even if I register several 'phones with the same AoR, they're
> all just voice terminals. I had thought that what goes into ENUM is the
> AoR, not the individual contact URIs. However, I've been convinced that
> a contact URI would work as well; I learn.
> 

Right, now we're getting to the point - publishing contact URIs in ENUM is
what you have to be doing in order for these URIs to have capability as
such. It's also what I most vehemently oppose. The reasons that I am opposed
this were the subject of my first mail in this thread (in which I presented
four specific reasons why this is bad). If the authors of "vovi" really
think that contact URIs should be published in ENUM (and I think you more or
less have to be committed to this), I think at least those four bullet
points need to be addressed, though they are not exhaustive.

> Thus, if you try to IM to this 'phone, you will waste your time. It
> doesn't support T.38 so you can't fax to it - it just does voice. If I
> as a Registrant want to give a hint that you will only be successful if
> you do an INVITE with a voice media offer, then I can't see how this
> breaks SIP, or is even unhelpful.
> 
> If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip',
> that's fine. Support for this enumservice consists solely of ignoring
> the hint and treating it as a standard 'sip' enumservice.

Sure - in my problem case above, it might be tempting to say that when an
application with a SIP IM capability looks at the ENUM resource records for
SIP, it should be willing to try sending an IM to the 'voice:sip' entry. If
you agree with that, though, then I think you basically agree with my
proposal to have a 'sip' enumservice without any capability semantics. That
hint is semantically disregarded by SIP applications.

> 
> Of course, anything to the account I have registered my 'phone with other
> than an INVITE with a voice media offer will be rejected . The 'phone
> fully supports 3261 but does not engage in all possible (non-media)
> sessions. It's a 'phone.
> 
> Similarly, if anyone wants to try to INVITE my Virtual PC to a voice
> session, it will be rejected. It's also 3261 compliant, but only handles
> an IM session, due to my incompetence.
> 

That's all true, yes. Of course, if you just registered the two at the same
AoR, then attempts to contact you for either capability at that AoR would
succeed.

> Now, if anyone thinks that giving this hint is a BAD choice on the part
> of the registrant, that's a valid opinion, and there are many privacy
> issues with ENUM that we need to spell out (not just in this draft) so
> that folks can make informed choices on the information they publish.
> No-one is forced to publish information that they don't want the world
> to know - we have the 'I'm not telling you any more information here'
> enumservices as well.
> 

Privacy is at least one other reason why publishing contact addresses in
ENUM is undesirable, yes. Superficially, the concept of the hint isn't
anathema to privacy, but since it entails publication of contact addresses
it is troublesome.

> I still don't understand how this draft is not aligned with IETF
> standards, specifically 3261. I'm willing to believe that SIP with
> CallerPrefs could allow a client to negotiate a kind of service;
> I'm a little surprised that support for this is REQUIRED as the only
> solution if we're to avoid extended offer/rejection cycles.
> 

Service negotiation goes well beyond caller prefs, which as you surmise is
not REQUIRED. See my previous note, especially the fourth bullet point, on
why primitives like 'voice' aren't really suitable for SIP capability
negotiation. Incidentally, in parallel forking cases that are likely when
scanning multiple devices for a given capability, the offer/answer cycles
occur simultaneously, and don't result in any appreciable delay.

> all the best,
>     Lawrence
> -- 
> --------------------------------------------------------------
> ---------
> Roke Manor Research    : This information is provided "as is" 
> and is not
> <mailto:[email-masked]>: intended to create any contractual or legal
> <tel:+441794833666>    : relationship.
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 8 Mar 2003 13:55:45 +0000

Hi Jon, folks,
  Thanks for the useful points - I think that they help to zero
in on the problem - without which we can't fix it.

Herewith my response - I apologise for quoting all of Jon's text
below, but these ARE important points that should be read in
conjunction.

============
I think that the key points here seems to be the use of contact 
addresses, and assumptions that there is some protocol feature 
required to check that an avowed Registrant policy is being enforced, 
and that the ENUM client MUST follow the hints published. My bad, as 
none of these these are intended in the VOVI draft.

In the VOVI draft, there is NO protocol feature proposed or required 
of SIP. There is NO check that, if an end user says that this account 
is associated with RTC, all of the contacts represented by this AoR 
ARE capable of RTC. The end user can make a mistake or lie and 
register one kind of device "under" an account that they tell the 
world is actually associated with another kind of service.

It seems (to me) perfectly valid for a SIP subscriber to choose to 
register an IM device, for example, under an account that, ->in 
ENUM<-, is shown as being associated with only voice teleservice. 
This means that SIP users (who have the URI already containing this 
AoR) may negotiate any supported session (including IM), whilst those 
using ENUM will normally only select this account if they intend to 
place a voice call.

At the extreme, there is no compulsion on a Registrant to install a 
NAPTR referring to a particular SIP account at all; thus ENUM users 
won't use that account, whilst SIP users who have the AoR will 
continue to use it. IMHO, this doesn't break either SIP or ENUM. I 
assert that ENUM is a pure opt-in service and the Registrant is free 
to select the information they wish to publish in it (and the 
information they choose NOT to publish). SIP is no different from 
other information here.

The label that a particular account and its AoR is associated with 
one kind of service is a hint that a Registrant MAY choose to put 
into ENUM, and that the querying program MAY choose to present to its 
end user or to act on if the end user has pre-specified their policy.

The Registrant MAY instead choose NOT to give a hint that a 
particular subset of communication session types may be associated 
with a particular account and AoR; in this case they just use the 
"pure" sip enumservice. Apart from the hint the information presented 
is exactly the same.

Similarly, the querying end user's program MAY choose to ignore a 
hint within a NAPTR and treat this as a standard SIP account capable 
of negotiating and initiating any communications session; they can 
treat this NAPTR as if it were a standard 'sip' enumservice.

There is no compulsion here, either to publish a NAPTR with a hint as 
to the service expected from this account or to use this hint when 
receiving the NAPTR. Nothing is mandatory.

It is equally possible for a determined Registrant to put a contact 
URI into either a NAPTR with 'sip' enumservice OR with a 'voice:sip' 
enumservice; it's dumb, but I trust we don't expect a DNS Service 
Provider to check somehow before publishing the domain data in DNS in 
these cases.

----

I agree that when an AoR is installed in a NAPTR it does not 
intrinsically have any teleservice capability associated with it. The 
teleservice capability of the end systems registered "behind" that 
AoR defines the communications session that may be negotiated via 
this account.

I'm willing to believe that communication session type can be 
negotiated within the SIP process once it has begun, and that 
starting the SIP process can expose the teleservice capability of end 
units associated with an AoR in a controlled manner.

I agree that if a particular account is associated with a set of end 
systems that have varying capability then the use of teleservice- 
specific hints associated with the AoR is inappropriate, due to the 
intrinsic latency in updating DNS and so the ENUM data being "out of 
date".

However, for those cases where (i) an AoR is associated over the long 
term with a set of end systems that have only a single function, and 
(ii) the Registrant chooses to register only devices that have a 
specified teleservice capability under this particular AoR, then 
giving a hint to this capability within ENUM seems (to me) to be both 
possible and may be useful *TO A QUERYING END USER*.

If a SIP UAC is all that will process ENUM data, then as pointed out 
there is little need for ENUM as the end user may have a SIP URI 
already, and any data in ENUM is intrinsically redundant.

However, I suggest that there could be other programs that query, 
receive and process this information. The "Generic ENUM Client" is an 
example of a program that can process the returned results, possibly 
display them to an end user so that they select a particular option 
and so "break the tie" in the DDDS processing round, and then fire up 
the appropriate communications program with the resulting URI.

That program may well be a SIP UAC; however, the SIP UAC will not 
have checked ENUM at all, as this has been done by an external ENUM 
client.

In the specific case of a NAPTR with 'voice:sip' enumservice, it is 
possible for the Registrant to lie, indicating an account that only 
has devices registered "behind" the AOR that do not support voice. 
The end user's SIP UAC will fail in its attempts to initiate a voice 
call.
Will the end user be unhappy? - possibly. Is this a protocol issue? - 
I don't think so. If it were, then we'd need protocol mechanisms to 
block someone putting an incorrect MX record or even an incorrect SOA 
record into DNS. Equally, we'd require a Telephone Service Provider 
to check that an entry in the White Pages that indicated a Fax 
machine really DID have a fax machine plugged in.

It would seem that these applicability points are not clear in the 
current draft. Given that these can be spelled out in the "other 
information that the authors deem useful" section of the 
registration, is there still an objection on technical grounds (i.e. 
why won't it work?).

============

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 9 Mar 2003 20:13:20 +0000

Hi Jon, folks,

Re-reading the response from Jon to my re-named thread posting, I feel that
a more point by point reaction may help - my more general response seemed to
leave exactly the same misunderstandings that I was trying to dispel.

<snip - I said that 'voice:sip' works, so why do you think it doesn't?>
>   registrations and DNS publications, synchronization between SIP and ENUM,

I summarise this as:'If an IM-capable device registers behind an AoR
that is labelled with 'voice', then an end user, when retrieving the
published ENUM data, will not choose that AoR if they have a SIP client
that is only capable of IM. This is breakage for SIP'.

It is true that the end user might assume that they are incapable of
contacting a Registrant using this SIP AoR, but that may be the
intention of the Registrant in publishing the information in this way;
they are, in effect, stating that they only want voice calls via this
AoR.

A SIP UAC is still capable of contacting the Registrant's SIP UAS,
*IF THEY ALREADY HAVE THE AoR*, so this does not break SIP.
To summarise, it still works fine.

>   ENUM. More on that below...

8-()

It does not require any policy constraint on the part of the SIP 
infrastructure.
If a Registrant chooses to SIP register a device that is capable of another
service than the one with which the AoR is labelled in ENUM, then they may
intend that information on this capability is not published in EMUM.
They may have made a mistake. In either case, this does NOT stop SIP UACs
working, nor does it require a change to SIP Registrar operation of any kind.

We do not believe that publication of contact addresses is appropriate in ENUM.
You continue to believe that we are actually proposing this, despite our
protestations to the contrary, as you think that to do otherwise would
require policy changes to SIP infrastructure to exclude inappropriate
registrations against an AoR that was labelled with a particular capability.

All I can do is to re-iterate our statement that AoRs are the only appropriate
SIP entities to publish in ENUM, due to their long-term nature.

Given the nature of ENUM, it is not possible to block a Registrant from
publishing a contact address (or some AoR with which, for some reason,
they have only a momentary association and then discard forever).
We just don't think it's a good idea for the often repeated DNS update
latency reasons.

>   devices under a single AoR.

My reasons for having two accounts, each of which I use for registrations
of teleservice-specific devices, is administrative (i.e. non-technical) and
so not the subject of standardisation, except insofar as I am not allowed to
do this by a draft including such labelling being blocked by the IETF.

I understand that I could combine the two accounts under a third, or to
register one account under the other. In so doing, the resulting "top"
account would no longer be teleservice-specific, and so it would be
inappropriate to label it so.

However, I contend that it is perfectly possible to have two accounts
and to use each one in a service-specific manner, and thus being able
to label each one accordingly is appropriate. If others do not make this
choice but instead decide on a single multi-capability account or simply
choose not to label the entry, they won't have a use for a service-
specific label and so will use the entry without it (i.e. use a "plain"
'sip' enumservice).

I don't see how that means that my choice, and wish to indicate which
account I would like folks to use for voice calls, is unacceptable.

BTW, I'm not sure how your bullet 1 on provisioning multiple URIs in
ENUM causing synchronisation issues that arise with (undesirable)
redundancy fits here as these are long-term (and so stable) AoRs?

>   points need to be addressed, though they are not exhaustive.

Again, if by my purely administrative actions I have two accounts, one
I use exclusively for voice capable SIP registrations with the other
that I use exclusively for IM capable SIP registrations, how does that
state that I must mean that I'm installing contact addresses? The AoRs
have no intrinsic technical service capability associated with them
OTHER than that I assert by my administrative actions. I repeat, I am NOT
suggesting the use of SIP contact addresses in ENUM.

I was reminded that it would be possible to publish contact URIs in ENUM;
OK, it is possible for someone to do this. We all agree that this is a bad
idea as you quite correctly point out that contact addresses may be short
term.

>   hint is semantically disregarded by SIP applications.

If a Registrant chooses to label a SIP AoR with a hint as to its use,
and I as an end user choose to ignore this advice, then there is no
enforcement other than a SIP rejection.

Outside of California, I can smoke; in so doing I ignore the label
warning me that I will drop dead but only after I have poisoned the
entire population. Is this wise? No. Will I be arrested for so doing?
We'll see in SF.

Seriously, if there is only one entry in ENUM with a SIP AoR, and
this is labelled with 'voice', then it may be tempting to ignore
this label and try to use the AoR for other kinds of communication.
In so doing, the end user should not be surpised if an attempted SIP
session results in a rejection. If I dial a phone number labeled as
voice and attempt to send a fax, again, I should be unsurpised if
a fax doesn't pop out of the callee's ear.

The hint indicates a preference on the part of the Registrant. It
SHOULD be considered by the end user when selecting between entries
with different SIP AoRs, but it's possible for them to ignore this
preference. ENUM can't block their actions subsequent on receiving
the entries; if a DDDS implementation allows an end user to "break
the tie" then this allows the end user to select any of the available
entries.

The only question that remains is whether or not a DDDS implementation
with knowledge of local capabilities will display an entry to the end
user if its knowledge leads it to believe that it cannot support the
labeled communication type.

Is that the whole issue here?

<snip -- there may be privacy issues - we agree>

>   occur simultaneously, and don't result in any appreciable delay.

In response to the "doesn't result in any appreciable delay", I have
two comments:
*  You have obviously not tried to use some of the early SIP
    implementations on a 2G/2.5G 'phone :)

* An ENUM lookup and resolution is a pre-call activity, particularly if
   the end user is involved in making a selection so "breaking the tie"
   in the final round of DDDS processing. It's pretty quick, with just
   one round trip of a short packet (in fact for some GPRS services, it
   isn't even charged :).

   A SIP resolution that leads into a call may well be perceived as a
   mid-call activity.

   Whether or not this is the case remains to be seen, until which time
   I'm conservative in terms of what constitutes an appreciable delay.

Re. the points in your earliest posting, I will respond to that shortly.

all the best,
   Lawrence