Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?)

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 1 Oct 2009 10:33:54 +0200

When would this RUPDATE be sent?
 
Could you provide an example call flow, please.
 
Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Dean Willis
Sent: Tue 9/29/2009 5:50 AM
To: Paul Kyzivat
Cc: SIPCORE
Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?)

On Sep 28, 2009, at 7:41 PM, Paul Kyzivat wrote:

> Dean,
>
> IIUC you have just reinvented Jonathan's loose routing registration 
> proposal.
>
>      

Well, I'm trying to take a slightly different approach to it, 
primarily by applying it to the wildcard registration problem. I think 
I've also eliminated all the guesswork on subcases, making proxy 
behavior arguably more deterministic than it might have been in 
Jonathan's original proposal. And the  questionable usage of Supported 
and Requires for negotiation is right out. There's also no need for 
confusing discussion of GRUU minting in the UA.

The cleanest approach, in my current humble opinion (IMCHO), is to add 
a new SIP method that registers a route (or maybe multiple routes)" 
instead of registering a contact. We might think of this as analogous 
to BGP UPDATE route advertisements. I propose the RUPDATE method name 
for SIP.

So, IIUC, I'd say "reprised" rather than "reinvented". But yeah, it 
owes a lot to JDR's work on ua-loose-route.

Any benefit we get in terms of parameter delivery, retention of URI's 
etc. is actually just side-effect from cleaning up the semantic model 
of message routing.

--
Dean
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Shida Schubert <[email-masked]>
Date: Thu, 1 Oct 2009 20:36:55 +0900

I am really not sure why we are even discussing this.

  I believe it was because toll-free number or any other
service invocation uri(sos/directory assistance) is hard
to determine at the UAS because they can be buried in
the number of h-i entries with 'mp' tag and is not
distinguishable from any other retargets..

  But in reality at least the way things are deployed as of
now and probably for some time in the future, whether
it's freedial, emergency call or directory assistance, the
translation entity clearly knows the semantics of the
translation (that it's a route and not a contact) thus
would be able to label them as toll-free, emergency call,
directory assistance and such if there was a way to
label a URI with such semantics in RFC4244..

  Regards
   Shida

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 2 Oct 2009 05:51:24 -0000 (UTC)

> Could you provide an example call flow, please.

The PBX pbx1.example.org uses a service provider proxy spp.example.com. So
does pbx2.example.org.

pbx1 handles the engineering.example.org and science.example.org domains,
as well as phone number 888-555-0000 through 888-555-6999.

pbx2 explicitly handles the marketing.example.org subdomain and
888-555-7000 through 888-555-7999. Further, it acts as a backup route for
anything in example.org and 888-555-0000 through 888-555-9999.

So on bootup, and periodically thereafter, pbx1.example,org would send to
spp.example.com a RUPDATE (or set of RUPDATES, depending on how we define
the message) adverting that pbx1.example.org handles:
*.engineering.example.org at priority X,
*.science.example.org at priority X,
8885550* at priority X,
8885551??? at priority X,
8885552??? at priority X,
8885553??? at priority X,
8885554??? at priority X,
8885555??? at priority X,
8885556??? at priority X

Likewise, pbx2 would send rupdates for
*.marketing.example.org at priority X
*8885557??? at priority X
*.example.org at priority Y (where Y has lower precedence than X)
888555???? at priority Y (where Y has lower precedence than X)

Clearly we also need some sort of policy language that allows
spp.example.org to decide what things each of these PBXes is authorized to
update. Our existing authentication techniques should suffice for
authentication.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 2 Oct 2009 05:53:39 -0000 (UTC)

> *.science.example.org at priority X,

Ok, that should have been 8885550??? above . . .

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Oct 2009 09:13:29 -0400

Dean,

So, RUPDATE is really just what REGISTER should have been:
providing a route for reaching something responsible for a given AOR.
In principle it could *replace* REGISTER for any devices that were clued 
in to its use.

You give examples with phone numbers, but those provide unmentioned 
issues. Most notably, how you choose where to send the RUPDATE for the 
number.

	Thanks,
	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 3 Oct 2009 23:01:20 -0500 (CDT)

> In principle it could *replace* REGISTER for any devices that were clued

Yes! You have it exactly. It's not "backward compatible" in that you have
to understand RUPDATE to use it. But nodes that use RUPDATE instead of
REGISTER can still be reached by old-style devices, so it's operationally
backward compatible.

> issues. Most notably, how you choose where to send the RUPDATE for the

That, like who you would send a REGISTER to (or where your mail client
sends SMTP submission to) is a thing that must be configured.

We could always define some sort of NAPTR configuration resolution method,
but that's a different working group.

--
dean

---

From: Shida Schubert <[email-masked]>
Date: Sun, 18 Oct 2009 16:16:39 +0900

The reason why current use of "mp" tag is not
semantically correct for freephone, is because Service-URN
and free-phone is a "name" and not an "address" based on
the definition in the target-uri draft.

  I believe we need to define another tag for "name" to
"address" translation.

## Definition of address/name in the target-uri draft ##

    A name is a moniker for an entity which refers to it in a way which
    reveals nothing about where it is in a network.  In SIP, tel URI
    which doesn't represent the location of the entity is a name.

    An address is an identifier for an entity which describes it by its
    location on the network.  In SIP, the SIP URI itself is a form of
    address because the host part of the URI, the only mandatory part of
    the URI besides the scheme itself, indicates the location of a SIP
    server that can be used to handle the request.

## -- ##

  In deployment, name to name translation never happens
and generally  "name" to "address" translation is very
deterministic that entity doing the mapping/translation can
  tag the entry with confidence.

  For example, If one sends a request to PSAP using 911, directory
assistance using 411, name(411,911 or service-URN) is translated
to an address. That address may be translated numerous times to
another address (PSAP in NYC to PSAP in NJ) but will never be
translated again to another name(911 to 411).

  Furthermore, entity/organization that is expecting to be reached
by name usually knows what name it will be reached by, so having
the ability to distinguish one service to another is probably not
necessary but having the ability to tag "name" to "address"
translation, I believe is very helpful.

  Any thoughts?

  Regards
   Shida

On Sep 25, 2009, at 3:48 AM, Francois Audet wrote:

> Other idea?
>
> (I really don't care personally about "freephone"...)
>
>> -----Original Message-----
>> From: Hans Erik van Elburg [mailto:[email-masked]]
>> Sent: Thursday, September 24, 2009 11:48
>> To: Audet, Francois (SC100:3055); Elwell, John; Shida
>> Schubert; Jonathan Lennox; [email-masked]; Hadriel Kaplan;
>> Dean Willis; Elwell, John; Keith Drage
>> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
>>
>> Yes got that, but that does not justify a service specific
>> tag in  4244bis.
>> /hans erik
>>

---

From: François AUDET <[email-masked]>
Date: Sun, 18 Oct 2009 07:37:06 -0700

This is quite an interesting idea. Probably wider in scope than  
History-Info, but it sounds like a good way to tackle the problem.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 09:12:35 +0200

But in actual fact, any E.164 number is a name, so the tag would apply to any E.164 to SIP URI translation. Is this helpful?

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of François AUDET
> Sent: 18 October 2009 15:37
> To: Shida Schubert
> Cc: Jonathan Lennox; [email-masked]; Hadriel Kaplan; Dean 
> Willis; ELWELL John; Keith Drage

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2009 19:33:03 -0400

> But in actual fact, any E.164 number is a name, so the tag would apply to any E.164 to SIP URI translation. Is this helpful?

Yes, any E.164 number is a name, even if it is embedded in a SIP uri 
containing a domain name. (Its quite likely the domain name doesn't 
reflect the "owner" of the E.164 number, just a convenient server that 
will hopefully figure out what to do next based on the number.)

Of course, once upon a time phone numbers *were* addresses, and were 
routed digit by digit. But that time is over. Similarly, the domain 
names in SIP URIs are *name*s, not addresses. And the IP addresses are 
actually names too, ... What's a name and what's an address is a matter 
of perspective and layering.

So, to go this will will require careful definition of the distinction 
in this context.

> In deployment, name to name translation never happens

That's not really true is it? IIUC, its pretty normal for a "name" like 
1-800-666-1111 to be translated to another name,like 1-212-555-1234, 
which then must be routed to a responsible server.

	Thanks,
	Paul

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 26 Oct 2009 11:36:19 +0100

All,

Paul is correct in the name to name translation.

As well as the basic translation that Paul identified it is also common to translate from one 'freephone type' number to another. This occurs where a call answering service has multiple answering locations and the specific answering location is determined based upon identity of the caller, date/day/time etc.

When the call answering service is required to handle calls from multiple different 'freephone' numbers then it is often easier to have one number which defines the answering location and another which is the 'dialed' number which translates to the number, or numbers, which define the call handling. In effect a hierarchy can be using these numbers which translate to each other.

I use the term 'freephone type' as freephone relates to one charging scenario where there are other charging scenarios defined in different regulatory regimes, local call rate, national call rate and a plethora of different premium rates. All of these are logically handled in a similar fashion.

The ISUP PSTN network allows the provision 2 different numbers to the called party, original called party number and redirecting number. The redirecting number is the last identity which performed a diversion of redirection. The original called party number is the number dialed by the caller ( as modified by the network to make is a standard format, e.g. national or international number).

For H-I we need to be able to replicate at least the ability to identify the original number/identity called and the last identity which diverted/redirected the call.

The intermediate information which is not available in ISUP is also useful, particularly when some data is incorrect, as it allow tracing of how a call was handled.

Ian Elz

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 20 October 2009 00:33
To: Elwell, John
Cc: Jonathan Lennox; François AUDET; [email-masked]; Hadriel Kaplan; Dean Willis; ELWELL John; Keith Drage
Subject: Re: [sipcore] rfc4244bis: what is an AoR?

> But in actual fact, any E.164 number is a name, so the tag would apply to any E.164 to SIP URI translation. Is this helpful?

Yes, any E.164 number is a name, even if it is embedded in a SIP uri containing a domain name. (Its quite likely the domain name doesn't reflect the "owner" of the E.164 number, just a convenient server that will hopefully figure out what to do next based on the number.)

Of course, once upon a time phone numbers *were* addresses, and were routed digit by digit. But that time is over. Similarly, the domain names in SIP URIs are *name*s, not addresses. And the IP addresses are actually names too, ... What's a name and what's an address is a matter of perspective and layering.

So, to go this will will require careful definition of the distinction in this context.

That's not really true is it? IIUC, its pretty normal for a "name" like
1-800-666-1111 to be translated to another name,like 1-212-555-1234, which then must be routed to a responsible server.

	Thanks,
	Paul

>> Cc: Jonathan Lennox; [email-masked]; Hadriel Kaplan; Dean Willis; 
>> ELWELL John; Keith Drage
>>> The reason why current use of "mp" tag is not semantically correct 
>>> for freephone, is because Service-URN and free-phone is a "name" and 
>>> not an "address" based on the definition in the target-uri draft.
>>>
>>> I believe we need to define another tag for "name" to "address" 
>>> translation.
>>>
>>> In deployment, name to name translation never happens and generally  
>>> "name" to "address" translation is very deterministic that entity 
>>> doing the mapping/translation can tag the entry with confidence.
>>>
>>> assistance using 411, name(411,911 or service-URN) is translated to 
>>> an address. That address may be translated numerous times to another 
>>> address (PSAP in NYC to PSAP in NJ) but will never be translated 
>>> again to another name(911 to 411).
>>>
>>> Furthermore, entity/organization that is expecting to be reached by 
>>> name usually knows what name it will be reached by, so having the 
>>> ability to distinguish one service to another is probably not 
>>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida Schubert; 
>>>>> Jonathan Lennox; [email-masked]; Hadriel Kaplan; Dean Willis; 
>>>>> Elwell, John; Keith Drage
>>>>> Yes got that, but that does not justify a service specific tag in  
>>>>> 4244bis.
>>>>> /hans erik
>>>>>