Subject: Re: [sipcore] rfc4244bis: what is an AoR?

From: Shida Schubert <[email-masked]>
Date: Thu, 5 Nov 2009 22:54:12 +0900

One of the co-author (Hans Eric) actually pointed out
that toll-free number can be addressed with the current spec.

  According to 4244bis, 'mp' is added when the target user
changes.

  With toll-free, after the call is routed to a toll-free any  
retargeting
after that should indeed be targeted towards the same user
so the target user isn't really changing even if the R-URI is
rewritten, unless of course call is diverted to a completely
different user.

  So with this in mind let's look at the example John had
previously mentioned on the list.

  - Example 1: Call from A to B, which is forwarded to freephone  
number C, which resolves to D, which resolves to contact E.

This would look like the followings.

  H-I: B; index=1
  H-I: C; index=1.1;mp=1
  H-I: D; index=1.1.1
  H-I: E; index=1.1.1.1; rc

  C and D represents the same user so, E can simply look
at the last 'mp' tagged entry to see if the call was made to its
toll-free alias.

- Example 2: Call from A to freephone number B, which resolves to C,  
which is then forwarded to D, which resolves to contact E.

  H-I: B; index=1
  H-I: C; index=1.1;
  H-I: D; index=1.1.1;
  H-I: E; index=1.1.1.1;rc

  Here if C and D are both expecting a call via
toll-free number(b), say office in Dallas and
office in NY representing the same company,
  then they are both the same user toll-free is
trying to contact, so there is no 'mp' tag and E
looks at the first H-I entry.

  To identify whether the call came in via the service number,
one would look for the last 'mp' tagged entry OR if there is
none look at the first 'hi-entry'.

  Any comments?

  Regards
   Shida

On Oct 26, 2009, at 7:36 PM, Ian Elz wrote:

> 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?
>
>
>
> Elwell, John wrote:
>> 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.
>
> Also, Shida said:
>
>> 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
>
>
>> John
>>
>>> -----Original Message-----
>>> 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
>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
>>>
>>> This is quite an interesting idea. Probably wider in scope than
>>> History-Info, but it sounds like a good way to tackle the problem.
>>>
>>> On Oct 18, 2009, at 24:16 , Shida Schubert wrote:
>>>
>>>> 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
>>>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 5 Nov 2009 16:56:02 +0100

> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 05 November 2009 13:54
> To: Ian Elz
> Cc: Paul Kyzivat; Elwell, John; François AUDET; SIPCORE; 
> Hadriel Kaplan; Dean Willis; ELWELL John; Keith Drage
[JRE] I think this should have an mp tag, because the entity doing the forwarding would normally apply the mp tag when forwarding. The fact that earlier the request had been targeted at a freephone number is unlikely to influence forwarding behaviour (and indeed might not be known to the entity doing the forwarding), so the mp tag would be added.

John

> and generally

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 5 Nov 2009 17:50:12 +0100

Schilda, John,

I agree with John that in the second case the mp tag should be added when the forwarding occurs.

The first example shows an interesting case as the original number is not the freephone number. In this case the answering system would need to look through the H-I entries to find a number which it recognizes.

I am unsure whether the translation from the freephone number to the new identity should be considered to be the same user. At the time that the particular INVITE occurs then freephone number is a 'proxy identity' for the translated identity. [I know that this is not a very good term.] The next INVITE to the same freephone number could translate to a totally different number but that is largely irrelevant.

If we take the approach that when a freephone number translates it does not include an mp tag then we need to ensure that this will not result in other issues; e.g. counting of number or times the INVITE has been forwarded.

I don't think that this will be an issue. The alternative is to have another tag which distinguishes translations from mapping. Not sure that this will help though as you may end up with many different tags.

I will look back through the draft to refresh my memory as to the initial issues.

Ian

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 05 November 2009 15:56
To: Shida Schubert; Ian Elz
Cc: Paul Kyzivat; François AUDET; SIPCORE; Hadriel Kaplan; Dean Willis; ELWELL John; Keith Drage
Subject: RE: [sipcore] rfc4244bis: what is an AoR?

> Cc: Paul Kyzivat; Elwell, John; François AUDET; SIPCORE; Hadriel 
>   One of the co-author (Hans Eric) actually pointed out that toll-free 
> number can be addressed with the current spec.
> 
>   According to 4244bis, 'mp' is added when the target user changes.
> 
> retargeting after that should indeed be targeted towards the same user 
> rewritten, unless of course call is diverted to a completely different 
> user.
> 
>   So with this in mind let's look at the example John had previously 
> mentioned on the list.
> 
>   C and D represents the same user so, E can simply look at the last 
> 'mp' tagged entry to see if the call was made to its toll-free alias.
> 

John

>   H-I: E; index=1.1.1.1;rc
> 
>   Here if C and D are both expecting a call via toll-free number(b), 
> say office in Dallas and office in NY representing the same company,
>   then they are both the same user toll-free is trying to contact, so 
> there is no 'mp' tag and E looks at the first H-I entry.
> 
>   To identify whether the call came in via the service number, one 
> would look for the last 'mp' tagged entry OR if there is none look at 
> the first 'hi-entry'.
> 
>   Any comments?
> 
>   Regards
>    Shida
> 
> >>>> another address (PSAP in NYC to PSAP in NJ) but will never be 
> >>>> translated again to another name(911 to 411).
> >>>>

---

From: Shida Schubert <[email-masked]>
Date: Sat, 7 Nov 2009 22:00:17 +0900

John;

  My comments inline...

> [JRE] I think this should have an mp tag, because the entity doing  
> the forwarding would normally apply the mp tag when forwarding. The  
> fact that earlier the request had been targeted at a freephone  
> number is unlikely to influence forwarding behaviour (and indeed  
> might not be known to the entity doing the forwarding), so the mp  
> tag would be added.
>
> John

  If C and D represents a different user I would agree with you
but if it represents for example two different office location from
the same company which have freephone number B as their
alias, I think it really represents the same user so 'mp' tag
shouldn't be added.

  Regards
   Shida

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 8 Nov 2009 23:08:04 +0100

> Sent: 07 November 2009 13:00
> To: Elwell, John
> Cc: Ian Elz; Paul Kyzivat; François AUDET; SIPCORE; Hadriel 
[JRE] I agree. In the case where it is the same user, ideally the two phones would have the same AoR, so there would be no mapping. However, in practice they are often different AoRs, so the situation can arise that there would be mapping from one AoR to another AoR, both representing the same "user". The question is, whether the entity doing the forwarding is aware that the two AoRs represent the same user, in order to suppress the 'mp' tag in this case.

As I explained to you face-to-face this evening, I think the present proposal is better than earlier proposals, and that with careful wording we can define the conditions for inserting the two tags reasonably precisely such that different implementations will use them correctly. However, I am convinced there will be some cases (perhaps relatively uncommon) where interpretation of the received HI as described in the draft (e.g., to find the freephone number) will not work quite as expected. Maybe the answer is to search the HI looking for a URI that you recognise as a freephone number - but you don't need to enhance HI to do that.

John

---

From: Shida Schubert <[email-masked]>
Date: Mon, 9 Nov 2009 14:14:32 +0900

My comments inline..

On Nov 9, 2009, at 7:08 AM, Elwell, John wrote:

> [JRE] I agree. In the case where it is the same user, ideally the  
> two phones would have the same AoR, so there would be no mapping.  
> However, in practice they are often different AoRs, so the situation  
> can arise that there would be mapping from one AoR to another AoR,  
> both representing the same "user". The question is, whether the  
> entity doing the forwarding is aware that the two AoRs represent the  
> same user, in order to suppress the 'mp' tag in this case.
>
> As I explained to you face-to-face this evening, I think the present  
> proposal is better than earlier proposals, and that with careful  
> wording we can define the conditions for inserting the two tags  
> reasonably precisely such that different implementations will use  
> them correctly. However, I am convinced there will be some cases  
> (perhaps relatively uncommon) where interpretation of the received  
> HI as described in the draft (e.g., to find the freephone number)  
> will not work quite as expected. Maybe the answer is to search the  
> HI looking for a URI that you recognise as a freephone number - but  
> you don't need to enhance HI to do that.

  Sure this is one can do without the enhancement, but enhancement
makes it easier to find the hi-entry that is of concern and addresses  
most
of the scenarios surrounding service number.

  Generally there are multiple AoRs mapped to a service number and it
is unlikely that call to a service number forwarded to an AoR will get  
forwarded
farther but there is always a corner case.

  For example, a call may get routed to a closest call-center/ 
operation center
based on geographical location, if the destination is busy as all the  
operator
is on call, a call may get routed to a different location where call  
can be
  handled right away but generally I think the call gets in the queue  
instead.

  Anyhow, we can add a descriptive text showing that "mp" tag will  
make the
search of service number more efficient and suggest that UAS will search
for the service number in other "mp" tag entry in case it's not in the  
last "mp"
entry to catch the corner cases you described above.

  Regards
   Shida