Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

From: "Mary Barnes" <[email-masked]>
Date: Thu, 11 Jun 2009 13:04:48 -0500

Hi folks,

We have made a few changes to this document which was submitted last
week just to tie up some loose ends and inconsistencies, some of which
Shida identified when he reviewed the -00 version. 

The following summarizes the high level changes in the
sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San
Francisco:
1) Renamed the "retarget" parameter to "target" and defined explicit
tags to reflect the various mechanisms by which a Request is retargeted.
All entries are now tagged. 
2) Updated redirect server processing as the redirect server must
capture the "target" parameter since it is the entity that knows the
specific mechanism by which the new target has been determined. 
3) Changed the privacy such that rather than removing entries based on
the various values of the privacy header, the entries are recommended to
be anonymized. 
4) Updated security section
5) Updated examples to reflect the new parameter, use loose routing and
fix errors/nits.
6) Editorial changes to remove redundant text and the convuluted text
around optionality in the non-normative sections, which is now discussed
appropriately in the context of the histinfo option tag.

The detailed changes between the versions are summarized in the
document.

If you're wanting to look at a diff, I would recommend you diff against
RFC 4244 rather than the earlier 4244bis documents. 

We'd really appreciate feedback on this approach to precisely tagging
all the entries. We believe it is comprehensive and should suffice for
all the use cases identified in the target-uri document, as well as any
others that might arise.  

Thanks,
Mary and Francois.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, June 11, 2009 12:45 PM
To: [email-masked]
Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : An Extension to the Session Initiation
Protocol (SIP) for Request History Information
	Author(s)       : M. Barnes, F. Audet
	Filename        : draft-barnes-sipcore-rfc4244bis-01.txt
	Pages           : 42
	Date            : 2009-06-11

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) request.
This capability enables many enhanced services by providing the
information as to how and why a call arrives at a specific application
or user.  This document defines a new optional SIP header, History-Info,
for capturing the history information in requests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t
xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 11 Jun 2009 22:30:44 +0200

Hi,

I think it is important to mention that there are still different
approaches regarding the target uri delivery, and that there is another
approach described in the latest version of the target-uri delivery
draft (I am not sure it appears in the archieves, though, for some
reason). Both approaches are based on History-Info, though.

We haven't yet been able to agree on an approach, so we thought the best
is to bring it to the list in order for other people to get involved.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mary Barnes
Sent: Thursday, June 11, 2009 9:05 PM
To: [email-masked]
Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi folks,

Thanks,
Mary and Francois.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 11 Jun 2009 22:32:21 +0200

Here is the link to the latest version of the target-uri draft:

http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00.
txt 

-----Original Message-----
From: Christer Holmberg 
Sent: Thursday, June 11, 2009 11:31 PM
To: 'Mary Barnes'; [email-masked]
Subject: RE: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

-----Original Message-----

Hi folks,

Thanks,
Mary and Francois.

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 11 Jun 2009 16:39:37 -0400

Hello,

Can someone please summarize the differences between the two approaches?

Thanks,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: Thursday, June 11, 2009 4:32 PM
To: Christer Holmberg; Mary Barnes; [email-masked]
Subject: Re: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt

-----Original Message-----
From: Christer Holmberg 
Sent: Thursday, June 11, 2009 11:31 PM
To: 'Mary Barnes'; [email-masked]
Subject: RE: [sipcore] FW: I-D

Hi,

Regards,

Christer

-----Original Message-----

Hi folks,

Thanks,
Mary and Francois.

-----Original Message-----

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 11 Jun 2009 16:13:16 -0500

Christer,

I reviewed the updated target-uri draft and have a few comments - well I
reviewed the diff since there isn't a summary of changes in the
document:

1) I had a lot of difficulty picking out the normative processing for
History-Info in this document. Can you summarize the differences? 

2) The reason I'm concerned about understanding how this fits with the
current normative processing is because I'm not seeing precisely when
these tags are added as the terminology is different than that used in
RFC 4244 - i.e., are these two terms equivalent:
RFC 4244:
"... hi-entry received in the request being forwarded."

target-uri:
"...hi-entry recording the incoming request URI."

There is no reference in terms of current History-Info processing as to
when in the request processing these tags are added.  

3) In particular, I'm having difficulty with this text in section 6:  
   "When a home proxy receives a request for a user or resource for
which
   is abstract location function returns registered contacts or
   configured URIs, the proxy adds two History-Info header field values.
   The first is the incoming request URI.  Since the Request-URI
   identifies a user or resource for which it has a registration or
   configuration, the Request-URI is an AOR and thus an address for the
   user.  The proxy adds a History-Info header field parameter, "aor",
   which indicates this.  Next, the proxy inserts the contact URI which
   will be contained in the outgoing Request-URI."
Currently, in RFC 4244, the proxy only adds that additional (first)
hi-entry IF there wasn't one in the incoming request, since the UAC can
initially add one when it builds the request. So, this is inconsistent
with current RFC 4244. And, I think you need to define "home" proxy -
that's not an RFC 3261 term - there is the concept of a "home" domain. 

4) There is a bug in the Syntax (section 9) - the Index is not optional
(that is an error we have fixed in the 4244bis). 

5) I'm really confused about this two-stage tagging - how does that
happen in the context of the determination of Request Targets in section
16.5 of RFC3261? Wouldn't the decisions as to the addition of the two
different tags occur at the same time and thus what is the advantage of
the defining the two tags - i.e., why not one tag for each combination?
Also, are you proposing that the addition of the tags be mandatory -
there is no normative language in the target-uri document, so it's
impossible to tell.  And, if you are proposing they be mandatory, your
ABNF syntax needs to reflect that, thus defining a single parameter with
multiple values would be necessary (which is the approach in 4244bis).

6) What is the difference (or is there a difference?) between the
functionality associated with the tags in 4244bis and the tags defined
in this document in terms of types of retargets that are being tagged?
I think this is the crux of what we need to agree - i.e., why aren't the
4244bis tags sufficient?  If there is no logical difference and it's
just the words used to define the tags, then we're very close to
agreement. 

Regards,
Mary. 

-----Original Message-----
From: Christer Holmberg
Sent: Thursday, June 11, 2009 11:31 PM
To: 'Mary Barnes'; [email-masked]
Subject: RE: [sipcore] FW: I-D

Hi,

Regards,

Christer

-----Original Message-----

Hi folks,

Thanks,
Mary and Francois.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 12 Jun 2009 08:20:20 +0200

Hi Mary,

I will look at your comments more in detail later, but just to clarify one thing:

The idea  - which you also are very aware about - IS to eventually put the normative target uri text into 4244bis. The reason we haven't done that yet is because we couldn't agree on the approache, and therefor the decission was to keep one approach in the target uri draft for now, so that we have both approaches properly documented.

Regards.

Christer

> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 12. kesäkuuta 2009 0:13
> To: Christer Holmberg; [email-masked]
> I reviewed the updated target-uri draft and have a few 
> comments - well I reviewed the diff since there isn't a 
> summary of changes in the
> document:
> 
> 1) I had a lot of difficulty picking out the normative 
> processing for History-Info in this document. Can you 
> summarize the differences? 
> 
> 2) The reason I'm concerned about understanding how this fits 
> with the current normative processing is because I'm not 
> seeing precisely when these tags are added as the terminology 
> is different than that used in RFC 4244 - i.e., are these two 
> terms equivalent:
> RFC 4244:
> There is no reference in terms of current History-Info 
> processing as to when in the request processing these tags 
> are added.  
> 
>    "When a home proxy receives a request for a user or 
> resource for which
> Currently, in RFC 4244, the proxy only adds that additional 
> (first) hi-entry IF there wasn't one in the incoming request, 
> since the UAC can initially add one when it builds the 
> request. So, this is inconsistent with current RFC 4244. And, 
> I think you need to define "home" proxy - that's not an RFC 
> 3261 term - there is the concept of a "home" domain. 
> 
> 4) There is a bug in the Syntax (section 9) - the Index is 
> not optional (that is an error we have fixed in the 4244bis). 
> 
> 5) I'm really confused about this two-stage tagging - how 
> does that happen in the context of the determination of 
> Request Targets in section
> 16.5 of RFC3261? Wouldn't the decisions as to the addition of 
> the two different tags occur at the same time and thus what 
> is the advantage of the defining the two tags - i.e., why not 
> one tag for each combination?
> Also, are you proposing that the addition of the tags be 
> mandatory - there is no normative language in the target-uri 
> document, so it's impossible to tell.  And, if you are 
> proposing they be mandatory, your ABNF syntax needs to 
> reflect that, thus defining a single parameter with multiple 
> values would be necessary (which is the approach in 4244bis).
> 
> 
> 6) What is the difference (or is there a difference?) between 
> the functionality associated with the tags in 4244bis and the 
> tags defined in this document in terms of types of retargets 
> that are being tagged?
> I think this is the crux of what we need to agree - i.e., why 
> aren't the 4244bis tags sufficient?  If there is no logical 
> difference and it's just the words used to define the tags, 
> then we're very close to agreement. 
> 
> Regards,
> Mary. 
> 
> 
> 
> Subject: [sipcore] FW: I-D

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 12 Jun 2009 10:12:42 +0200

Hi,

The biggest difference is regarding support of service-number (like toll-free/freephone) type-of services, where the Request-URI translation does not change the targeted user or resource. Without going in to the protocol differences (which aren't that big), my understanding of the functional differences are the following:

- 4244bis approach does not distinguish between service-number (like toll-free/freephone) number translation and diversion.

- 4244bis approach does not allow a service-number (like toll-free/freephone) translation for a user which belongs to another domain.

- 4244bis requires that all service-numbers for a user/company (like toll-free/freephone) must be registered (explicitly or implictly), which means that the translation must be done by an entity (normally the registrar) which has the registration information for the called user.

The target uri approach does allow translation in another domain, and does not require toll-free/freephone numbers to be registered for the called user.

So, I don't think that the 4244bis approach supports all service-numbers (like toll-free/freephone) in a sufficient way, and that it is too restrictive for no good reason. It imposes restrictions on the potential business models that are not necessary.

Regards,

Christer 

> From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
> Sent: 11. kesäkuuta 2009 23:40
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 10:38:07 +0200

Hi Mary,

Sure when we agree on the way forward we have to resolve all these detailed
procedures and conform to the 4244 language etc. But we already agreed to
integrate it into 4424bis at the moment that there is agreement about the
solution.

Regarding the two tag approach that is open for discussion, i think it is
more clean and in general pays off to separate concepts that are independent
from each other. For example a hi-entry may be routed and not be an AOR,
whereas it may also be routed and also an AOR. The decisions to be taken for
additions of these tags are independent, so there is also no need to
intertwine procedural text for them. (It is also more clear for
implementors.)

BR,
/Hans Erik van Elburg

On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes <[email-masked]>wrote:

> txt<http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00.%0Atxt>
>
> xt<http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t%0Axt>
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Fri, 12 Jun 2009 06:12:40 -0400

Christer,

The items you listed need to be supported. Our call center customers require us to pass them the original dialed toll-free number. And the same is true for call processing needs of the other call service-numbers.

Cheers,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, June 12, 2009 4:13 AM
To: DOLLY, MARTIN C, ATTLABS; Mary Barnes; [email-masked]
Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 08:57:42 -0500

Hi Christer,

The problem I have is that it is very difficult to discern exactly how you all are proposing to tag the entities in terms of core RFC 3261 functionality. Yes, we had a small thread of discussion amongst the authors with no conclusion, but Francois did put forth the exact changes proposed in RFC 4244....

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 1:20 AM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Regards.

Christer

> I reviewed the updated target-uri draft and have a few comments - well 
> I reviewed the diff since there isn't a summary of changes in the
> document:
> 
> There is no reference in terms of current History-Info processing as 
> to when in the request processing these tags are added.
> 
> (first) hi-entry IF there wasn't one in the incoming request, since 
> the UAC can initially add one when it builds the request. So, this is 
> inconsistent with current RFC 4244. And, I think you need to define 
> "home" proxy - that's not an RFC
> 4) There is a bug in the Syntax (section 9) - the Index is not 
> optional (that is an error we have fixed in the 4244bis).
> 
> different tags occur at the same time and thus what is the advantage 
> of the defining the two tags - i.e., why not one tag for each 
> combination?
> ABNF syntax needs to reflect that, thus defining a single parameter 
> with multiple values would be necessary (which is the approach in 
> 4244bis).
> 
> 
> I think this is the crux of what we need to agree - i.e., why aren't 
> the 4244bis tags sufficient?  If there is no logical difference and 
> it's just the words used to define the tags, then we're very close to 
> agreement.
> 
> Regards,
> Mary. 
> 
> 
> 
> approaches regarding the target uri delivery, and that there is 
> another approach described in the latest version of the target-uri 
> delivery draft (I am not sure it appears in the archieves, though, for 
> some reason). Both approaches are based on History-Info, though.
> 
> We haven't yet been able to agree on an approach, so we thought the 
> best is to bring it to the list in order for other people to get 
> involved.
> 
> Regards,
> 
> Christer
> 
>  
> 
> the various values of the privacy header, the entries are recommended 
> to be anonymized.
> 5) Updated examples to reflect the new parameter, use loose routing 
> and fix errors/nits.
> around optionality in the non-normative sections, which is now 
> discussed appropriately in the context of the histinfo option tag.
> 
> If you're wanting to look at a diff, I would recommend you diff 
> against RFC 4244 rather than the earlier 4244bis documents.
> 
> all the use cases identified in the target-uri document, as well as 
> any others that might arise.
> 
> Thanks,
> Mary and Francois.
> 
> or user.  This document defines a new optional SIP header, 
> History-Info, for capturing the history information in requests.
>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 09:01:37 -0500

Hi Christer,

Sorry, I hit send before I finished... 

So, I am trying to figure out why we have the differences and have difficulty because I cannot understand how this solution is fitting with core SIP processing in section 16.5 in terms of determining Request targets and am confused about the double tagging.  So, it is quite difficult to sift through the differences in the solution proposal if we are not starting from common ground in terms of how the hi-entries are added, etc. 

I will respond separately to Hans' email on the services that are suggested not to be supported by 4244bis.  

Mary. 

-----Original Message-----
From: Barnes, Mary (RICH2:AR00) 
Sent: Friday, June 12, 2009 8:58 AM
To: 'Christer Holmberg'; [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Christer,

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, June 12, 2009 1:20 AM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Regards.

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 09:11:01 -0500

Hi Hans,
 
A couple comments below [MB].
 
Mary.

________________________________

From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 3:38 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Sure when we agree on the way forward we have to resolve all these
detailed procedures and conform to the 4244 language etc. But we already
agreed to integrate it into 4424bis at the moment that there is
agreement about the solution. 

Regarding the two tag approach that is open for discussion, i think it
is more clean and in general pays off to separate concepts that are
independent from each other. For example a hi-entry may be routed and
not be an AOR, whereas it may also be routed and also an AOR. The
decisions to be taken for additions of these tags are independent, so
there is also no need to intertwine procedural text for them. (It is
also more clear for implementors.) 
[MB] This is where my major confusion is in that you say the tags are
independent, BUT where in the normative RFC 3261 processing does this
occur?  I'm confused because the logic in section 16.5 isn't
"multi-stage" (for lack of a better term), the incoming request URI is
evaluated and then the new target list is constructed   The tagging in
4244 is based on the mechanism by which a new target is determined .
The previous hi-entry (that in the incoming request) is tagged at the
point the request is being forwarded. I do agree that in the internal
processing that information needs to exist so that the tagging at the
point of forwarding the request is appropriate.  [/MB]

BR,
/Hans Erik van Elburg

On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes <[email-masked]>
wrote:

	Christer,
	
	I reviewed the updated target-uri draft and have a few comments
- well I
	reviewed the diff since there isn't a summary of changes in the
	document:
	
	1) I had a lot of difficulty picking out the normative
processing for
	History-Info in this document. Can you summarize the
differences?
	
	2) The reason I'm concerned about understanding how this fits
with the
	current normative processing is because I'm not seeing precisely
when
	these tags are added as the terminology is different than that
used in
	RFC 4244 - i.e., are these two terms equivalent:
	RFC 4244:
	"... hi-entry received in the request being forwarded."
	
	target-uri:
	
processing as to
	
	3) In particular, I'm having difficulty with this text in
section 6:
	  "When a home proxy receives a request for a user or resource
for
	which
	  is abstract location function returns registered contacts or
	  configured URIs, the proxy adds two History-Info header field
values.
	  The first is the incoming request URI.  Since the Request-URI
	  identifies a user or resource for which it has a registration
or
	  configuration, the Request-URI is an AOR and thus an address
for the
	  user.  The proxy adds a History-Info header field parameter,
"aor",
	  which indicates this.  Next, the proxy inserts the contact URI
which
	  will be contained in the outgoing Request-URI."
	Currently, in RFC 4244, the proxy only adds that additional
(first)
	hi-entry IF there wasn't one in the incoming request, since the
UAC can
	initially add one when it builds the request. So, this is
inconsistent
	with current RFC 4244. And, I think you need to define "home"
proxy -
	that's not an RFC 3261 term - there is the concept of a "home"
domain.
	
optional
	
	5) I'm really confused about this two-stage tagging - how does
that
	happen in the context of the determination of Request Targets in
section
	16.5 of RFC3261? Wouldn't the decisions as to the addition of
the two
	different tags occur at the same time and thus what is the
advantage of
	the defining the two tags - i.e., why not one tag for each
combination?
	Also, are you proposing that the addition of the tags be
mandatory -
	there is no normative language in the target-uri document, so
it's
	impossible to tell.  And, if you are proposing they be
mandatory, your
	ABNF syntax needs to reflect that, thus defining a single
parameter with
	multiple values would be necessary (which is the approach in
4244bis).

	6) What is the difference (or is there a difference?) between
the
	functionality associated with the tags in 4244bis and the tags
defined
	in this document in terms of types of retargets that are being
tagged?
	I think this is the crux of what we need to agree - i.e., why
aren't the
	4244bis tags sufficient?  If there is no logical difference and
it's
	just the words used to define the tags, then we're very close to
	agreement.
	
	Regards,
	Mary.

	-----Original Message-----
	From: Christer Holmberg [mailto:[email-masked]]
	Sent: Thursday, June 11, 2009 3:32 PM
	
	To: Christer Holmberg; Barnes, Mary (RICH2:AR00);
[email-masked]
	Subject: RE: [sipcore] FW: I-D
	Action:draft-barnes-sipcore-rfc4244bis-01.txt

http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00.
	txt
<http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00
.%0Atxt> 
	
	-----Original Message-----
	From: Christer Holmberg
	Sent: Thursday, June 11, 2009 11:31 PM
	To: 'Mary Barnes'; [email-masked]
	Subject: RE: [sipcore] FW: I-D
	Action:draft-barnes-sipcore-rfc4244bis-01.txt

	Hi,
	
	I think it is important to mention that there are still
different
	approaches regarding the target uri delivery, and that there is
another
	approach described in the latest version of the target-uri
delivery
	draft (I am not sure it appears in the archieves, though, for
some
	reason). Both approaches are based on History-Info, though.
	
	We haven't yet been able to agree on an approach, so we thought
the best
	is to bring it to the list in order for other people to get
involved.
	
	Regards,
	
	Christer

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On
	Behalf Of Mary Barnes
	Sent: Thursday, June 11, 2009 9:05 PM
	To: [email-masked]
	Subject: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt
	
	Hi folks,
	
	We have made a few changes to this document which was submitted
last
	week just to tie up some loose ends and inconsistencies, some of
which
	Shida identified when he reviewed the -00 version.
	
	The following summarizes the high level changes in the
	sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in
San
	Francisco:
	1) Renamed the "retarget" parameter to "target" and defined
explicit
	tags to reflect the various mechanisms by which a Request is
retargeted.
	All entries are now tagged.
	2) Updated redirect server processing as the redirect server
must
	capture the "target" parameter since it is the entity that knows
the
	specific mechanism by which the new target has been determined.
	3) Changed the privacy such that rather than removing entries
based on
	the various values of the privacy header, the entries are
recommended to
	be anonymized.
	4) Updated security section
	5) Updated examples to reflect the new parameter, use loose
routing and
	fix errors/nits.
	6) Editorial changes to remove redundant text and the convuluted
text
	around optionality in the non-normative sections, which is now
discussed
	appropriately in the context of the histinfo option tag.

against
	
	We'd really appreciate feedback on this approach to precisely
tagging
	all the entries. We believe it is comprehensive and should
suffice for
	all the use cases identified in the target-uri document, as well
as any
	others that might arise.
	
	Thanks,
	Mary and Francois.
	
	-----Original Message-----
	From: [email-masked]
	[mailto:[email-masked]] On Behalf Of
	[email-masked]
	Sent: Thursday, June 11, 2009 12:45 PM
	To: [email-masked]
	Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt
	
	A New Internet-Draft is available from the on-line
Internet-Drafts
	directories.

	This document defines a standard mechanism for capturing the
history
	information associated with a Session Initiation Protocol (SIP)
request.
	This capability enables many enhanced services by providing the
	information as to how and why a call arrives at a specific
application
	or user.  This document defines a new optional SIP header,
History-Info,
	for capturing the history information in requests.

http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t
	xt
<http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.
t%0Axt> 

	Below is the data which will enable a MIME compliant mail reader
	implementation to automatically retrieve the ASCII version of
the
	Internet-Draft.
	_______________________________________________
	sipcore mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 12 Jun 2009 16:11:51 +0200

Hi, 

>So, I am trying to figure out why we have the differences and 
>have difficulty because I cannot understand how this solution 
>is fitting with core SIP processing in section 16.5 in terms 
>of determining Request targets and am confused about the 
>double tagging.  So, it is quite difficult to sift through 
>the differences in the solution proposal if we are not 
>starting from common ground in terms of how the hi-entries 
>are added, etc. 

I think we should start from common ground on what functional requirements we have...

Regards,

Christer

> The problem I have is that it is very difficult to discern 
> exactly how you all are proposing to tag the entities in 
> terms of core RFC 3261 functionality. Yes, we had a small 
> thread of discussion amongst the authors with no conclusion, 
> but Francois did put forth the exact changes proposed in RFC 4244....
> 
> The idea  - which you also are very aware about - IS to 
> eventually put the normative target uri text into 4244bis. 
> The reason we haven't done that yet is because we couldn't 
> agree on the approache, and therefor the decission was to 
> keep one approach in the target uri draft for now, so that we 
> have both approaches properly documented.
> 
> Regards.
> 
> Christer
> 
>  
> 
> comments - well 
> processing as 
> advantage 
> recommended

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 09:31:52 -0500

Hi Christer,

I really think one of the biggest issues here is that 4244bis is written from the perspective of core SIP processing and entirely uses existing constructs. 

Let me make sure I understand your scenarios, as I think they're obviously all related in that your 3rd point describes how things could work with core SIP and 4244bis, which supports both your first two cases (although see my note on your 2nd case below).   I also think the target-uri solution is convoluting how the UAS that would use History-Info versus how History-Info is captured - that's likely why we getting into these never ending discussions.   

One question I have is whether or not these numbers are tel-uris? I think they have to be for any of this to work. But, if so then your 2nd bullet does violate core SIP functionality in that you cannot change the target of a Request (you can only forward) if the Request-URI does not belong to the domain of the entity doing the retargeting (per section 16.5):
   "If the domain of the Request-URI indicates a domain this element is
   not responsible for, the Request-URI MUST be placed into the target
   set as the only target, and the element MUST proceed to the task of
   Request Forwarding (Section 16.6)."

For item 1, yes the entries are tagged differently depending upon how you configure the 800 service on the home proxy. But, that's basic SIP. If you don't want to do item 3 below, then since these numbers have meaning in terms of a service, you really are talking about special flavors of URIs that the UAS can still pull out of the History-Info - i.e., you need History-Info a URI parameter, so you move the complexity to the UAS.   

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 3:13 AM
To: DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 09:34:19 -0500

Hi Christer,

I think we're entirely clear on the types of services that need to be supported. It is the mechanism that we're debating. And by mechanism, I mean how information that is meaningful to services (at a UAS) is "lost" information as a request is retargeted. 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 9:12 AM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi, 

>So, I am trying to figure out why we have the differences and have 
>difficulty because I cannot understand how this solution is fitting 
>with core SIP processing in section 16.5 in terms of determining 
>Request targets and am confused about the double tagging.  So, it is 
>quite difficult to sift through the differences in the solution 
>proposal if we are not starting from common ground in terms of how the 
>hi-entries are added, etc.

Regards,

Christer

> The problem I have is that it is very difficult to discern exactly how 
> you all are proposing to tag the entities in terms of core RFC 3261 
> functionality. Yes, we had a small thread of discussion amongst the 
> authors with no conclusion, but Francois did put forth the exact 
> changes proposed in RFC 4244....
> 
> The idea  - which you also are very aware about - IS to eventually put 
> the normative target uri text into 4244bis.
> The reason we haven't done that yet is because we couldn't agree on 
> the approache, and therefor the decission was to keep one approach in 
> the target uri draft for now, so that we have both approaches properly 
> documented.
> 
> Regards.
> 
> Christer
> 
>  
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jun 2009 10:47:55 -0400

Mary Barnes wrote:
> One question I have is whether or not these numbers are tel-uris? 
> I think they have to be for any of this to work. 
> But, if so then your 2nd bullet does violate core SIP functionality 
> in that you cannot change the target of a Request (you can only forward)

> if the Request-URI does not belong to the domain of the entity doing the retargeting (per section 16.5):

I'm not sure I follow the exact assumptions people are making here,
and as a result exactly what is meant by the particular issues raised.

If an R-URI is: sip:[email-masked] (with or without 
user=phone), then it can only be replaced by a server responsible for 
sp1.net. If the request is being handled by proxy.sp2.net then it will 
have to pass it along to sp1.net unchanged. That's clear from what Mary 
quotes above.

Things are not so clear if the R-URI is tel:+1-800-555-1234. It doesn't 
have a domain. Does that mean that nobody is responsible for it, or that 
anybody can consider themselves responsible for it? I think I can make a 
case either way. But if nobody is permitted to consider themselves 
responsible for it, then how can it ever be answered?

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 17:24:09 +0200

Hi Mary,

I do not understand what you mean with multi stage. All the tagging can be
prepared at the time that the translation is done and added at the time that
4244 suggests the H-I to be added. If the current text suggests otherwise,
then we might need to fix that.

BR,
/Hans Erik van Elburg

On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes <[email-masked]> wrote:

>  ------------------------------
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* Friday, June 12, 2009 3:38 AM
> *To:* Barnes, Mary (RICH2:AR00)
> *Cc:* Christer Holmberg; [email-masked]
> *Subject:* Re: [sipcore] FW: I-D
> occur?  I'm confused because the logic in section 16.5 isn't "multi-stage"
> (for lack of a better term), the incoming request URI is evaluated and then
> the new target list is constructed   The tagging in 4244 is based on the
> mechanism by which a new target is determined .  The previous hi-entry (that
> in the incoming request) is tagged at the point the request is being
> forwarded. I do agree that in the internal processing that information needs
> to exist so that the tagging at the point of forwarding the request is
> appropriate.  [/MB]
>
>
>
> BR,
> /Hans Erik van Elburg
>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 11:45:51 -0500

Hi Hans,
 
My confusion comes from the 3rd paragraph in section 6 (the same one
that confuses in terms of the unconditional addition of two hi-entries),
specifically this text:
" When a home proxy receives a request for a user or resource for which
   is abstract location function returns registered contacts or
   configured URIs, the proxy adds two History-Info header field values.
   The first is the incoming request URI.  Since the Request-URI
   identifies a user or resource for which it has a registration or
   configuration, the Request-URI is an AOR and thus an address for the
   user.  The proxy adds a History-Info header field parameter, "aor",
   which indicates this.  Next, the proxy inserts the contact URI which
   will be contained in the outgoing Request-URI."
 
(Note: this also confuses me because it is combining determining request
targets with the forwarding)
 
But, then later  in that section, there's the following text (7th
paragraph):
  "When a proxy receives a request for a user or resource for which it
   is responsible, then when a request URI rewrite occurs that is a
   routing translation, then add a History-Info header field parameter
   "routed" to the hi-entry recording the incoming request URI.
   Otherwise when a request URI rewrite occurs that is a mapping
   translation, then add a History-Info header field parameter "mapped"
   to the hi-entry recording the incoming request URI. "
 
So, it's just not clear at all to me how you coordinate the addition of
the two tags.  Perhaps, it's just how that section is written, but
again, this is my point that it's really difficult to understand your
solution proposal when it is not described in the context of the current
normative RFC 4244 functionality.  
 
This solution also does not seem to give clear delineation between
registered contacts versus configured URIs. I had understood that to be
important for some services. In particular, how will this solution
support being able to identify aliases?
 
Thanks,
Mary. 

Sent: Friday, June 12, 2009 10:24 AM

Hi Mary,

I do not understand what you mean with multi stage. All the tagging can
be prepared at the time that the translation is done and added at the
time that 4244 suggests the H-I to be added. If the current text
suggests otherwise, then we might need to fix that.

BR,
/Hans Erik van Elburg

On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes <[email-masked]>
wrote:

	Hi Hans,

	Mary.

	

	Hi Mary,
	
	Sure when we agree on the way forward we have to resolve all
these detailed procedures and conform to the 4244 language etc. But we
already agreed to integrate it into 4424bis at the moment that there is
agreement about the solution. 
	
	Regarding the two tag approach that is open for discussion, i
think it is more clean and in general pays off to separate concepts that
are independent from each other. For example a hi-entry may be routed
and not be an AOR, whereas it may also be routed and also an AOR. The
decisions to be taken for additions of these tags are independent, so
there is also no need to intertwine procedural text for them. (It is
also more clear for implementors.) 
	[MB] This is where my major confusion is in that you say the
tags are independent, BUT where in the normative RFC 3261 processing
does this occur?  I'm confused because the logic in section 16.5 isn't
"multi-stage" (for lack of a better term), the incoming request URI is
evaluated and then the new target list is constructed   The tagging in
4244 is based on the mechanism by which a new target is determined .
The previous hi-entry (that in the incoming request) is tagged at the
point the request is being forwarded. I do agree that in the internal
processing that information needs to exist so that the tagging at the
point of forwarding the request is appropriate.  [/MB]

	BR,
	/Hans Erik van Elburg

	On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes
<[email-masked]> wrote:

		Christer,
		
		I reviewed the updated target-uri draft and have a few
comments - well I
		reviewed the diff since there isn't a summary of changes
in the
		document:

		2) The reason I'm concerned about understanding how this
fits with the
		current normative processing is because I'm not seeing
precisely when
		these tags are added as the terminology is different
than that used in
		RFC 4244 - i.e., are these two terms equivalent:
		RFC 4244:
		"... hi-entry received in the request being forwarded."
		
		target-uri:

		3) In particular, I'm having difficulty with this text
in section 6:
		  "When a home proxy receives a request for a user or
resource for
		which
		  is abstract location function returns registered
contacts or
		  configured URIs, the proxy adds two History-Info
header field values.
		  The first is the incoming request URI.  Since the
Request-URI
		  identifies a user or resource for which it has a
registration or
		  configuration, the Request-URI is an AOR and thus an
address for the
		  user.  The proxy adds a History-Info header field
parameter, "aor",
		  which indicates this.  Next, the proxy inserts the
contact URI which
		  will be contained in the outgoing Request-URI."
		Currently, in RFC 4244, the proxy only adds that
additional (first)
		hi-entry IF there wasn't one in the incoming request,
since the UAC can
		initially add one when it builds the request. So, this
is inconsistent
		with current RFC 4244. And, I think you need to define
"home" proxy -
		that's not an RFC 3261 term - there is the concept of a
"home" domain.
		
		4) There is a bug in the Syntax (section 9) - the Index
is not optional
		(that is an error we have fixed in the 4244bis).
		
		5) I'm really confused about this two-stage tagging -
how does that
		happen in the context of the determination of Request
Targets in section
		16.5 of RFC3261? Wouldn't the decisions as to the
addition of the two
		different tags occur at the same time and thus what is
the advantage of
		the defining the two tags - i.e., why not one tag for
each combination?
		Also, are you proposing that the addition of the tags be
mandatory -
		there is no normative language in the target-uri
document, so it's
		impossible to tell.  And, if you are proposing they be
mandatory, your
		ABNF syntax needs to reflect that, thus defining a
single parameter with
		multiple values would be necessary (which is the
approach in 4244bis).

		6) What is the difference (or is there a difference?)
between the
		functionality associated with the tags in 4244bis and
the tags defined
		in this document in terms of types of retargets that are
being tagged?
		I think this is the crux of what we need to agree -
i.e., why aren't the
		4244bis tags sufficient?  If there is no logical
difference and it's
		just the words used to define the tags, then we're very
close to
		agreement.
		
		Regards,
		Mary.

		-----Original Message-----
		From: Christer Holmberg
[mailto:[email-masked]]
		Sent: Thursday, June 11, 2009 3:32 PM

		Here is the link to the latest version of the target-uri
draft:

		-----Original Message-----
		From: Christer Holmberg
		Sent: Thursday, June 11, 2009 11:31 PM
		To: 'Mary Barnes'; [email-masked]
		Subject: RE: [sipcore] FW: I-D
		Action:draft-barnes-sipcore-rfc4244bis-01.txt

		Hi,
		
		I think it is important to mention that there are still
different
		approaches regarding the target uri delivery, and that
there is another
		approach described in the latest version of the
target-uri delivery
		draft (I am not sure it appears in the archieves,
though, for some
		reason). Both approaches are based on History-Info,
though.
		
		We haven't yet been able to agree on an approach, so we
thought the best
		is to bring it to the list in order for other people to
get involved.
		
		Regards,
		
		Christer

		-----Original Message-----
[mailto:[email-masked]] On
		
		Hi folks,
		
		We have made a few changes to this document which was
submitted last
		week just to tie up some loose ends and inconsistencies,
some of which
		Shida identified when he reviewed the -00 version.
		
		The following summarizes the high level changes in the
		sipcore-rfc4244bis from the sip-rfc4244bis that we
discussed in San
		Francisco:
		1) Renamed the "retarget" parameter to "target" and
defined explicit
		tags to reflect the various mechanisms by which a
Request is retargeted.
		All entries are now tagged.
		2) Updated redirect server processing as the redirect
server must
		capture the "target" parameter since it is the entity
that knows the
		specific mechanism by which the new target has been
determined.
		3) Changed the privacy such that rather than removing
entries based on
		the various values of the privacy header, the entries
are recommended to
		be anonymized.
		4) Updated security section
		5) Updated examples to reflect the new parameter, use
loose routing and
		fix errors/nits.
		6) Editorial changes to remove redundant text and the
convuluted text
		around optionality in the non-normative sections, which
is now discussed
		appropriately in the context of the histinfo option tag.
		
		The detailed changes between the versions are summarized
in the
		document.
		
		If you're wanting to look at a diff, I would recommend
you diff against
		RFC 4244 rather than the earlier 4244bis documents.
		
		We'd really appreciate feedback on this approach to
precisely tagging
		all the entries. We believe it is comprehensive and
should suffice for
		all the use cases identified in the target-uri document,
as well as any
		others that might arise.
		
		Thanks,
		Mary and Francois.
		
		-----Original Message-----
		From: [email-masked]
		[mailto:[email-masked]] On Behalf Of
		[email-masked]
		Sent: Thursday, June 11, 2009 12:45 PM
		To: [email-masked]
		Subject: I-D

		       Title           : An Extension to the Session
Initiation
		Protocol (SIP) for Request History Information
		       Author(s)       : M. Barnes, F. Audet
		       Filename        :
draft-barnes-sipcore-rfc4244bis-01.txt
		       Pages           : 42
		       Date            : 2009-06-11
		
		This document defines a standard mechanism for capturing
the history
		information associated with a Session Initiation
Protocol (SIP) request.
		This capability enables many enhanced services by
providing the
		information as to how and why a call arrives at a
specific application
		or user.  This document defines a new optional SIP
header, History-Info,
		for capturing the history information in requests.

		
		
		Below is the data which will enable a MIME compliant
mail reader
		implementation to automatically retrieve the ASCII
version of the
		Internet-Draft.
		_______________________________________________
		sipcore mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 12 Jun 2009 13:18:53 -0500

This is a lame way to describe the problem without describing what a 
service number is.

Also, it is completely innacurate. 

> Sent: Friday, June 12, 2009 01:13
> The biggest difference is regarding support of service-number 
> (like toll-free/freephone) type-of services, where the 
> Request-URI translation does not change the targeted user or 
> resource. Without going in to the protocol differences (which 
> aren't that big), my understanding of the functional 
> differences are the following:
> 
> - 4244bis approach does not distinguish between 
> service-number (like toll-free/freephone) number translation 
> and diversion.
> 
> - 4244bis approach does not allow a service-number (like 
> toll-free/freephone) translation for a user which belongs to 
> another domain.
> 
> - 4244bis requires that all service-numbers for a 
> user/company (like toll-free/freephone) must be registered 
> (explicitly or implictly), which means that the translation 
> must be done by an entity (normally the registrar) which has 
> the registration information for the called user.
> 
> 
> The target uri approach does allow translation in another 
> domain, and does not require toll-free/freephone numbers to 
> be registered for the called user.
> 
> So, I don't think that the 4244bis approach supports all 
> service-numbers (like toll-free/freephone) in a sufficient 
> way, and that it is too restrictive for no good reason. It 
> imposes restrictions on the potential business models that 
> are not necessary.
> 
> Regards,
> 
> Christer 
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 12 Jun 2009 13:36:24 -0500

Here is the summary.

I'm going to spare details, but the main different is as follows.

1) RFC 4244bis

In RFC 4244bis, if the domain is responsible for the URI
in the Request-URI and it replacing it with a Contact, it will
put a reg-uri flag (if the Request-URI was the AOR used for 
registration), or reg-uri-alias (if the Request-URI was an 
alias for the AOR used in registration).

If the domain is responsible for the URI and it "maps" it
to a different user, then it puts a "mapped" flag.

If the domain is NOT responsible for the AOR but it changes
the Request-URI nevertheless, then it is also marked as "mapped".

	Note: With loose routing, this is not supposed to happen 
	(at least in theory).

This next statement is where there is a big difference:

If the domain is NOT responsible for the URI, the mapping cannot
know if the new URI is belongs to the same User than the original
one. This is why it is mapping: it is impossible for a proxy NOT
responsible for a URI to change it to something else and "know" if
it a different user (retarget) or just a "synonym" for the same user.

2) Target-UI

In target-URI, there is an assumption that a domain NOT responsible for
a URI can change the URI to something AND know authoritatively that the
new target is a "synonym" for the original target.

-------------

So this is what it boils down to.

Can a domain NOT responsible for a target change the target AND
mark the new target authoritatively as "belonging" to the same user?

In target-URI, the assumption is yes.

In 4244bis, the assumption is no (only the domain responsible for the URI can
do so). 

----

As pointed out by Paul Kyzivat, we probably need to think on how this
works with Tel URIs. I think for Tel URI it would be totally different.

> [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN 
> C, ATTLABS
> Sent: Thursday, June 11, 2009 13:40

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 21:07:53 +0200

Francois,

It is clear that a service or tollfree address if expressed as a SIP URI 
is always delivered to the domain that is expressed in the home part.

Such service is therefore responsible for that domain. If it forwards 
the request to an AOR of another domain, but knows that this is the same 
addressed target. Then it can tag the hi-entry accordingly.  This 
knowledge is inherently linked to the service being provided, so this 
can be very reliably decided by this specific proxy.

> new target is a "synonym" for the original target.

This is incorrect. An entry is only tagged to be an AOR if the proxy is 
responsible for the domain and translates Request URI based on a 
abstract location function lookup. (per RFC3261 section 16.5 )

> In target-URI, the assumption is yes.

This is again incorrect. Target-uri draft does not imply this. It is a misinterpretation.

do so).

4424bis does not allow distinction between a diversion and a users service number (like a tollfree number service) 

Best Regards,
/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 21:46:20 +0200

Hi Mary,

>  So, it's just not clear at all to me how you coordinate the addition 
of the two tags.  Perhaps, it's just how that section is written,
>  but again, this is my point that it's really difficult to understand 
your solution proposal when it is not described in the context of
>  the current normative RFC 4244 functionality. 

The text can definitely be improved, but still the criteria for adding 
the tags are independent.

I will try draft a chapter as it would look like in 4424.

>  This solution also does not seem to give clear delineation between 
registered contacts versus configured URIs. I had understood > that to 
be important for some services. In particular, how will this solution 
support being able to identify aliases?

Regarding the alias concept, I have no problems in adding that. But it 
is currently not in scope of the target-uri work, if people agree then 
we can add that requirement. We could reuse the definition that is 
contained in the 4424bis draft as I think that is a good definition.

But what is the essential difference between bindings that came about 
due to registration and those that are configured? (To me this has 
nothing todo with aliases, in fact I think it is not a meaningful 
difference how the binding was made.)
But if you have a requirement for that, you should maybe explain it.

/Hans Erik

Mary Barnes wrote:
> that confuses in terms of the unconditional addition of two 
> hi-entries), specifically this text:
> (Note: this also confuses me because it is combining determining 
> request targets with the forwarding)
>  
> So, it's just not clear at all to me how you coordinate the addition 
> of the two tags.  Perhaps, it's just how that section is written, but 
> solution proposal when it is not described in the context of the 
> current normative RFC 4244 functionality. 
>  
> registered contacts versus configured URIs. I had understood that to 
> be important for some services. In particular, how will this solution 
> ------------------------------------------------------------------------
> *Sent:* Friday, June 12, 2009 10:24 AM
> I do not understand what you mean with multi stage. All the tagging 
> can be prepared at the time that the translation is done and added at 
> the time that 4244 suggests the H-I to be added. If the current text 
> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Hans,
>      
>     ------------------------------------------------------------------------
>     *From:* Hans Erik van Elburg [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Christer Holmberg; [email-masked] <mailto:[email-masked]>
>     detailed procedures and conform to the 4244 language etc. But we
>     already agreed to integrate it into 4424bis at the moment that
>     there is agreement about the solution.
>
>     think it is more clean and in general pays off to separate
>     concepts that are independent from each other. For example a
>     hi-entry may be routed and not be an AOR, whereas it may also be
>     routed and also an AOR. The decisions to be taken for additions of
>     these tags are independent, so there is also no need to intertwine
>     procedural text for them. (It is also more clear for implementors.) 
>     [MB] This is where my major confusion is in that you say the tags
>     are independent, BUT where in the normative RFC 3261 processing
>     does this occur?  I'm confused because the logic in section 16.5
>     isn't "multi-stage" (for lack of a better term), the incoming
>     request URI is evaluated and then the new target list is
>     constructed   The tagging in 4244 is based on the mechanism by
>     which a new target is determined .  The previous hi-entry (that in
>     the incoming request) is tagged at the point the request is being
>     forwarded. I do agree that in the internal processing that
>     information needs to exist so that the tagging at the point of
>     forwarding the request is appropriate.  [/MB]
>      
>
>
>     BR,
>     /Hans Erik van Elburg
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Christer,
>
>         From: Christer Holmberg [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         [email-masked] <mailto:[email-masked]>
>         <http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00.%0Atxt>
>
>         To: 'Mary Barnes'; [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] On
>         Behalf Of Mary Barnes
>         To: [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of
>         [email-masked] <mailto:[email-masked]>
>         To: [email-masked] <mailto:[email-masked]>
>         <http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t%0Axt>
>
>         [email-masked] <mailto:[email-masked]>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 15:33:08 -0500

Hi Hans, 

Just a few comments below [MB].   

Thanks,
Mary.

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 2:46 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] FW: I-D

Hi Mary,

I will try draft a chapter as it would look like in 4424.
[MB] Yes, it would help to understand this in the context of 16.5 where
you are determining the targets for the request as I can't quite see how
the determination of the tags are independent. And, I say determination
because as is, you don't add the tag until you are forwarding the
request per section 16.6.  The exception is the case of a 3xx and the
redirect server has added the tag - at least per the 4244bis
specification of redirect server and 3xx handling, which is actually
something else missing in target-uri as this does introduce a somewhat
special case now that we are adding this level of granularity in terms
of the mechanism by which the target(s) are determined. [/MB]

Regarding the alias concept, I have no problems in adding that. But it
is currently not in scope of the target-uri work, if people agree then
we can add that requirement. We could reuse the definition that is
contained in the 4424bis draft as I think that is a good definition.
[MB] I'm puzzled as aliases are identified as a service to be supported
by target-uri in section 4.1. That's the exact use case that the
"reg-uri-alias" tag in 4244bis will support. [/MB]

But what is the essential difference between bindings that came about
due to registration and those that are configured? (To me this has
nothing todo with aliases, in fact I think it is not a meaningful
difference how the binding was made.) But if you have a requirement for
that, you should maybe explain it.
[MB] I'm not sure we're using the term configured in the same context
here as I think you are really talking about the entries that are tagged
as "mapped" in 4244bis.  The alias concept actually uses both
registration and configuration - that's why it's really a separate
mechanism by which targets are determined. This is clearly defined in
4244bis in the description of the "reg-uri-alias" tag. [/MB]

/Hans Erik

values.
which
>     *Cc:* Christer Holmberg; [email-masked]
<mailto:[email-masked]>
differences?
for
Request-URI
registration or
it's
the
draft:
different
some
must
determined.
Internet-Drafts
Initiation
the

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 22:39:58 +0200

The delivery of the addressed target to the UAS is what we are trying to solve, the alias use case is just showing a case where this information is usefull for the UAS, but destroyed by Request-URI overwriting.

Best Regards,
/Hans Erik

Mary Barnes wrote:
>> " When a home proxy receives a request for a user or resource for
>>     
> which
>   
>>    configuration, the Request-URI is an AOR and thus an address for
>>     
> the
>   
>>    translation, then add a History-Info header field parameter
>>     
> "mapped"
>   
>>     procedural text for them. (It is also more clear for
>>     
> implementors.) 
>   
>>         reviewed the diff since there isn't a summary of changes in
>>     
> the
>   
>>         document:
>>
>>         just the words used to define the tags, then we're very close
>>     
> to
>   
>>         agreement.
>>
>>         Regards,
>>         Mary.
>>
>>
>>
>>         The detailed changes between the versions are summarized in
>>     
> the
>   
>>         document.
>>
>>         This capability enables many enhanced services by providing
>>     
> the
>   
>>         Below is the data which will enable a MIME compliant mail
>>     
> reader
>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 16:05:43 -0500

I'm even further puzzled then.  The abstract of target-uri states:

   "This document
   describes these use cases and defines an extension to the History-
   Info header field which allows it to be used to support those cases."

With the following listed in the TOC: 
     4.1.  Unknown Aliases  . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Limited Use Addresses  . . . . . . . . . . . . . . . . . .  6
     4.4.  Sub-Addressing . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  Service Invocation . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Toll Free Numbers  . .

I thought the whole point was to handle ANY of the use cases "where this
information is usefull for the UAS, but destroyed by Request-URI
overwriting" - i.e, that's the general problem being solved and the
solution provided by History-Info is agnostic as to how an application
might use that information. 

I think what we may be butting heads on isn't the History-Info aspects
of supporting those services, but rather that the information that some
of those services depend on isn't amenable to clear identification in
terms of how SIP determines request targets. This is where I was going
with my initial suggestion that you may need to add some more service
specific looking tags to the request URIs. 

Mary. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 3:40 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] FW: I-D

The delivery of the addressed target to the UAS is what we are trying to
solve, the alias use case is just showing a case where this information
is usefull for the UAS, but destroyed by Request-URI overwriting.

Best Regards,
/Hans Erik

> [MB] Yes, it would help to understand this in the context of 16.5 
> where you are determining the targets for the request as I can't quite

> see how the determination of the tags are independent. And, I say 
> determination because as is, you don't add the tag until you are 
> forwarding the request per section 16.6.  The exception is the case of

> a 3xx and the redirect server has added the tag - at least per the 
> 4244bis specification of redirect server and 3xx handling, which is 
> actually something else missing in target-uri as this does introduce a

> somewhat special case now that we are adding this level of granularity

> in terms of the mechanism by which the target(s) are determined. [/MB]
>
>
>   

> [MB] I'm puzzled as aliases are identified as a service to be 
> supported by target-uri in section 4.1. That's the exact use case that

> the "reg-uri-alias" tag in 4244bis will support. [/MB]
>
> difference how the binding was made.) But if you have a requirement 
> for that, you should maybe explain it.
> here as I think you are really talking about the entries that are 
> tagged as "mapped" in 4244bis.  The alias concept actually uses both 
"aor",

>> ---------------------------------------------------------------------
>> -
>> --

>>     A couple comments below [MB].
these
>> resource
address
>>           user.  The proxy adds a History-Info header field
parameter,
>>         that's not an RFC 3261 term - there is the concept of a
"home"
>>         4) There is a bug in the Syntax (section 9) - the Index is
not
>>         5) I'm really confused about this two-stage tagging - how
does
>>         in this document in terms of types of retargets that are
being
>>         -----Original Message-----
[mailto:[email-masked]
>   
>>         txt
>>         
>> <http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery
>> -
>> 00.%0Atxt>
>>
>> <http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-
>> 0
>> 1.t%0Axt>
>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 23:04:43 +0200

I'm trying to do it similarly 4.3.3.1.4/[4424bis], but I do not 
understand how this text works for the forked case.

Because for different forks the hi-entry representing the retargeted 
R-URI could get another tag. The current text does not seem to cover 
this aspect.

How is this intended to be covered by this text?

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 12 Jun 2009 23:13:38 +0200

> might use that information. 
Exactly.

> specific looking tags to the request URIs. 
It is not a service specific thing, but specific services cant be 
provided because SIP adresses target uri delivery is broken.

>>>   "When a proxy receives a request for a user or resource for which
>>>       
> it
>   
>>>    routing translation, then add a History-Info header field
>>>       
> parameter
>   
>>>     routed and also an AOR. The decisions to be taken for additions
>>>       
> of
>   
>>>     these tags are independent, so there is also no need to
>>>       
> intertwine
>   
>>>     which a new target is determined .  The previous hi-entry (that
>>>       
> in
>   
>>>         these tags are added as the terminology is different than
>>>       
> that
>   
>>>         used in
>>>           is abstract location function returns registered contacts
>>>       
> or
>   
>>>         functionality associated with the tags in 4244bis and the
>>>       
> tags
>   
>>>         defined
>>>         around optionality in the non-normative sections, which is
>>>       
> now
>   
>>>         discussed

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Jun 2009 16:56:55 -0500

Hi Hans,

I think we're making progress - I understand why you do not understand
this.  We likely need to add some more text to make this clear.  The way
History-Info works now is that the tags are added to the previous/last
hi-entry (i.e., the one in the incoming request) at the point in time
that the request is being forwarded. This is what's described in section
4.3.3.1.  

This means that the proxy needs to keep track of the hi-target that
would be applied to that previous/last hi-entry for each target in the
target list it builds per section 16.5.   Then, as the proxy forwards
the request as described in section 4.3.3.1, the proxy has the
information as to how to appropriately tag that previous/last hi-entry.
That's the only way it will work. But, yes, this is confusing in that
section 4.3.3.1.4 is discussing how the information that is used when
the request is forwarded is derived. 

So, I will add some text to clarify this in the next update to 4244bis,
I should reword that first paragraph in section 4.3.3.1.4 as follows:
OLD:
   An hi-target attribute MUST be included in a request forwarded by a
   proxy.  The addition of the hi-target parameter MUST occur prior to
   the forwarding of the request (which may add a new hi-entry with a
   new hi-targeted-to- uri) as it is associated with the hi-targeted-to-
   uri that has been retargeted.  

NEW: 
   An hi-target attribute MUST be included in a request forwarded by a
   proxy.  The addition of the hi-target parameter MUST occur just prior
to
   the forwarding of the request (which may add a new hi-entry with a
   new hi-targeted-to- uri) as it is associated with the hi-targeted-to-
   uri that has been retargeted. 
   The value for the hi-target attribute is determined by the proxy when
it builds 
   the target list as described in section 16.5 of [RFC3261].  The
subsequent paragraphs 
   describe the processing relevant to section 16.5 for determining the
value of the 
   hi-target attribute that is associated with a specific target to
which a request 
   is to be forwarded and the value to which the hi-target parameter
MUST be set when 
   the request is forwarded.

Thanks,
Mary. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 4:05 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] FW: I-D

/Hans Erik

"aor",
it
parameter

these
of
intertwine
in
that
or
address
parameter,
"home"
not
does
tags
being
now

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 12 Jun 2009 17:21:04 -0500

> It is clear that a service or tollfree address if expressed 
> as a SIP URI is always delivered to the domain that is 
> expressed in the home part.

Yes, we agree on this.

> Such service is therefore responsible for that domain. If it 
> forwards the request to an AOR of another domain, but knows 
> that this is the same addressed target. Then it can tag the 
> hi-entry accordingly.  This knowledge is inherently linked to 
> the service being provided, so this can be very reliably 
> decided by this specific proxy.

I don't believe we will get agreement on this point.

If I send a request to sip:[email-masked], and example forwards it
to sip:[email-masked], I do not think it is reasonable to expect
that example.com can assert that sip:[email-masked] and sip:[email-masked]
are in aliases.

This is very different from example.com knowing that sip:[email-masked]
and sip:[email-masked] are aliases of sip:[email-masked].

That is the core of the argument.

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 13 Jun 2009 09:42:40 +0200

Hi, 

>This is a lame way to describe the problem without describing what a service number is.

So, maybe we need to agree on that first. We DO have a requirement to support it, but it is difficult to support it if we don't know what it is...

>Also, it is completely innacurate. 

So, please correct me.

Regards,

Christer

> The biggest difference is regarding support of service-number (like 
> toll-free/freephone) type-of services, where the Request-URI 
> translation does not change the targeted user or resource. Without 
> going in to the protocol differences (which aren't that big), my 
> understanding of the functional differences are the following:
> 
> - 4244bis approach does not distinguish between service-number (like 
> toll-free/freephone) number translation and diversion.
> 
> toll-free/freephone) translation for a user which belongs to another 
> domain.
> 
> - 4244bis requires that all service-numbers for a user/company (like 
> toll-free/freephone) must be registered (explicitly or implictly), 
> which means that the translation must be done by an entity (normally 
> the registrar) which has the registration information for the called 
> user.
> 
> 
> The target uri approach does allow translation in another domain, and 
> does not require toll-free/freephone numbers to be registered for the 
> called user.
> 
> service-numbers (like toll-free/freephone) in a sufficient way, and 
> that it is too restrictive for no good reason. It imposes restrictions 
> on the potential business models that are not necessary.
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 13 Jun 2009 09:49:21 +0200

Hi, 

>>It is clear that a service or tollfree address if expressed as a SIP
URI is always delivered to the domain that is expressed in the home
part.
>>the request to an AOR of another domain, but knows that this is the 
>>same addressed target. Then it can tag the hi-entry accordingly.  This

>If I send a request to sip:[email-masked], and example forwards it to
sip:[email-masked], I do not think it is reasonable to expect that
example.com can assert that sip:[email-masked] and 
>sip:[email-masked] are in aliases.
>
>This is very different from example.com knowing that
sip:[email-masked] and sip:[email-masked] are aliases
of sip:[email-masked].
>That is the core of the argument.

Yes.

I also think we have different opinions on whether a service number has
to be an alias (meaning that the service number is registered for the
user).

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 13 Jun 2009 10:06:39 +0200

Hi, 

>In RFC 4244bis, if the domain is responsible for the URI in the
Request-URI and it replacing it with a Contact, it will put a reg-uri
flag (if the Request-URI was the AOR used for registration), or reg-
>uri-alias (if the Request-URI was an alias for the AOR used in
registration).
>
>If the domain is responsible for the URI and it "maps" it to a
different user, then it puts a "mapped" flag.
>
>If the domain is NOT responsible for the AOR but it changes the
Request-URI nevertheless, then it is also marked as "mapped".
>If the domain is NOT responsible for the URI, the mapping cannot know
if the new URI is belongs to the same User than the original one. This
is why it is mapping: it is impossible for a proxy NOT 
>responsible for a URI to change it to something else and "know" if it a
different user (retarget) or just a "synonym" for the same user.

We don't think it is "impossible", and we see no reason why we should
make that restriction without any technical justification. The proxy
does not change the URI just for fun, with a value out of the blue - it
does it based on some kind of knowledge/configuration.

Correct. 

And, I assume the difference between "synomym" and "alias" is that a
synonym URI is not registered for the called user, right?

But, one question for clarification: if the "synonym" translation is
done by an entity which IS reponsible for the domain, how is it tagged?

-------------

>So this is what it boils down to.

I think that is more or less what I was trying to say.

>Can a domain NOT responsible for a target change the target AND mark
the new target authoritatively as "belonging" to the same user?
>In 4244bis, the assumption is no (only the domain responsible for the
URI can do so). 

Correct.

-------------

Yes. You raised that also in our private discussions, but we never
discussed it in details.

So, before we start discussing the protocol details, I think we need to
solve the issues above. 

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 13 Jun 2009 10:20:04 +0200

Hi, 

>I think we're entirely clear on the types of services that need to be supported.

Yes, we seem to agree we need to support service numbers. However, we seem to have different opinions on what a service number is.

1. Does a service number has to be an alias?

2. Can the service number translation be done by "another" domain?

>It is the mechanism that we're debating. And by mechanism, I mean how information that is meaningful to services (at a UAS) is "lost" information as a request is retargeted. 

Yes, and if the service number is meaningful to the UAS it needs to know what the service number was...

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, June 12, 2009 9:12 AM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi, 

Regards,

Christer

> that used in
> tags defined

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 13 Jun 2009 10:21:48 +0200

Hi, 

registration).

And if the Request-URI was a "synonym" for the AOR?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 13 Jun 2009 16:23:42 -0400

This thing about the freephone services is an ugly one.
I've thought for a long time that the mechanism is an entirely brain 
dead way to designate who should pay for a call.

But it is what it is, so I guess we have to cope with it.

I wonder if perhaps this is really one of the few circumstances where 
the recipient of a call ought to make call handling decisions based on 
the To-uri. The reason I say this is because the "contract" with these 
numbers is that the caller expects the call will be free based on the 
form of the number being called. And if the caller is wrong, it is the 
caller who gets charged.

So, while I generally recommend that the To-uri be used for *nothing*, 
it might be right here. If so, then the whole target-uri/h-i discussion 
may be irrelevant to it.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 13 Jun 2009 22:54:23 +0200

Already 4.3.3.1 must be clarified as it says that the proxy must add a hi-entry, 
but it does not specify what value should be added.

Further all this text seems to be written backwards instead of in logical order, 
which makes it very hard to understand or modify.

So why dont we rewrite 4.3.3.1 something like:

<BEGIN FRAGMENT>

          .3.3.1. Adding the History-Info Header to Requests

RFC3261 Section 16.6 describes the procedure executed for each target in the 
target set, this specification extends that procedure as follows.
 
A proxy conforming to this specification MUST perform the following steps between
Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each target separately <http://tools.ietf.org/html/rfc3261#section-16.6>:   
   1. If a request is received that doesn't include a History-Info header, a proxy 
   conforming to this specification MUST add a History-Info header with a hi-entry 
   with the value of Request-URI from the received request. The index for this 
   hi-entry MUST start at 1. The <XYZ> attributes MUST be set according to the 
   procedure as specified in 4.3.3.1.X.
   
   2. If the incoming request already contains a History-Info header field,
   and the last hi-entry is not identical to the Request-URI of the received request,
   MUST add a History-Info header with a hi-entry with the value of Request-URI from 
   the received request. The index for this hi-entry MUST follow the rules specified in 4.3.3.1.3. 
   The <XYZ> attributes MUST be set according to the procedure as specified in 4.3.3.1.X.

   3. A proxy conforming to this specification MUST add a hi-entry with the value 
   of the target as it forwards a Request.

<END FRAGMENT>

It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. I also think step 1 and 2 should 
be mandatory evaluated. The current text for step 1 is at MAY strength.

If we could agree to rewrite 4.3.3.1 like this it would be much easier to hook in different  
attribute setting behaviours, even if in the future someone sees the need for a new attribute and writes 
a separate draft for extending the mechanism.

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 13 Jun 2009 23:02:20 +0200

Hi Paul,

For what would you want to use the To-uri?

/Hans Erik

Paul Kyzivat wrote:
> it might be right here. If so, then the whole target-uri/h-i 
> discussion may be irrelevant to it.
>
>     Thanks,
>     Paul
>
> Christer Holmberg wrote:
>> Hi,
>>>     Note: With loose routing, this is not supposed to happen     (at 
>>> least in theory).
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 13 Jun 2009 17:34:44 -0400

> For what would you want to use the To-uri?

To decide who/what the caller desired to reach, and hence what treatment 
to give the call. This seems to be the key thing for the call centers 
that use freephone numbers.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 14 Jun 2009 09:42:10 +0200

But that does not work when a diversion to that service number takes 
place. It only works for direct calls to such service number.

/Hans Erik

Paul Kyzivat wrote:
> To decide who/what the caller desired to reach, and hence what 
> treatment to give the call. This seems to be the key thing for the 
> call centers that use freephone numbers.
>
>     Thanks,
>     Paul
>
>> /Hans Erik
>>
>> Paul Kyzivat wrote:
>>> I wonder if perhaps this is really one of the few circumstances 
>>> where the recipient of a call ought to make call handling decisions 
>>> based on the To-uri. The reason I say this is because the "contract" 
>>> with these numbers is that the caller expects the call will be free 
>>> based on the form of the number being called. And if the caller is 
>>> wrong, it is the caller who gets charged.
>>>
>>> So, while I generally recommend that the To-uri be used for 
>>> *nothing*, it might be right here. If so, then the whole 
>>> target-uri/h-i discussion may be irrelevant to it.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> Christer Holmberg wrote:
>>>> Hi,
>>>>> it a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 14 Jun 2009 09:50:59 +0200

Just an update of my previous mail I realised I forgot one step 
(inserted after step 3).

Already 4.3.3.1 must be clarified as it says that the proxy must add a 
hi-entry, but it does not specify what value should be added.

Further all this text seems to be written backwards instead of in 
logical order, which makes it very hard to understand or modify.

<BEGIN FRAGMENT>

4.3.3.1. Adding the History-Info Header to Requests

RFC3261 Section 16.6 describes the procedure executed for each target in 
the target set, this specification extends that procedure as follows.

A proxy conforming to this specification MUST perform the following 
steps between
Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each 
target separately <http://tools.ietf.org/html/rfc3261#section-16.6>:    
1. If a request is received that doesn't include a History-Info header, 
a proxy   conforming to this specification MUST add a History-Info 
header with a hi-entry   with the value of Request-URI from the received 
request. The index for this   hi-entry MUST start at 1. The <XYZ> 
attributes MUST be set according to the   procedure as specified in 
4.3.3.1.X.

2. If the incoming request already contains a History-Info header field,
  and the last hi-entry is not identical to the Request-URI of the 
received request,
  MUST add a History-Info header with a hi-entry with the value of 
Request-URI from   the received request. The index for this hi-entry 
MUST follow the rules specified in 4.3.3.1.3.   The <XYZ> attributes 
MUST be set according to the procedure as specified in 4.3.3.1.X.

3. If the incoming request already contains a History-Info header field,
  and the last hi-entry is identical to the Request-URI of the received 
request:
  the <XYZ> attributes MUST be set according to the procedure as 
specified in 4.3.3.1.X.

4. A proxy conforming to this specification MUST add a hi-entry with the 
value   of the target as it forwards a Request.

<END FRAGMENT>

It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. I 
also think step 1 and 2 should be mandatory evaluated. The current text 
for step 1 is at MAY strength.

If we could agree to rewrite 4.3.3.1 like this it would be much easier 
to hook in different  attribute setting behaviours, even if in the 
future someone sees the need for a new attribute and writes a separate 
draft for extending the mechanism.

/Hans Erik

Hans Erik van Elburg wrote:
> Already 4.3.3.1 must be clarified as it says that the proxy must add a 
> hi-entry, but it does not specify what value should be added.
>
> Further all this text seems to be written backwards instead of in 
> logical order, which makes it very hard to understand or modify.
>
> RFC3261 Section 16.6 describes the procedure executed for each target 
> in the target set, this specification extends that procedure as follows.
>
> Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each 
> target separately <http://tools.ietf.org/html/rfc3261#section-16.6>:   
>   1. If a request is received that doesn't include a History-Info 
> header, a proxy   conforming to this specification MUST add a 
> History-Info header with a hi-entry   with the value of Request-URI 
> from the received request. The index for this   hi-entry MUST start at 
> 1. The <XYZ> attributes MUST be set according to the   procedure as 
> specified in 4.3.3.1.X.
>   MUST add a History-Info header with a hi-entry with the value of 
> Request-URI from   the received request. The index for this hi-entry 
> MUST follow the rules specified in 4.3.3.1.3.   The <XYZ> attributes 
> MUST be set according to the procedure as specified in 4.3.3.1.X.
>
>   3. A proxy conforming to this specification MUST add a hi-entry with 
> the value   of the target as it forwards a Request.
>
> <END FRAGMENT>
>
> It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. 
> I also think step 1 and 2 should be mandatory evaluated. The current 
> text for step 1 is at MAY strength.
>
> If we could agree to rewrite 4.3.3.1 like this it would be much easier 
> to hook in different  attribute setting behaviours, even if in the 
> future someone sees the need for a new attribute and writes a separate 
> draft for extending the mechanism.
>
> /Hans Erik
> Mary Barnes wrote:
>> Hi Hans,
>>
>> NEW:    An hi-target attribute MUST be included in a request 
>> forwarded by a
>>    uri that has been retargeted.    The value for the hi-target 
>> attribute is determined by the proxy when
>> it builds    the target list as described in section 16.5 of 
>> [RFC3261].  The
>> subsequent paragraphs    describe the processing relevant to section 
>> 16.5 for determining the
>> value of the    hi-target attribute that is associated with a 
>> specific target to
>> which a request    is to be forwarded and the value to which the 
>> hi-target parameter
>> MUST be set when    the request is forwarded.
>>
>>
>> Thanks,
>> Mary.
>> From: Hans Erik van Elburg [mailto:[email-masked]] Sent: 
>> Friday, June 12, 2009 4:05 PM
>>> be important for some services. In particular, how will this 
>>> solution support being able to identify aliases?
>>>
>>> But what is the essential difference between bindings that came 
>>> about due to registration and those that are configured? (To me this 
>>> has nothing todo with aliases, in fact I think it is not a 
>>> meaningful difference how the binding was made.) But if you have a 
>>> requirement for that, you should maybe explain it.
>>> [MB] I'm not sure we're using the term configured in the same 
>>> context here as I think you are really talking about the entries 
>>> that are tagged as "mapped" in 4244bis.  The alias concept actually 
>>> uses both registration and configuration - that's why it's really a 
>>> separate mechanism by which targets are determined. This is clearly 
>>> defined in 4244bis in the description of the "reg-uri-alias" tag. [/MB]
>>>
>>>
>>> /Hans Erik
>>>
>>> Mary Barnes wrote:
>>>      
>>>> Hi Hans,
>>>>  
>>>> My confusion comes from the 3rd paragraph in section 6 (the same 
>>>> one that confuses in terms of the unconditional addition of two 
>>>> So, it's just not clear at all to me how you coordinate the 
>>>> addition of the two tags.  Perhaps, it's just how that section is 
>>>> written, but
>>>>       
>>
>>  
>>>> registered contacts versus configured URIs. I had understood that 
>>>> to be important for some services. In particular, how will this 
>>>> solution
>>>>       
>>
>>  
>>>> the time that 4244 suggests the H-I to be added. If the current 
>>>> text suggests otherwise, then we might need to fix that.
>>>>
>>>> BR,
>>>> /Hans Erik van Elburg
>>>>
>>>>
>>>> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 14 Jun 2009 14:47:26 +0200

Hi Paul,

I guess you can look at the To-uri if you want to know who/what the
caller desired to reach.

However, the ua-loose-draft describes why the To-uri approach doesn't
work as a general solution for the target delivery problem. Please know
that diversion may have taken place before the final target was chosen,
so the To-uri may not say anything about the current target. 

So, even for freephone the To-uri may not contain the freephone number,
if the caller first tried to call something/someone else.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, June 14, 2009 12:35 AM
To: Hans Erik van Elburg
Cc: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: Re: [sipcore] The functional differences between 4244bis and
target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt)

	Thanks,
	Paul

>> the recipient of a call ought to make call handling decisions based 
>> on the To-uri. The reason I say this is because the "contract" with 
>> these numbers is that the caller expects the call will be free based 
>> on the form of the number being called. And if the caller is wrong, 
>> it is the caller who gets charged.
>>
>>> Request-URI and it replacing it with a Contact, it will put a 
>>> reg-uri flag (if the Request-URI was the AOR used for registration),

>>> or reg-
(at 
>>>> know
>>> if the new URI is belongs to the same User than the original one. 
>>> This is why it is mapping: it is impossible for a proxy NOT
>>> We don't think it is "impossible", and we see no reason why we 
>>> should make that restriction without any technical justification. 
>>> The proxy does not change the URI just for fun, with a value out of 
>>> the blue - it does it based on some kind of knowledge/configuration.
>>>
>>>> 2) Target-UI
>>>>
>>>> In target-URI, there is an assumption that a domain NOT responsible

>>>> for
>>> a URI can change the URI to something AND know authoritatively that 
>>> the new target is a "synonym" for the original target.
>>>
>>> Correct.

>>>> mark
>>> So, before we start discussing the protocol details, I think we need

>>> to solve the issues above.
>>>
>>> Regards,
>>>
>>> Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Sun, 14 Jun 2009 09:32:44 -0500

Hi Hans,

This is a good suggestion. The MAY strength was all that could be agreed
at that point in time. We have made other MAYs -> MUSTs in the doc and
this one should be done as well -i.e., add an entry if the previous hop
did not. 

I will incorporate the change you suggest in the next update. 

Thanks,
Mary. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Sunday, June 14, 2009 2:51 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] FW: I-D

<BEGIN FRAGMENT>

<END FRAGMENT>

/Hans Erik

>>>>  So, it's just not clear at all to me how you coordinate the
addition

>>>>          A couple comments below [MB].
----------------------------------------------------------------------
tags
>>>>         2) The reason I'm concerned about understanding how this
fits
resource
>>>>           which indicates this.  Next, the proxy inserts the
contact
>>>>         URI which
"home"
>>>>         happen in the context of the determination of Request
Targets
>>>>         in section
between
>>>>         just the words used to define the tags, then we're very
close
>>>>         approaches regarding the target uri delivery, and that
there
>>>>         is another
some
>>>>         of which
discussed
>>>>         in San
server
>>>>         3) Changed the privacy such that rather than removing
entries
>>>>         We'd really appreciate feedback on this approach to
precisely
the
>>>>         A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01
>>> .t

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Jun 2009 17:28:33 -0400

> place. It only works for direct calls to such service number.

Perhaps. That depends on *if* that is a reasonable scenario, and if so 
precisely what you want to happen in that case.

For instance, does it really make sense for you to call me, and for me 
to then divert you to an 800 number? If so, is that supposed to behave 
as if you had called the 800 number?

I realize there are many possible desired outcomes, so many strategies 
may be used from case to case.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 07:14:48 +0200

Hi Paul,

I am sure To-uri may work in some cases (eventhough I don't know how the UAS would know). But, we agreed a long time ago (when Jonathan submitted the ua-loose-route draft) that we were going to work on a more generic solution...

Regards,

Christer

> Sent: 15. kesäkuuta 2009 0:29
> To: Hans Erik van Elburg
> Subject: Re: [sipcore] The functional differences between 
> 4244bis and target- uri (was FW: I-D 
> Action:draft-barnes-sipcore-rfc4244bis-01.txt)
> 
> 
> 
> Perhaps. That depends on *if* that is a reasonable scenario, 
> and if so precisely what you want to happen in that case.
> 
> For instance, does it really make sense for you to call me, 
> and for me to then divert you to an 800 number? If so, is 
> that supposed to behave as if you had called the 800 number?
> 
> I realize there are many possible desired outcomes, so many 
> strategies may be used from case to case.
> 
> 	Thanks,
> 	Paul
> 
> > /Hans Erik
> > 
> > Paul Kyzivat wrote:
> >>
> >>
> >>>> I've thought for a long time that the mechanism is an entirely 
> >>>> brain dead way to designate who should pay for a call.
> >>>>
> >>>>> reg-uri flag (if the Request-URI was the AOR used for 
> >>>>> registration), or reg-
> >>>>>> responsible for a URI to change it to something else 
> and "know" 
> >>>>>> if it a
> >>>>> The proxy does not change the URI just for fun, with a 
> value out 
> >>>>> of the blue
> >>>>> - it
> >>>>> a URI can change the URI to something AND know authoritatively 
> >>>>> that the new target is a "synonym" for the original target.
> >>>>>
> >>>>> Correct.
> >>>>> And, I assume the difference between "synomym" and 
> "alias" is that 
> >>>>> a synonym URI is not registered for the called user, right?
> >>>>>
> >>>>> But, one question for clarification: if the "synonym" 
> translation 
> >>>>> is done by an entity which IS reponsible for the 
> domain, how is it 
> >>>>> tagged?
> >>>>>
> >>>>> -------------
> >>>>>
> >>>>>> In 4244bis, the assumption is no (only the domain 
> responsible for 
> >>>>>> the
> >>>>> URI can do so).
> >>>>> Correct.
> >>>>>
> >>>>> -------------
> >>>>>
> >>>>>> As pointed out by Paul Kyzivat, we probably need to 
> think on how 
> >>>>>> this
> >>>>> So, before we start discussing the protocol details, I think we 
> >>>>> need to solve the issues above.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jun 2009 08:58:10 -0400

> I am sure To-uri may work in some cases (eventhough I don't know how the UAS would know). But, we agreed a long time ago (when Jonathan submitted the ua-loose-route draft) that we were going to wor…

I wasn't suggesting it as a general solution. I know we need one of those.

I was suggesting that using To might be the right thing to do in a *few* 
cases, perhaps the freephone case. Its just another trick in the bag of 
tricks.

As to how you would tell, I think that is a policy decision for the 
receiving service.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 10:35:46 -0500

Ok, this is good.

At least we have a common understanding of the main sticking point.

Let me think about it a little bit and see how we could address the issue.

> Sent: Saturday, June 13, 2009 01:07
> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; 
> Barnes, Mary (RICH2:AR00); [email-masked]
> Subject: The functional differences between 4244bis and 
> target- uri (was FW: I-D 
> if the new URI is belongs to the same User than the original 
> We don't think it is "impossible", and we see no reason why 
> we should make that restriction without any technical 
> justification. The proxy does not change the URI just for 
> fun, with a value out of the blue - it does it based on some 
> kind of knowledge/configuration.
> 
> >2) Target-UI
> >
> a URI can change the URI to something AND know 
> authoritatively that the new target is a "synonym" for the 
> original target.
> 
> Correct. 
> 
> And, I assume the difference between "synomym" and "alias" is 
> that a synonym URI is not registered for the called user, right?
> 
> translation is done by an entity which IS reponsible for the 
> domain, how is it tagged?
> 
> -------------
> 
> Yes. You raised that also in our private discussions, but we 
> never discussed it in details.
> 
> So, before we start discussing the protocol details, I think 
> we need to solve the issues above. 
> 
> 
> Regards,
> 
> Christer
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 10:51:24 -0500

Perhaps you are correct.

I must admit I'm having trouble understanding the sutleties of the freephone service. 

> Sent: Saturday, June 13, 2009 13:24
> To: Christer Holmberg
> Cc: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; 
> I've thought for a long time that the mechanism is an 
> entirely brain dead way to designate who should pay for a call.
> 
> I wonder if perhaps this is really one of the few 
> circumstances where the recipient of a call ought to make 
> call handling decisions based on the To-uri. The reason I say 
> this is because the "contract" with these numbers is that the 
> caller expects the call will be free based on the form of the 
> number being called. And if the caller is wrong, it is the 
> caller who gets charged.
> 
> >> responsible for a URI to change it to something else and 
> "know" if it 
> >> a
> we should 
> > does not change the URI just for fun, with a value out of 
> the blue - 
> > it does it based on some kind of knowledge/configuration.
> > 
> >> 2) Target-UI
> >>
> translation is 
> responsible for the

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 10:50:28 -0500

then reg-uri-alias. 

> Sent: Saturday, June 13, 2009 01:22

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 19:16:53 +0200

But if it is NOT an alias (=implicitly/explicitly registered)? 

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 6:50 PM
To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;
[email-masked]

then reg-uri-alias. 

> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, 
> Mary (RICH2:AR00); [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jun 2009 13:23:32 -0400

This discussion is probably not worth having.
I agree there are all sorts of cases where something else is needed.
I was only thinking of freephone (800) service which is somewhat 
peculiar. But even then I don't know all the nuances that people may 
want to work.

Lets just forget it.

	Thanks,
	Paul

Shida Schubert wrote:
> 
>  I don't think it's a special case for free-dial alone.
> 
>  If service URN is used to deliver a service request such as emergency call
> or directory assistance request to a local call-center, and takes a similar
> approach to what's defined in phoneBCP to support devices not compliant to
> service URN, the translation to service URN from the dial string will be 
> done
> by the proxy. But the translation from 911 to "sos" will only be seen in 
> request URI
> and not in the To header.
> 
>  So To header even without diversion is not dependable.
> 
>  Regards
>   Shida
> 
> On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote:
> 
>>
>>
>>>>>> where the recipient of a call ought to make call handling 
>>>>>> decisions based on the To-uri. The reason I say this is because 
>>>>>> the "contract" with these numbers is that the caller expects the 
>>>>>> call will be free based on the form of the number being called. 
>>>>>> And if the caller is wrong, it is the caller who gets charged.
>>>>>>
>>>>>>> reg-uri
>>>>>>> This
>>>>>>> should
>>>>>>> that the

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 12:46:52 -0500

Yes, we need to sort out what to do for that. 

> Sent: Monday, June 15, 2009 10:17

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 13:13:11 -0500

It seems to me that the gist of this discussion has been based on the
expectation that independent of how the 800 number is configured,
registered or whatever at a proxy, that there is an expectation of
deterministic behavior in terms of how it's tagged.  So, if 800 numbers
are special and they can end up tagged as either reg-uri-alias or as
mapped, then perhaps the service has to know that it needs to look for
either of those. ISTM that if there is a reason to preserve that it's an
800 number (i.e., and not format as a service specific uri), the service
at the UAS knows that it's special, thus it would need to check the
request-URIs associated with both reg-uri-alias and mapped hi-entries.
I can't see how we can make it work any other way without being
prescriptive of how proxy's MUST tag these entries, which is not a good
idea IMHO.  However, I think these numbers are either special cases at
proxies or something that services know about. 

Mary. 

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Monday, June 15, 2009 12:47 PM
To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary
(RICH2:AR00); [email-masked]
Subject: RE: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 20:22:49 +0200

Hi Mary,

Proxies will tag entries based on the functionality they perform.

Let's leave req-uri-alias for the moment.

As I said earlier, one of the issues we have with 4244bis, is that
"mapped" seems to be used BOTH for diversion and when an AOR is replaced
with another AOR pointing to the same user - e.g. freephone. So, it is
not possible to distinguish between diversion and freephone.

We think one MUST be able to make that distinguishment, because you may
have cases where both diversion and service number translation (e.g.
freephone) occurs, and the UAS needs to know which is which.

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jun 2009 14:47:22 -0400

Do I get this right?
We need to be able to tag an R-URI replacement as being any one of three 
different types? Yet I gather we can't all agree on what the semantics 
of those three types is. Is it possible that there could be *more* than 
three types?

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 13:53:15 -0500

Correct. But, what I am suggesting is that you distinguish it at the UAS
- I'm assuming that the target Request-URI that arrives at the UAS is
something that identifies a client that handles 800 numbers.  That
client could be configured such that it knows to look for the original
800 number in the mapped URIs or in the reg-alias-URIs or both.  Again,
if you're making these 800 numbers special and allowing proxies to
change them in multiple ways (i.e., non-deterministic), then if you want
them tagged special, then you need special logic in the proxies to do
this.  That doesn't make sense to me, although you could do it that way
in a closed network, in which case you can make sure to always tag them
as whatever you think they should be - so we could define an additional
value for the tag. But, this is what I don't think is right in terms of
normal SIP request routing and forwarding, which is what the current
4244bis tags have been defined to represent. 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,
MARTIN C, ATTLABS; [email-masked]
Subject: RE: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 13:53:41 -0500

Yes. See my response ;)

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 1:47 PM
To: Christer Holmberg
Cc: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Do I get this right?

	Thanks,
	Paul

Christer Holmberg wrote:
> "mapped" seems to be used BOTH for diversion and when an AOR is 
> replaced with another AOR pointing to the same user - e.g. freephone. 
> So, it is not possible to distinguish between diversion and freephone.
> 
> We think one MUST be able to make that distinguishment, because you 
> may have cases where both diversion and service number translation
(e.g.
> deterministic behavior in terms of how it's tagged.  So, if 800 
> numbers are special and they can end up tagged as either reg-uri-alias

> or as mapped, then perhaps the service has to know that it needs to 
> look for either of those. ISTM that if there is a reason to preserve 
> that it's an 800 number (i.e., and not format as a service specific 
> uri), the service at the UAS knows that it's special, thus it would 
> need to check the request-URIs associated with both reg-uri-alias and
mapped hi-entries.
> prescriptive of how proxy's MUST tag these entries, which is not a 
> good idea IMHO.  However, I think these numbers are either special 
> cases at proxies or something that services know about.
> 
> Mary. 
>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 15 Jun 2009 21:20:15 +0900

If service URN is used to deliver a service request such as  
emergency call
or directory assistance request to a local call-center, and takes a  
similar
approach to what's defined in phoneBCP to support devices not  
compliant to
service URN, the translation to service URN from the dial string will  
be done
by the proxy. But the translation from 911 to "sos" will only be seen  
in request URI
and not in the To header.

  Regards
   Shida

On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote:

>> But that does not work when a diversion to that service number  
>> takes place. It only works for direct calls to such service number.
>
> Perhaps. That depends on *if* that is a reasonable scenario, and if  
> so precisely what you want to happen in that case.
>
> For instance, does it really make sense for you to call me, and for  
> me to then divert you to an 800 number? If so, is that supposed to  
> behave as if you had called the 800 number?
>
>>>>> *nothing*, it might be right here. If so, then the whole target- 
>>>>> uri/h-i discussion may be irrelevant to it.
>>>>>
>>>>>    Thanks,
>>>>>    Paul
>>>>>
>>>>> Christer Holmberg wrote:
>>>>>> Hi,
>>>>>>>    Note: With loose routing, this is not supposed to  
>>>>>>> happen     (at least in theory).
>>>>>>>
>>>>>> one. This
>>>>>>> "know" if it a
>>>>>> that a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 20:59:24 +0200

The UAS has no knowledge about freephone service it is only interested 
in extracting the addressed target.

The freephone service is just an example case where this poses currently 
a problem.

A proxy that performs a certain service can by configuration know that 
it performs kind of a synonym mapping and tag accordingly. This is 
totally deterministic.

/Hans Erik

Mary Barnes wrote:
>>> Request-URI and it replacing it with a Contact, it will put
>>>       
>> a reg-uri
>>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 14:07:41 -0500

See the response to Paul on defining an additional tag for this.  

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 1:59 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, MARTIN C,
ATTLABS; [email-masked]
Subject: Re: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt

/Hans Erik

> 800 number in the mapped URIs or in the reg-alias-URIs or both.  
> Again, if you're making these 800 numbers special and allowing proxies

> to change them in multiple ways (i.e., non-deterministic), then if you

> want them tagged special, then you need special logic in the proxies 
> to do this.  That doesn't make sense to me, although you could do it 
> that way in a closed network, in which case you can make sure to 
> always tag them as whatever you think they should be - so we could 
> define an additional value for the tag. But, this is what I don't 
> think is right in terms of normal SIP request routing and forwarding, 
> which is what the current 4244bis tags have been defined to represent.
>
> Mary. 
>
>
(e.g.

mapped hi-entries.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 21:06:03 +0200

Yes, I think we can, if we introduce the third category.

We have now:
- mapping translation (aor1->aor2, where aor2 is not configured as 
synonym for aor1)
- routing translation (noop, predetermined, aor->contact)

maybe we need a third, something like:
- synonym translation (aor1->aor2, where aor2 is a onfigured synonym for 
aor1)

Mapping and synonym, would only be performed by proxies that are 
configured to do so. This makes this entirely deterministic.

/Hans Erik

Paul Kyzivat wrote:
> Do I get this right?
> We need to be able to tag an R-URI replacement as being any one of 
> three different types? Yet I gather we can't all agree on what the 
> semantics of those three types is. Is it possible that there could be 
> *more* than three types?
>
>     Thanks,
>     Paul
>
> Christer Holmberg wrote:
>> Hi Mary,
>>
>> From: Mary Barnes [mailto:[email-masked]] Sent: Monday, June 
>> 15, 2009 9:13 PM

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 14:08:03 -0500

So Christer,

Who is in a position to determine that an address is "mapped to same user"?

Is it the the proxy that retargets to the new address, or is it the proxy
who receives that request that determines "yeah, Bob is same as 1800-5551212".

(I'm talking about the case where the 1800 number is in a different domain
as Bob). 

> Sent: Monday, June 15, 2009 11:23
> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); 
> DOLLY, MARTIN C, ATTLABS; [email-masked]
> As I said earlier, one of the issues we have with 4244bis, is 
> that "mapped" seems to be used BOTH for diversion and when an 
> AOR is replaced with another AOR pointing to the same user - 
> e.g. freephone. So, it is not possible to distinguish between 
> diversion and freephone.
> 
> We think one MUST be able to make that distinguishment, 
> because you may have cases where both diversion and service 
> number translation (e.g.
> To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, 
> It seems to me that the gist of this discussion has been 
> based on the expectation that independent of how the 800 
> number is configured, registered or whatever at a proxy, that 
> there is an expectation of deterministic behavior in terms of 
> how it's tagged.  So, if 800 numbers are special and they can 
> end up tagged as either reg-uri-alias or as mapped, then 
> perhaps the service has to know that it needs to look for 
> either of those. ISTM that if there is a reason to preserve 
> that it's an 800 number (i.e., and not format as a service 
> specific uri), the service at the UAS knows that it's 
> special, thus it would need to check the request-URIs 
> associated with both reg-uri-alias and mapped hi-entries.
> I can't see how we can make it work any other way without 
> being prescriptive of how proxy's MUST tag these entries, 
> which is not a good idea IMHO.  However, I think these 
> numbers are either special cases at proxies or something that 
> services know about. 
> 
> Mary. 
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 21:11:26 +0200

I disagree that the UAS needs to be aware about such services. It is 
only interested in extracting the addressed target in a generic way.

/Hans Erik

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 14:13:20 -0500

So... Then why do we need the difference between mapped-to-new-guy
and this-is-just-an-alias-aor again? 

> Sent: Monday, June 15, 2009 12:11
> Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, 
> I disagree that the UAS needs to be aware about such 
> services. It is only interested in extracting the addressed 
> target in a generic way.
> 
> /Hans Erik
> 
> Mary Barnes wrote:
> > Correct. But, what I am suggesting is that you distinguish 
> it at the 
> > UAS
> > may have cases where both diversion and service number 
> translation (e.g.
> based on the 
> > need to check the request-URIs associated with both 
> reg-uri-alias and mapped hi-entries.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 21:17:35 +0200

For an alias you do not translate to another AOR, you will just  rewrite 
with the contact.

The UAS is in this case interested with which AOR it was being reached, 
not whether this is an alias. It might be interested in that, but we 
haven't defined a requirement for that.

/Hans Erik

Francois Audet wrote:
>>> - I'm assuming that the target Request-URI that arrives at 
>>>       
>> the UAS is 
>>     
>>> client could be configured such that it knows to look for 
>>>       
>> the original 
>>     
>>> Again, if you're making these 800 numbers special and 
>>>       
>> allowing proxies 
>>     
>>> to change them in multiple ways (i.e., non-deterministic), 
>>>       
>> then if you 
>>     
>>> want them tagged special, then you need special logic in 
>>>       
>> the proxies 
>>     
>>> to do this.  That doesn't make sense to me, although you 
>>>       
>> could do it 
>>     
>>> think is right in terms of normal SIP request routing and 
>>>       
>> forwarding, 
>>     
>>> which is what the current 4244bis tags have been defined to 
>>>       
>> represent.
>>     
>>> Mary. 
>>>
>>>
>>> replaced with another AOR pointing to the same user - e.g. 
>>>       
>> freephone. 
>>     
>>> So, it is not possible to distinguish between diversion and 
>>>       
>> freephone.
>>     
>>> numbers are special and they can end up tagged as either 
>>>       
>> reg-uri-alias 
>>     
>>> look for either of those. ISTM that if there is a reason to 
>>>       
>> preserve 
>>     
>>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, 
>>>>         
>> ATTLABS; Barnes, 
>>     
>>>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, 
>>>>>           
>> ATTLABS; Barnes, 
>>     
>>>>> flag (if the Request-URI was the AOR used for 
>>>>>           
>> registration), or reg-
>>     
>>>>>       
>>>>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 21:33:36 +0200

Hi, 

something that identifies a client that handles 800 numbers.  That
client could be configured such that it knows to look for the 
>original 800 number in the mapped URIs or in the reg-alias-URIs or
both. 

800 numbers is just one example. 

Why should the UAS have to be configured with this information??? I
think that is very limiting and unpractical.

to change them in multiple ways (i.e., non-deterministic), then if you
want them tagged special, then you need special logic in the 
>proxies to do this.

The logic is that the AOR is replaced with another AOR, which belongs to
the same user. 

It's not only for 800 numbers - they are just an example where it would
be useful.

 And, the proxy is configured to do this - it doesn't do it because it
"thinks" it has to do it :)

>That doesn't make sense to me, although you could do it that way in a
closed network, in which case you can make sure to always tag them as
whatever you think they should be - so we could define an 
>additional value for the tag. But, this is what I don't think is right
in terms of normal SIP request routing and forwarding, which is what the
current 4244bis tags have been defined to represent. 

I really don't understand wht this "normal SIP request routing and
forwarding" is all about. Normal SIP request routing and forwarding has
issues, which were presented in the ua-loose-route draft - and that is
why we are now working on a solution to solve those issues.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 21:39:58 +0200

Hi, 

>Is it the the proxy that retargets to the new address, or is it the
proxy who receives that request that determines "yeah, Bob is same as
1800-5551212".

It is the entity which translates 1800-1551212 to Bob. So, in this case
it is the entity which implements the freephone service.

>(I'm talking about the case where the 1800 number is in a different
domain as Bob). 

In that case it will of course only be done if there is some kind of
agreement between the domains, so that the entity in the "1800 domain"
KNOWS that the 1800 number points to Bob.

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 14:52:58 -0500

Christer, 

On your last point, the objective here was to make use of History-Info
WITHOUT changing any core SIP functionality - it's a whole different
ballgame if we want to do the latter IMHO. However, here's the snippet
from the end of the response I just sent to Martin (summarizing the
current set of tags), which you may not read:

" So, we're debating here the differences between the "aor,mapped" and
"aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias".  I think
that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed".
And, I think one could consider the "aor,mapped" as predetermined. But,
again 4244bis tags the entries entirely based on what SIP does and if
the 800 number translations (or whatever services) are setup differently
in different proxies, then you can't determine if the "aor,routed" cases
might be "reg-uri-alias" or "reg-uri".  Although, I am personally
confused as to whether an 800 number would always be "aor, mapped" or
"aor, routed" - i.e., I just don't see this being deterministic and I
think that if a service can reach a UAS through different SIP
retargeting mechanisms, then the UAS needs to be aware. 

Also, as I'm going through this, I think we need 3 more tags if we want
the proxy to do the tagging - i.e., I think we need to add "-aor" to the
"predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the
proxy will mark in this manner. "

Mary. 
P.S. Also, I do not think it's a burden to put logic in the UAS - that
was the original intent for SIP - services in the endpoints - SIP is
just the signalling to carry the relevant information. But, I can see
that since the sort of service you mention that does not have a standard
SIP URI (i.e., user@domain) introduces something that isn't accomodated
in the basic SIP model, so we may need to add additional logic to the
proxies (I don't like it though). 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 15:01:06 -0500

But, still with this approach, I do not think you can get away with not
looking for multiple tags with the way you envision doing your services.
I think there are others that will implement services on the UAS that
will not need the differentiation that you do - i.e, they care about the
difference between "reg-uri" and "reg-uri-alias".

Mary. 

-----Original Message-----
From: Barnes, Mary (RICH2:AR00) 
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 22:06:07 +0200

Hi,

WITHOUT changing any core SIP functionality - it's a whole different
ballgame if we want to do the latter IMHO. However, here's the 
>snippet from the end of the response I just sent to Martin (summarizing
the current set of tags), which you may not read:

I don't see this as a change to any core SIP functionality.

"aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias".  I think
that "reg-uri-alias" and "reg-uri" are equivalent to "aor, 
>routed".
again 4244bis tags the entries entirely based on what SIP does and if
the 800 number translations (or whatever services) are setup 
>differently in different proxies, then you can't determine if the
"aor,routed" cases might be "reg-uri-alias" or "reg-uri".  Although, I
am personally confused as to whether an 800 number would always be 
>"aor, mapped" or "aor, routed" - i.e., I just don't see this being
deterministic and I think that if a service can reach a UAS through
different SIP retargeting mechanisms, then the UAS needs to be 
>aware. 

I think we are still debating the requirements.

I think Hans Erik's proposal (copied below) was very clear. If we can
agree on that, then we can start discussing the protocol. I think it is
useless to do a beauty contest on tags before we are clear on the
requirements...

-------

We have now:

------

the proxy to do the tagging - i.e., I think we need to add "-aor" to the
"predetermined", "reg-uri" and "reg-uri-alias" IF we agree 
>that the proxy will mark in this manner. "
>Mary. 
was the original intent for SIP - services in the endpoints - SIP is
just the signalling to carry the relevant information.

This is not about putting the serivce in the UAS (the translation may
still be done in the network). This is about having to configure the UAS
in order to somehow figure out what has happended - when we instead can
define a protocol mechanism to carry that information (as you said
yourself :)

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 22:08:54 +0200

I think this is a new requirement.

4244bis has introduced this distinction, so maybe you have a some 
requirement in mind.
Maybe you can explain why it is needed?

/Hans Erik

Mary Barnes wrote:
>> Correct. But, what I am suggesting is that you distinguish it at the
>>     
> UAS
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 22:13:48 +0200

Hi, 

Maybe not - that depends on the service. But, then it will at least be
possible to figure out what has happended.

My differentiation is based on my understanding of the requirements that
we have.

If you think we need to differentiate between req-uri and req-uri-alias,
then we should agree on such requirement. Let's not mix it with the
freephone requirement.

Regards,

Christer

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

UAS
both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 22:18:36 +0200

Just a subtle correction. The requirement is the delivery of the 
addressed target to the UAS, in order for it to be able to extract it.

We dont have a freephone service requirement, the freephone service is a 
scenario that is a testcase  which our solution should be able to cope with.

/Hans Erik

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 22:21:53 +0200

Correct.

Regards,

Christer 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 11:19 PM
To: Christer Holmberg
Cc: Mary Barnes; Francois Audet; DOLLY, MARTIN C, ATTLABS;
[email-masked]

We dont have a freephone service requirement, the freephone service is a
scenario that is a testcase  which our solution should be able to cope
with.

/Hans Erik

> will not need the differentiation that you do - i.e, they care about 
> the difference between "reg-uri" and "reg-uri-alias".
>
> My differentiation is based on my understanding of the requirements 
> that we have.
>
> If you think we need to differentiate between req-uri and 
> req-uri-alias, then we should agree on such requirement. Let's not mix

> it with the freephone requirement.
>
> Regards,
>
> Christer
>
>
>
>
>
> To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN 
> C, ATTLABS; [email-masked]

> "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias".  I 
> think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,
routed".
> And, I think one could consider the "aor,mapped" as predetermined. 
> But, again 4244bis tags the entries entirely based on what SIP does 
> and if the 800 number translations (or whatever services) are setup 

> different SIP retargeting mechanisms, then the UAS needs to be aware.
>
> Also, as I'm going through this, I think we need 3 more tags if we 
> want the proxy to do the tagging - i.e., I think we need to add "-aor"

> to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that

> the proxy will mark in this manner. "
>
>
> Mary. 

> that since the sort of service you mention that does not have a 
> standard SIP URI (i.e., user@domain) introduces something that isn't 
> accomodated in the basic SIP model, so we may need to add additional 
> logic to the proxies (I don't like it though).
>

> The logic is that the AOR is replaced with another AOR, which belongs 
> to the same user.
>
> It's not only for 800 numbers - they are just an example where it 
> would be useful.
>

> in terms of normal SIP request routing and forwarding, which is what 
> the current 4244bis tags have been defined to represent.
>
> forwarding" is all about. Normal SIP request routing and forwarding 
> has issues, which were presented in the ua-loose-route draft - and 
> that is why we are now working on a solution to solve those issues.
>
> Regards,
>
> Christer
>
>
>
>
(e.g.

mapped hi-entries.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 15:36:51 -0500

Debug/diagnostics - we've talked about this from day 1. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 3:09 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

/Hans Erik

Mary Barnes wrote:
> But, still with this approach, I do not think you can get away with 
> not looking for multiple tags with the way you envision doing your
services.

routed".

(e.g.

mapped hi-entries.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 15:37:53 -0500

But, the freephone service can be implemented also with a reg-uri or
reg-uri-alias - NOW if a specific service treats them the same, no big
deal. The UAS then looks for any of a set of tags to grab the
appropriate hi-entry. 

Mary.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 3:14 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

Regards,

Christer

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

UAS
both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 15 Jun 2009 22:40:02 +0200

Ok, so this is a 4244bis requirement, not a target-uri requirement. 
Thats fine. i have no problem with covering that, but Id like to be 
explicit on what requirement we are covering when.

BR,
/Hans Erik

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 22:44:16 +0200

Hi, 

>appropriate hi-entry. 

Req-uri and req-uri-alias replaces an AOR with a registered contact.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 3:14 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

Regards,

Christer

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

UAS
both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Jun 2009 22:49:44 +0200

So, if we decided upon the alias separation, could we use Hans Erik's
earlier proposal as base? We would then modify it so that it covers the
alias separation.

But, I agree with Hans Erik that we should have some
requirement/scenario which is covered, to show people why it is useful
to implement. 

Regards,

Christer

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 11:40 PM
To: Mary Barnes
Cc: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;
[email-masked]

BR,
/Hans Erik

>> snippet

freephone.

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Mon, 15 Jun 2009 17:10:02 -0400

no

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 4:38 PM
To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 3:14 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

Regards,

Christer

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

UAS
both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Jun 2009 20:43:45 -0500

All right guys,

I've been thinking about this.

It seems to me that what we want to capture is:
1) If the target is an AOR, a contact, or a routing URI (maddr, noop intra-domain, or noop
   forward to next domain, or strict routing).
2) In the case that the target is an AOR, then if that AOR is known to be an alias for the previous
   one, or if it is mapped to another AOR.

It seems to me that a Proxy should mark a Previous entry in H-I with aor if it determines that it 
owns this AOR. Just as Hans's current target-uri draft.

Now, for the mapped vs routed (versus reg-contact, etc.), instead of marking the Previous entry,
we should mark the OUTGOING (i.e., New) entry instead. This would make the procedures of
7.2.1 & 7.2.2 of target-URI draft clearer.

Specifically, the logic would be:

When proxy receives an incoming request with H-I, it adds an ;aor tag to that incoming
entry if it determines that it is responsible for the AOR and. 

Also, if there was no Hi-entry at all (i.e., it came from a UAC), and the Proxy creates 
then two entries, the first one in this case would also have the ;aor tag associated to it.

For the Outgoing entry, I would see the following tags:

rc	:	The entry is an explicit registered contact (i.e., it was provided in a REGISTER message)

ic	:	The entry is an implicit registered contact (i.e., it's exactly as a registered contact,
		but was not discovered using SIP Registration: it could have been manually configured
		or done with a proprietary mechanism).

		(TBD: we could debate if we need both rc and irc, but I think we do).

mp	:	The request-URI is changed to a new URI that represent another user.

rt	:	The entry is "routed", i.e., it is either a no-opt like a proxy forwarding within
		a domain, predetermined by a maddr in the Request-URI, or when proxy is NOT responsible
		for domain, or the address is an alias for the incoming URI.

So, to give an example. 

Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to Carol. 

The History-info at Carol would look like this:

Alice -> example.com
Nothing because UAC typically doesn't send H-I (otherwise, it
would be as per Index 1 in next entry, but without the AOR.

example.com -> [email-masked]
History-Info: <sip:[email-masked]>;index=1;aor
History-Info: <sip:[email-masked]>;index=1.1;mp

example.net -> [email-masked]
History-Info: <sip:[email-masked]>;index=1;aor           
History-Info: <sip:[email-masked]>;index=1.1;mp;aor  <- aor is added
History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor    }  Two entries are
History-Info: <sip:[email-masked]>;index=1.1.1.1;rc        }  added at same time

Also, I don't think we need to define an equivalent to the "reg-uri-alias" anymore.
If Freephone was configured to go to +14085551212 instead of the registered Contact
(assuming +14085551212 was an Alias AOR for [email-masked]), the last H-I entries would
look like this instead:

example.net -> [email-masked]
History-Info: <sip:[email-masked]>;index=1;aor     
History-Info: <sip:[email-masked];user=phone>;index=1.1;mp;aor <- aor is added 
History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor  <- aor is added
History-Info: <sip:[email-masked]>;index=1.1.1.1;rt;aor    }  Two entries are
History-Info: <sip:[email-masked]>;index=1.1.1.1.1;rc        }  added at same time

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Jun 2009 23:58:18 -0500

> as if you had called the 800 number?

Yes. I do this on a fairly regular basis. It's a way to get my inbound 
SIP calls forwarded to a free-phone number that's billed differently 
than my SIP gateway service is.

I sometimes se it to get US toll-free access when calling from Europe. I 
set my in-country SIP-provider number to forward to the US 800 number  I 
need to reach, make the GSTN call to the in-country local number, and 
get routed to the US 800 number call center as desired.

Oddly enough, this all works without H-I.

--
Dean

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 07:01:30 +0200

Hi,
Why not to adopt the cause-parameter principle of RFC 4458 and extend it for other service approaches.
The have a general cause-param for services other then call diversion and to have explicit cause parameters for free phone, "IN-services", calling card ect.
Such indications where asked a couples of times from other service providers.

BR,

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von DOLLY, MARTIN C, ATTLABS
Gesendet: Montag, 15. Juni 2009 23:10
An: Mary Barnes; Christer Holmberg; Francois Audet; [email-masked]
Betreff: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

no

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 4:38 PM
To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 3:14 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

Regards,

Christer

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

UAS
both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 07:38:08 +0200

Such values looks good and gives more guideline why the entry was included.
My question would be if there is a different network behaviour foreseen for the History mechanism.
Perhaps some of the networks needs the history only to indicate where the URI were mapped ("mp") and others would really track the whole history of each SIP proxy.
Or is it only seen either to support history full  or not.

BR,

Roland  

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Francois Audet
Gesendet: Dienstag, 16. Juni 2009 03:44
An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida Schubert
Cc: [email-masked]
Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

All right guys,

So, to give an example. 

Alice -> example.com

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Jun 2009 00:52:45 -0500

> I must admit I'm having trouble understanding the sutleties of the freephone service. 

It's not that complicated.

Think of it as an AOR (the  freephone number) to which a contact (the 
service nuumber) is registered.

Unfortunately, said contact is also registered to other AORs, and the 
B2BUA that terminates the call needs to know which AOR was used so it 
can figure out 1) how to bill for the call, and 2) how to route the call 
within the call center and what to display on the UAS.

My proposal: This is an obtuse legacy. Don't build SIP-based systems on 
the same model; contacts are cheap, locally-mintable, and you can use a 
different one for every AOR.

If you THINK you have a freephone problem that needs a specification 
extension to deal with it, you probably just have a badly designed 
deployment. Rethink the problem without forcibly holding your head in a 
bell shape.

Remember, this is not your mother's phone network.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 09:38:56 +0200

Hi Francois,

"rc" and "ic" look rather ok. But, for "ic" you need to change "but was not discovered using SIP Registration", because you may discover it using the P-Associated-URI header (if you support it). So, I propose something like:

ic	:	The entry is an implicit registered contact (i.e., it's exactly as a registered contact,
 		but was not provided in a REGISTER request: it could have been manually configured
 		or done with a proprietary mechanism).

But, I think there is a small missunderstading for the AOR-to-AOR cases.

We don't think you need to know whether the new AOR is an alias or not. You need to know whether the new AOR belongs to the same user or not.

So, in case of diversion, where the user is changed, I assume "mp" is used.

For freephone, where the user is not changed, one could use "rt". But, I don't think it matters in which domain the translation takes place, or whether the new AOR is an alias or not.

So, my proposal would be something like:

rt	:	The entry is "routed", i.e., it is either a no-opt like a proxy forwarding within
 		a domain, predetermined by a maddr in the Request-URI, or when the request-URI is changed to a new URI that represent the same user.

Regards,

Christer

> Sent: 16. kesäkuuta 2009 4:44
> To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; 
> Shida Schubert
> Cc: [email-masked]
> Subject: draft-barnes-sipcore-rfc4244bis and target-uri
> 
> All right guys,
> 
> It seems to me that a Proxy should mark a Previous entry in 
> H-I with aor if it determines that it owns this AOR. Just as 
> Hans's current target-uri draft.
> 
> Now, for the mapped vs routed (versus reg-contact, etc.), 
> instead of marking the Previous entry, we should mark the 
> OUTGOING (i.e., New) entry instead. This would make the procedures of
> When proxy receives an incoming request with H-I, it adds an 
> ;aor tag to that incoming entry if it determines that it is 
> responsible for the AOR and. 
> 
> Also, if there was no Hi-entry at all (i.e., it came from a 
> UAC), and the Proxy creates then two entries, the first one 
> in this case would also have the ;aor tag associated to it.
> 
> rc	:	The entry is an explicit registered contact 
> (i.e., it was provided in a REGISTER message)
> 
> ic	:	The entry is an implicit registered contact 
> (i.e., it's exactly as a registered contact,
> 		a domain, predetermined by a maddr in the 
> Request-URI, or when proxy is NOT responsible
> If Freephone was configured to go to +14085551212 instead of 
> the registered Contact (assuming +14085551212 was an Alias 
> AOR for [email-masked]), the last H-I entries would look 
> like this instead:
> 
> History-Info: 
> <sip:[email-masked];user=phone>;index=1.1;mp;aor <- 
> aor is added

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Tue, 16 Jun 2009 09:52:45 +0200

Hi Francois,

I think this tagging of the outgoing entry might actually be a good
idea.
Also the tagging of the contacts seems very intuitive and clear.

Also the procedure for the UAS trying to extract the adressed target
will become much simpler and intuitive.

I like where this is heading and I agree with Christers improvement
proposals.

Thanks,
/Hans Erik

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 3:44 AM
To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida Schubert
Cc: [email-masked]
Subject: draft-barnes-sipcore-rfc4244bis and target-uri

All right guys,

It seems to me that what we want to capture is:
1) If the target is an AOR, a contact, or a routing URI (maddr, noop
intra-domain, or noop
   forward to next domain, or strict routing).
2) In the case that the target is an AOR, then if that AOR is known to
be an alias for the previous
   one, or if it is mapped to another AOR.

It seems to me that a Proxy should mark a Previous entry in H-I with aor
if it determines that it owns this AOR. Just as Hans's current
target-uri draft.

Now, for the mapped vs routed (versus reg-contact, etc.), instead of
marking the Previous entry, we should mark the OUTGOING (i.e., New)
entry instead. This would make the procedures of
7.2.1 & 7.2.2 of target-URI draft clearer.

When proxy receives an incoming request with H-I, it adds an ;aor tag to
that incoming entry if it determines that it is responsible for the AOR
and. 

Also, if there was no Hi-entry at all (i.e., it came from a UAC), and
the Proxy creates then two entries, the first one in this case would
also have the ;aor tag associated to it.

rc	:	The entry is an explicit registered contact (i.e., it
was provided in a REGISTER message)

ic	:	The entry is an implicit registered contact (i.e., it's
exactly as a registered contact,
		but was not discovered using SIP Registration: it could
have been manually configured
		or done with a proprietary mechanism).

		(TBD: we could debate if we need both rc and irc, but I
think we do).

mp	:	The request-URI is changed to a new URI that represent
another user.

rt	:	The entry is "routed", i.e., it is either a no-opt like
a proxy forwarding within
		a domain, predetermined by a maddr in the Request-URI,
or when proxy is NOT responsible
		for domain, or the address is an alias for the incoming
URI.

So, to give an example. 

Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to
Carol. 

Alice -> example.com
Nothing because UAC typically doesn't send H-I (otherwise, it would be
as per Index 1 in next entry, but without the AOR.

example.net -> [email-masked]
History-Info: <sip:[email-masked]>;index=1;aor           
History-Info: <sip:[email-masked]>;index=1.1;mp;aor  <- aor is
added
History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor    }  Two
entries are
History-Info: <sip:[email-masked]>;index=1.1.1.1;rc        }  added at
same time

Also, I don't think we need to define an equivalent to the
"reg-uri-alias" anymore.
If Freephone was configured to go to +14085551212 instead of the
registered Contact (assuming +14085551212 was an Alias AOR for
[email-masked]), the last H-I entries would look like this instead:

example.net -> [email-masked]
History-Info: <sip:[email-masked]>;index=1;aor     
History-Info: <sip:[email-masked];user=phone>;index=1.1;mp;aor
<- aor is added
History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor  <- aor is
added
History-Info: <sip:[email-masked]>;index=1.1.1.1;rt;aor    }  Two
entries are
History-Info: <sip:[email-masked]>;index=1.1.1.1.1;rc        }  added
at same time

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 12:12:11 +0200

I would go even further. There are cases where it is useful to keep track of the services invoked during the establishment of a session, irrespective of whether these services have modified the R-URI or not. To achieve this, an application server providing service X would insert an entry in the History-Info header field with hi-target=noop, an unmodified R-URI and an extended cause-param set to a value representing service "X".

BC 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 16 juin 2009 07:02
À : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

BR,

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von DOLLY, MARTIN C, ATTLABS
Gesendet: Montag, 15. Juni 2009 23:10
An: Mary Barnes; Christer Holmberg; Francois Audet; [email-masked]
Betreff: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

no

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 4:38 PM
To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [sipcore] FW: I-D

Mary.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 3:14 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

Regards,

Christer

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Monday, June 15, 2009 2:53 PM
To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C,

Christer, 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 2:34 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi, 

UAS
both. 

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, June 15, 2009 1:23 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,

Hi Mary,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Monday, June 15, 2009 9:13 PM
To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;
[email-masked]

Mary.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 12:30:57 +0200

Hi,

>I would go even further. There are cases where it is useful 
>to keep track of the services invoked during the 
>establishment of a session, irrespective of whether these 
>services have modified the R-URI or not. To achieve this, an 
>application server providing service X would insert an entry 
>in the History-Info header field with hi-target=noop, an 
>unmodified R-URI and an extended cause-param set to a value 
>representing service "X".

I think that should be a completely separate discussion.

It is an interesting topic, but I think you would need to start it in DISPATCH or BLISS, because I think it is far beyond the scope of both 4244bis and target delivery :)

Regards,

Christer

> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked] Envoyé : mardi 16 juin 2009 07:02 À : 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked] Objet : Re: [sipcore] FW: I-D 
> Why not to adopt the cause-parameter principle of RFC 4458 
> and extend it for other service approaches.
> The have a general cause-param for services other then call 
> diversion and to have explicit cause parameters for free 
> phone, "IN-services", calling card ect.
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von DOLLY, 
> MARTIN C, ATTLABS
> Betreff: Re: [sipcore] FW: I-D 
>  But, the freephone service can be implemented also with a 
> reg-uri or reg-uri-alias - NOW if a specific service treats 
> them the same, no big deal. The UAS then looks for any of a 
> set of tags to grab the appropriate hi-entry. 
> 
> Mary.
> 
> req-uri-alias,
> differently
> because you may
> that it's an

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 09:27:45 -0400

> We don't think you need to know whether the new AOR is an alias or not. You need to know whether the new AOR belongs to the same user or not.

This concept is still bugging me.
Precisely what do you mean by "new AOR *belongs* to the same user"?
And why does that matter? You have said that these might reside in 
different domains, and that the tagging will simply be configured.
In the end it isn't the one doing the tagging that cares, rather it is 
the one receiving the tagged entry that cares isn't it? So in some sense 
this is a matter of the "owner" of the downstream URI instructing the 
owner of the upstream URI to tag the entry in a way that the downstream 
URI will recognize.

Yet doing it *that* abstractly is likely to lead to a tower of babel. 
I'm still groping for the semantic meaning of the tag. And in practice 
remain unconvinced that it is needed at all. If the owner of the 
downstream URI has requested the mapping from the owner of the upstream 
URI, doesn't it know what upstream URIs map to it? Can't it check them 
by value, without a tag?

Overall, what I am looking for is a complete partitioning of the space 
into disjoint subspaces covering the whole space. In the past, this 
partitioning as been done informally and incompletely as "AOR" vs. 
"Contact". We all knew that wasn't either disjoint or complete. And we 
have always acted as if this is an inherent property of a URI, rather 
than a usage context. But of course it isn't that simple - one person's 
AOR can be another person's Contact. The current approach is about 
describing the role of a URI in context, which at least has a chance to 
be determinable, so its at least on the right track.

The trouble with H-I in this regard is that there seems no good reason 
to believe that middleboxes will preserve the entries that will 
ultimately be required.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 09:40:41 -0400

(I changed the subject again)

On one hand I agree with Dean that the freephone semantics are legacy 
baggage that are inextricably entwined with the legacy implementation. 
There is little we can do to "fix" it. But when interoperating with the 
legacy telephone network it will continue to be an elephant in the room 
and cannot simply be ignored.

We could no doubt devise some much more useful alternatives to the "800" 
style of freephone service when the call is sip end to end. (I've 
thought for a long time that "who pays" should be negotiated in much the 
way that QoS is. Perhaps preconditions could be used to do it - even the 
e2e vs segmented models make sense.) But we will not be doing that in 
ietf since we never discuss billing in ietf.

In Dean's example below, what is free? And who would have been billed 
for it if it hadn't been free?

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 08:52:18 -0500

So, to summarize:
- the old entry is tagged with the "type of URI"
- the new entry is tagged with the mechanism by which the URI was
determined

Is that correct?  That's actually backwards from what I just told Dean,
but does make sense since you don't know anything about the "type of
URI" until it reaches a domain that is responsible for it. 

I have a couple comments/questions embedded below to make sure I
understand, as this is slightly different than what I had envisioned
when we discussed it yesterday. 

Mary. 

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Monday, June 15, 2009 8:44 PM
To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary (RICH2:AR00);
Shida Schubert
Cc: [email-masked]

All right guys,

[MB] I think this gets to the concern I had earlier about it looking to
be "two stage".  [/MB]

rt	:	The entry is "routed", i.e., it is either a no-opt like
a proxy forwarding within
		a domain, predetermined by a maddr in the Request-URI,
or when proxy is NOT responsible
		for domain, or the address is an alias for the incoming
URI.
[MB] I'm slightly confused as to why alias are in this bucket - aren't
aliases also registered contacts?  

Also, I would prefer to tag these explictly as we did with the current
definition of hi-target in 4244bis. I don't think it costs anything and
I think it could be useful for debug/diagnostics.  Also, I would prefer
we expand the labels a tad, something like:
reg-exp
reg-imp
mapped
route 
reg-alias

I could live without the alias, but per my comment above, it's not clear
to me that these are "routed". 
[/MB]

So, to give an example. 

Alice -> example.com

Also, I don't think we need to define an equivalent to the
"reg-uri-alias" anymore.
[MB] I'm not entirely comfortable with losing the alias concept. I would
think it could be useful for debug/diagnostic use cases. [/MB]

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 16:53:49 +0200

-----Message d'origine-----
De : Christer Holmberg [mailto:[email-masked]] 
Envoyé : mardi 16 juin 2009 12:31
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

>I would go even further. There are cases where it is useful to keep 
>track of the services invoked during the establishment of a session, 
>irrespective of whether these services have modified the R-URI or not. 
>To achieve this, an application server providing service X would insert 
>an entry in the History-Info header field with hi-target=noop, an 

==>BC: It's indeed different from the current focus of the discussion but I would not say that it a completely separate discussion as it may well be that 4244bis can provide a solution with minimum changes to 4.3.3.1.2 (Reason) in the current draft.

Regards,

Christer

> [mailto:[email-masked]] De la part de [email-masked] 
> Envoyé : mardi 16 juin 2009 07:02 À :
> [email-masked]; [email-masked]; [email-masked] 
> Objet : Re: [sipcore] FW: I-D 
> The have a general cause-param for services other then call diversion 
> and to have explicit cause parameters for free phone, "IN-services", 
> calling card ect.
> [mailto:[email-masked]] Im Auftrag von DOLLY, MARTIN C, 
> ATTLABS

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 07:55:18 -0700

> Precisely what do you mean by "new AOR *belongs* to the same user"?

It means you believe they are aliases of each others.

> owner of the upstream URI to tag the entry in a way that the downstream

I'm not totally convinced myself to be honest. I'm trying to please my
coauthors.

Basically, it allows you to distinguish between "routing" (i.e., call
progresses towards the called user, using various AORs that are aliases of
each other), and "retargeting" where call bounces off from one user to
another.

Why would you want to do that? To provide services that people grew
accustomed to such as Freephone, Voicemail, Contact center, and so forth.

And yes, there are probably other ways to do so. Fact is, none of these
services are exciting enough to justify spending braincells trying to do in
a completely different way, so most operators just copy their existing
designs. It also makes it easier to interop with existing systems.

(Again, I'm also not totally convinced).

> URI, doesn't it know what upstream URIs map to it? Can't it check them

I think I agree with you here. Maybe Christer or Hans can explain. I don't
understand why its needed.

> to believe that middleboxes will preserve the entries that will

We actually fixed that particular problem in 4244bis by making the entries
mandatory, and relying on anonymizing entries when privacy is required.

>> For freephone, where the user is not changed, one could use "rt". But, I
>> don't think it matters in which domain the translation takes place, or
>> whether the new AOR is an alias or not.
>> 
>> a domain, predetermined by a maddr in the Request-URI, or when the
>> request-URI is changed to a new URI that represent the same user.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 07:27:23 -0700

Correct.

To be more precise, the "Type of URI" has only two values, AOR, and
"nothing" (i.e., you don't recognize it as a URI).

You are correct about the "two-stages".

And the aliases I have at the bottom are NOT registered contact
necessarily.

When an alias is programmed (typically in a Proxy), say, for a freephone
service, it doesn't know if it will be a registered contact, or something
else. Normally, it would be another AOR. For example,
[email-masked];user=phone could be mapped to an alias of
[email-masked].

On the issue of why "short two-letter names", the official reason would be
to shorten the length of the headers (HI can be quite large), save the
planet etc.

(The "real' reason are:
 1- To facilitate my life when writing the call flows by increasing the
    chances that the entries fit on one line :-)
 2- UNIX geekiness :-)
)

Finally, on the "alias" concept: the aliases are not lost. I've entered them
as a specific entry. In the last example:
History-Info: <sip:[email-masked];user=phone>;index=1.1;mp;aor <-
aor is added
History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor  <- aor is
added

The same could apply at the end of sequence. For example, if I register with
To: <sip:[email-masked]> and <sip:[email-masked];user=phone> is
an alias, in the HI there would be an entry for
<sip:[email-masked];user=phone> followed by one for
<sip:[email-masked]>, both flagged as ;aor.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 07:46:03 -0700

Freephone is just a form of target diversion where the forwarder knows that
the new target represents the same user.

Call Forwarding (using PSTN terminology) is a form of target diversion where
the forwarder does not know if the new target represents the same user
(chances are it is not the same user, although people often forward their
calls to another phone number they have, even if these phone numbers are not
correlated anywhere).

In my proposal, I'm handling the difference with the presence of the ;mp tag
(mapped) which means the second case, i.e., you have no knowledge that the
two URIs belong to the same user.

How service providers use it to charge or not is totally irrelevant and
outside the scope of a technical spec. I will also note that there are free
versions of similar services out there.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:19:27 -0500

See below. 

> Sent: Tuesday, June 16, 2009 00:39
> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; 
> Barnes, Mary (RICH2:AR00); Shida Schubert
> Cc: [email-masked]
> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri
> 
> 
> 
> Hi Francois,
> 
> "rc" and "ic" look rather ok. But, for "ic" you need to 
> change "but was not discovered using SIP Registration", 
> because you may discover it using the P-Associated-URI header 
> (if you support it). So, I propose something like:
> 
> We don't think you need to know whether the new AOR is an 
> alias or not. You need to know whether the new AOR belongs to 
> the same user or not.

To me, that is the definition of an alias.

Correct.

> For freephone, where the user is not changed, one could use 
> "rt". But, I don't think it matters in which domain the 
> translation takes place, or whether the new AOR is an alias or not.

Correct: it would be rt.

> Request-URI, or when the request-URI is changed to a new URI 
> that represent the same user.

I'm ok with that.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:23:18 -0500

I agree with christer.

(Holy Cow! Twice in 5 minutes!) 

> Sent: Tuesday, June 16, 2009 03:31
> To: [email-masked]; [email-masked]; 
> [email-masked]; Barnes, Mary (RICH2:AR00); Audet, Francois 
> (SC100:3055); [email-masked]
> It is an interesting topic, but I think you would need to 
> start it in DISPATCH or BLISS, because I think it is far 
> beyond the scope of both 4244bis and target delivery :)
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> diversion 
> reg-uri or

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 19:29:51 +0200

Hi,

>>We don't think you need to know whether the new AOR is an alias or 
>>not. You need to know whether the new AOR belongs to the same user or 
>>not.
>

Fine, but that is not the current definition in 4244bis, which says that
an alias is an implictity/explicitly registered AOR... With your new
definition an alias may be registered, or it may not. It may be an AOR,
or it may not.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:32:09 -0500

Yeah, I would fix that.

So....

So, it looks like we are in agreement. I think I should up-issue the document.

Agreed?

> Sent: Tuesday, June 16, 2009 10:30
> Fine, but that is not the current definition in 4244bis, 
> which says that an alias is an implictity/explicitly 
> registered AOR... With your new definition an alias may be 
> registered, or it may not. It may be an AOR, or it may not.
> 
> Regards,
> 
> Christer
> 
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 16 Jun 2009 13:37:38 -0400

And in summary....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francois Audet
Sent: Tuesday, June 16, 2009 1:32 PM
To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida Schubert
Cc: [email-masked]
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

Yeah, I would fix that.

So....

So, it looks like we are in agreement. I think I should up-issue the
document.

Agreed?

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 12:40:51 -0500

Now, I'm confused as I thought the alias must be an AOR.  I'm in the
midst of a response to another email on this topic.   

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Tuesday, June 16, 2009 12:32 PM
To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary (RICH2:AR00);
Shida Schubert
Cc: [email-masked]

Yeah, I would fix that.

So....

Agreed?

> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Barnes, Mary 
> (RICH2:AR00); Shida Schubert
> Cc: [email-masked]
> Fine, but that is not the current definition in 4244bis, which says 
> that an alias is an implictity/explicitly registered AOR... With your 
> new definition an alias may be registered, or it may not. It may be an

> AOR, or it may not.

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 12:41:23 -0500

I can live with the short names (I guess), as long as it doesn't bother
anyone else. So, the aliases then are "implicit" versus "explicit" -
i.e., you'll know that it's an alias because it will be labeled with the
..;rt;aor tags?

Mary. 

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Tuesday, June 16, 2009 9:58 AM
To: Barnes, Mary (RICH2:AR00); Christer Holmberg; Hans Erik van Elburg;
Shida Schubert
Cc: [email-masked]
Subject: Re: draft-barnes-sipcore-rfc4244bis and target-uri

Correct.

When an alias is programmed (typically in a Proxy), say, for a freephone
service, it doesn't know if it will be a registered contact, or
something else. Normally, it would be another AOR. For example,
[email-masked];user=phone could be mapped to an alias of
[email-masked].

On the issue of why "short two-letter names", the official reason would
be to shorten the length of the headers (HI can be quite large), save
the planet etc.

(The "real' reason are:

Finally, on the "alias" concept: the aliases are not lost. I've entered
them as a specific entry. In the last example:
History-Info: <sip:[email-masked];user=phone>;index=1.1;mp;aor
<- aor is added
History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor  <- aor is
added

The same could apply at the end of sequence. For example, if I register
with
To: <sip:[email-masked]> and
<sip:[email-masked];user=phone> is an alias, in the HI there
would be an entry for <sip:[email-masked];user=phone> followed
by one for <sip:[email-masked]>, both flagged as ;aor.

On Jun16 2009 06:52 , "Barnes, Mary (RICH2:AR00)"
<[email-masked]>
wrote:

> Is that correct?  That's actually backwards from what I just told 
> Dean, but does make sense since you don't know anything about the 
> "type of URI" until it reaches a domain that is responsible for it.
> 
> To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary 

> It seems to me that a Proxy should mark a Previous entry in H-I with 
> aor if it determines that it owns this AOR. Just as Hans's current 
> target-uri draft.
> 
> [MB] I think this gets to the concern I had earlier about it looking 
> to be "two stage".  [/MB]
> 
> When proxy receives an incoming request with H-I, it adds an ;aor tag 
> to that incoming entry if it determines that it is responsible for the

> AOR and.
> ic : The entry is an implicit registered contact (i.e., it's exactly 
> as a registered contact, but was not discovered using SIP 
> Registration: it could have been manually configured or done with a 
> proprietary mechanism).
> 
> rt : The entry is "routed", i.e., it is either a no-opt like a proxy 
> forwarding within a domain, predetermined by a maddr in the 
> Request-URI, or when proxy is NOT responsible for domain, or the 
> address is an alias for the incoming URI.

> definition of hi-target in 4244bis. I don't think it costs anything 
> and I think it could be useful for debug/diagnostics.  Also, I would 
> prefer we expand the labels a tad, something like:
> reg-exp
> reg-imp
> mapped
> route
> reg-alias
> 
> I could live without the alias, but per my comment above, it's not 
> clear to me that these are "routed".
> [/MB]
> 
> So, to give an example.
> 

> [MB] I'm not entirely comfortable with losing the alias concept. I 
> would think it could be useful for debug/diagnostic use cases. [/MB]
> 
> <sip:[email-masked];user=phone>;index=1.1;mp;aor
> <- aor is added

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:39:48 -0500

It is.

But the "guy" who forwards to an AOR doesn't know that it's necessarily
an AOR.

That's why it gets tagged as AOR later. 

> Sent: Tuesday, June 16, 2009 10:41
> To: Audet, Francois (SC100:3055); 'Christer Holmberg'; 'Hans 
> Erik van Elburg'; 'Shida Schubert'
> Cc: [email-masked]'
> Now, I'm confused as I thought the alias must be an AOR.  I'm 
> in the midst of a response to another email on this topic.   
> 
> alias or

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:41:19 -0500

Correct: you will know they are AOR when they get tagged as such by the
domain who owns the AOR.

That works well when going through multiple hops.

> To: Audet, Francois (SC100:3055); Christer Holmberg; Hans 
> Erik van Elburg; Shida Schubert
> Cc: [email-masked]
> I can live with the short names (I guess), as long as it 
> doesn't bother anyone else. So, the aliases then are 
> "implicit" versus "explicit" - i.e., you'll know that it's an 
> alias because it will be labeled with the ..;rt;aor tags?
> 
> Mary.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:21:36 -0500

In the new draft, the entries are always there and never removed. It makes
HI much more reliable.

If entries need to be anonymous, they are anonymized but the entry is still there. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, June 15, 2009 22:38
> To: Audet, Francois (SC100:3055); 
> [email-masked]; [email-masked]; 
> Barnes, Mary (RICH2:AR00); [email-masked]
> Cc: [email-masked]
> Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri
> 
> My question would be if there is a different network 
> behaviour foreseen for the History mechanism.
> Perhaps some of the networks needs the history only to 
> indicate where the URI were mapped ("mp") and others would 
> really track the whole history of each SIP proxy.
> [mailto:[email-masked]] Im Auftrag von Francois Audet

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 19:43:47 +0200

>Yeah, I would fix that.

Then I think you should add a note saying that your definition of
"alias" is different than the definition in 3GPP - to avoid confusion.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 13:44:01 -0400

> To me, that is the definition of an alias.

I have to differ here.

I may own a bunch of AORs. Some of them may be aliases, others may not 
be. For instance:

- sip:[email-masked] and [email-masked]
   might be aliases.

- sip:[email-masked] and sip:[email-masked]
   may be designed to bucket specific kinds of traffic, and so
   not be aliases.

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 12:46:46 -0500

Correct - this is what I tried to summarize in this email:
http://www.ietf.org/mail-archive/web/sipcore/current/msg00429.html

And, we are getting the threads all mixed, so maybe a summary of where
we are now would be helpful.

Thanks,
Mary. 

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Tuesday, June 16, 2009 12:40 PM
To: Barnes, Mary (RICH2:AR00); 'Christer Holmberg'; 'Hans Erik van
Elburg'; 'Shida Schubert'
Cc: [email-masked]'
Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri

It is.

> To: Audet, Francois (SC100:3055); 'Christer Holmberg'; 'Hans Erik van 
> Elburg'; 'Shida Schubert'
> Cc: [email-masked]'

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 16 Jun 2009 19:51:58 +0200

short names are fine

/Hans Erik

Francois Audet wrote:
> Do people prefer short names or long names?
>
> I don't care much. I was just in a short name a-la ;lr type
> of mood.
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 19:52:06 +0200

>   may be designed to bucket specific kinds of traffic, and so

That is why I like the 3GPP definition of alias, which 4244bis currently
also uses.

But, again, based on that definition a freephone number does not have to
be an alias: the 1-800 number is not necessarily registered for the
called user.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:52:44 -0500

I'm thinking it's the first case we are talking about.

The second case IMHO is multiple logical users.

But I see your point. We need to word this carefully.

Christer, I still don't get what's wrong with the 
3GPP terminology. Can you clarify? 

> Sent: Tuesday, June 16, 2009 10:44
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary 
> (RICH2:AR00); Shida Schubert; [email-masked]
> I may own a bunch of AORs. Some of them may be aliases, 
> others may not be. For instance:
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 19:57:46 +0200

>Christer, I still don't get what's wrong with the 3GPP terminology. Can
you clarify? 

I think the 3GPP terminology is just fine :)

What I am saying is that a freephone number is not necessarily an alias
- based on the 3GPP terminology.

The 1-800 number is not necessarily implicitly registered for the AOR it
is translated into.

Regards,

Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 16 Jun 2009 20:00:22 +0200

Bringing back the 3gpp definition:

*Alias Public User Identities:* A Public User Identity is an alias of 
another Public User Identity if both identities belong to the same 
implicit registration set, are linked to the same service profile and 
have the same service data configured for each and every service.

In this sense the freephone number that I have is not an alias of my 
normal AOR, because different service logic is invoked and different 
service data applies.

You had a similar definition in 4244bis.

BR,
/Hans Erik

Francois Audet wrote:
>>>> not. You need to know whether the new AOR belongs to the 
>>>>         
>> same user or 
>>     
>>>> not.
>>>>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 12:43:45 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 14:14:29 -0400

If I understand 3gpp terminology correctly, then I think that definition 
of alias is really problematic here.

Specifically, in 3pgg AFAIK there is no real distinction between a 
primary AOR and its aliases - there are just a bunch of URIs that are 
siblings. When you register with any one of the siblings, it shares the 
registered contacts with the others.

So when a request arrives addressed to one of the siblings, then it is 
immediately retargeted to the registered contacts. There is no 
translation from the "alias" to the "real AOR" and then to the contacts. 
So any H-I tagging that implied such a translation would be problematic.

Or have things changed since I was last paying attention to 3gpp? (Which 
has been a couple of years now.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 14:18:01 -0400

> I don't care much. I was just in a short name a-la ;lr type

While I don't like really-really-long-names for this sort of use, I 
don't love really short ones either. IMO best would be short words or 
acronyms that make some sense without being memorized.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 16 Jun 2009 20:22:20 +0200

Exactly it is confusing, to use this term for AOR -> AOR translations 
where both AOR's belong to the same user.

There is no need for special tagging in this case, as the UA knows with 
which AOR it registered.

In IMS the AOR that was called is delivered to the UA in the 
P-Called-Party-ID, in the solution that Francois sketched it would be 
the last hi-entry that is tagged "aor".

/Hans Erik

Paul Kyzivat wrote:
> If I understand 3gpp terminology correctly, then I think that 
> definition of alias is really problematic here.
>
> siblings. When you register with any one of the siblings, it shares 
> the registered contacts with the others.
>
> translation from the "alias" to the "real AOR" and then to the 
> contacts. So any H-I tagging that implied such a translation would be 
> problematic.
>
> Or have things changed since I was last paying attention to 3gpp? 
> (Which has been a couple of years now.)
>
>     Thanks,
>     Paul
>
> Christer Holmberg wrote:
>>  
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Jun 2009 20:22:30 +0200

I prefer something longer than two characters. Two characters does not even aid my failing memory in trying to work out what it is. I don't believe it needs to be fixed length either. Providing we don't get exceedingly long either - lets just say they should not exceed 20 per cent of average URI length (plucking figures out of the air). With two characters you might just as well use a bitstring or some other binary concept.

Keith

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, June 16, 2009 7:18 PM
> To: Francois Audet
> Cc: [email-masked]; Shida Schubert
> > I don't care much. I was just in a short name a-la ;lr type of mood.
> 
> While I don't like really-really-long-names for this sort of 
> use, I don't love really short ones either. IMO best would be 
> short words or acronyms that make some sense without being memorized.
> 
> 	Thanks,
> 	Paul
> 
> 
> >> To: Audet, Francois (SC100:3055); Christer Holmberg; Hans Erik van 
> >> Elburg; Shida Schubert
> >> Cc: [email-masked]
> >> I can live with the short names (I guess), as long as it doesn't 
> >> bother anyone else. So, the aliases then are "implicit" versus 
> >> "explicit" - i.e., you'll know that it's an alias because 
> it will be 
> >> labeled with the ..;rt;aor tags?

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 16:23:24 +0200

Hi, 

>>"rc" and "ic" look rather ok. But, for "ic" you need to change "but was not discovered using SIP Registration", 
>>because you may discover it using the P-Associated-URI header (if you support it). So, I propose something like:
>> 

Mabye bad wording. Is a synonym to the same user. Both AORs point to the same user.

I call 1-800-DUDE, which is translated by a freephone service to [email-masked]. 

>And why does that matter? You have said that these might 
>reside in different domains, and that the tagging will simply 
>be configured.

The translation will be configured, as part of the service, yes.

>In the end it isn't the one doing the tagging that cares, 
>rather it is the one receiving the tagged entry that cares 
>isn't it?

Yes. The tagging is done so that the receiver knows what/where has happended.

>So in some sense this is a matter of the "owner" of 
>the downstream URI instructing the owner of the upstream URI 
>to tag the entry in a way that the downstream URI will recognize.
> 
>I'm still groping for the semantic meaning of the tag. And in 
>practice remain unconvinced that it is needed at all. If the 
>owner of the downstream URI has requested the mapping from 
>the owner of the upstream URI, doesn't it know what upstream 
>URIs map to it? Can't it check them by value, without a tag?

You are making the assumption that the called user has all the information, but we don't think that should be mandated.

Also, if you have some kind of gateway which needs the information, and the gateway serves thousands of users, you would have to configure all that information for each and every user served by the gateway.

So, why should one be mandated to use configuration for this, when it can be indicated in the signalling?

Regards,

Christer

> 
> Overall, what I am looking for is a complete partitioning of 
> the space into disjoint subspaces covering the whole space. 
> In the past, this partitioning as been done informally and 
> incompletely as "AOR" vs. 
> "Contact". We all knew that wasn't either disjoint or 
> complete. And we have always acted as if this is an inherent 
> property of a URI, rather than a usage context. But of course 
> it isn't that simple - one person's AOR can be another 
> person's Contact. The current approach is about describing 
> the role of a URI in context, which at least has a chance to 
> The trouble with H-I in this regard is that there seems no 
> good reason to believe that middleboxes will preserve the 
> entries that will ultimately be required.
> 
> 	Thanks,
> 	Paul
> 
> >> 2) In the case that the target is an AOR, then if that AOR 
> is known 
> >> to be an alias for the previous
> instead of 
> >> to that incoming entry if it determines that it is responsible for 
> >> the AOR and.
> >>
> >> 		(TBD: we could debate if we need both rc and 
> irc, but I think we 
> >> do).
> >>
> >> Say Alice calls Bob. Bob is forwarded to freephone. 
> Freephone routes 
> >> to Carol.
> >>
> >> Nothing because UAC typically doesn't send H-I (otherwise, 
> it would 
> >> be as per Index 1 in next entry, but without the AOR.
> >>
> <- aor is

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 14:29:37 -0400

> the last hi-entry that is tagged "aor".

Then we shouldn't be using the 3gpp definition of alias in this discussion.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Jun 2009 20:33:29 +0200

Can we also not have a history-info specific meaning for the word "alias".

It gets used in RFC 3325 without formal definition (if I recall correctly) and in a number of other documents as well.

By giving it a more specific meaning here, you may end up changing the meaning of other RFCs.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: Tuesday, June 16, 2009 6:41 PM
> To: Francois Audet; Christer Holmberg; Hans Erik van Elburg; 
> Shida Schubert
> Cc: [email-masked]

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 14:02:38 -0500

Keith, 

The term "alias" is not used in RFC 3325. It is used once in RFC 3324
and I can't see that the proposed definition is confusing or conflicting
as it is used in a fairly general sense. The term alias is used once in
GRUU:
   "In cases where the UA uses a tel URI (as
   defiend in [11]) to populate the From header field, the UA typically
   has a SIP AOR that is treated as an alias for the tel URI."
And, the reference [11] does not use the term alias. 

Identity (RFC 4474) does use the term alias (once):
      "It must be possible for a user to have multiple AoRs (i.e.,
      accounts or aliases) that it is authorized to use within a
      domain..."

The most prolific user of the term alias is connection-reuse, where the
term is defined, but that context is entirely different than what we are
talking about here, so I don't see a problem. 

And, I don't see any more suspects of concern when I google:
draft-ietf-sip alias  I found one enum document that talks about
aliasing with DNS. Digging down to the 3rd page of hits, Hannes does use
it in one of his docs about SPIT, but again the usage is consistent with
the usage in Identity.  And, if you dig down to the fourth page, you can
find an interesting patent that uses the term. One thing I have found
with google is that you do get different results with different browsers
- I used IE.

So, I don't see the concern, since the most explicit usage in Identity
is exactly what I thought we were talking about.  Once we finally agree
these terms, we are proposing to write an update to section 16.5 in RFC
3261 since the plan is to define precise terms for the mechanisms by
which the targets are determined. 

Regards,
Mary

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 1:33 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Christer
Holmberg; Hans Erik van Elburg; Shida Schubert
Cc: [email-masked]
Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri

Can we also not have a history-info specific meaning for the word
"alias".

It gets used in RFC 3325 without formal definition (if I recall
correctly) and in a number of other documents as well.

By giving it a more specific meaning here, you may end up changing the
meaning of other RFCs.

regards

Keith 

> To: Francois Audet; Christer Holmberg; Hans Erik van Elburg; Shida 
> Schubert
> Cc: [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 21:41:28 +0200

Hi,

draft-rosenberg-sipcore-target-uri-delivery-00 also talks about aliases
(the text origins from the ua-loose-route draft).

In chapter 4.1 the 3GPP definition is used.

Chapter 4.6 (Toll free numbers) talks about "aliases in the PSTN
network", but there is no real definition of what it really means.

So, why can't we use the 3GPP definition for "alias", and when we talk
about something else we could use "synonym"? Francois has already used
that term.

Using that terminology, in the freephone case the 1-800 number would be
replaced by a synonym - not an alias.

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 10:03 PM
To: DRAGE, Keith (Keith); Francois Audet; Christer Holmberg; Hans Erik
van Elburg; Shida Schubert
Cc: [email-masked]
Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri

Keith, 

Regards,
Mary

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Tuesday, June 16, 2009 1:33 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Christer

regards

Keith

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 21:42:36 +0200

>> There is no need for special tagging in this case, as the UA knows 
>> with which AOR it registered.
>> 

>Then we shouldn't be using the 3gpp definition of alias in this
discussion.

I think we can use it. But, when we talk about something else we should
use another word.

Regards,

Christer

>> So when a request arrives addressed to one of the siblings, then it 
>> is immediately retargeted to the registered contacts. There is no 

>>>> Christer, I still don't get what's wrong with the 3GPP terminology.

>>>> Can
>>> The 1-800 number is not necessarily implicitly registered for the 
>>> AOR it is translated into.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>>>> But, I think there is a small missunderstading for the AOR-to-AOR

>>>>>> cases.
>>>>>>
>>>>>> We don't think you need to know whether the new AOR is an alias 
>>>>>> or not. You need to know whether the new AOR belongs to the
>>>> same user or
>>>>>> not.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 14:56:45 -0500

That works for me. 

> Sent: Tuesday, June 16, 2009 12:41
> To: Barnes, Mary (RICH2:AR00); DRAGE, Keith (Keith); Audet, 
> Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert
> Cc: [email-masked]
> draft-rosenberg-sipcore-target-uri-delivery-00 also talks 
> about aliases (the text origins from the ua-loose-route draft).
> 
> Chapter 4.6 (Toll free numbers) talks about "aliases in the 
> PSTN network", but there is no real definition of what it 
> really means.
> 
> So, why can't we use the 3GPP definition for "alias", and 
> when we talk about something else we could use "synonym"? 
> Francois has already used that term.
> 
> Using that terminology, in the freephone case the 1-800 
> number would be replaced by a synonym - not an alias.
> 
> Regards,
> 
> Christer
> 
>  
> 
> To: DRAGE, Keith (Keith); Francois Audet; Christer Holmberg; 
> Hans Erik van Elburg; Shida Schubert
> Cc: [email-masked]
> The term "alias" is not used in RFC 3325. It is used once in 
> RFC 3324 and I can't see that the proposed definition is 
> confusing or conflicting as it is used in a fairly general 
> sense. The term alias is used once in
> GRUU:
> The most prolific user of the term alias is connection-reuse, 
> where the term is defined, but that context is entirely 
> different than what we are talking about here, so I don't see 
> a problem. 
> 
> draft-ietf-sip alias  I found one enum document that talks 
> about aliasing with DNS. Digging down to the 3rd page of 
> hits, Hannes does use it in one of his docs about SPIT, but 
> again the usage is consistent with the usage in Identity.  
> And, if you dig down to the fourth page, you can find an 
> interesting patent that uses the term. One thing I have found 
> So, I don't see the concern, since the most explicit usage in 
> Identity is exactly what I thought we were talking about.  
> Once we finally agree these terms, we are proposing to write 
> an update to section 16.5 in RFC
> 3261 since the plan is to define precise terms for the 
> mechanisms by which the targets are determined. 
> 
> Regards,
> Mary
> 
> Christer Holmberg; Hans Erik van Elburg; Shida Schubert
> Cc: [email-masked]
> which says

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 22:12:35 +0200

>We can use synonyms if alias is too confusing. 

We can use both, when appropriate :)

>Or like Mary says, we can just define alias for the purpose of this
document.

I don't think we should do that. The 3GPP definition of "alias" is
useful for the "ic" tag, I believe.

Regards,

Christer

> Sent: Tuesday, June 16, 2009 12:03
> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer 
> and I can't see that the proposed definition is confusing or 
> conflicting as it is used in a fairly general sense. The term alias is

> used once in GRUU:
> The most prolific user of the term alias is connection-reuse, where 
> the term is defined, but that context is entirely different than what 
> we are talking about here, so I don't see a problem.
> 
> aliasing with DNS. Digging down to the 3rd page of hits, Hannes does 
> use it in one of his docs about SPIT, but again the usage is 
> consistent with the usage in Identity.
> And, if you dig down to the fourth page, you can find an interesting 
> patent that uses the term. One thing I have found with google is that 
> you do get different results with different browsers - I used IE.
> 

> is exactly what I thought we were talking about.
> Once we finally agree these terms, we are proposing to write an update

> to section 16.5 in RFC 3261 since the plan is to define precise terms 
> for the mechanisms by which the targets are determined.
> 
> Regards,
> Mary

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 15:13:23 -0500

Ok, I agree. 

> Sent: Tuesday, June 16, 2009 13:13
> To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); 
> DRAGE, Keith (Keith); Hans Erik van Elburg; Shida Schubert
> Cc: [email-masked]
> I don't think we should do that. The 3GPP definition of 
> "alias" is useful for the "ic" tag, I believe.
> 
> Regards,
> 
> Christer
> 
> 
> 
> interesting

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 16:20:34 -0400

A problem here is that "synonym" is the appropriate term for what 3gpp 
is calling "alias". If we we adopt the 3gpp usage of alias, then what to 
you want to use "synonym" for?

Alias has the connotation that it is just a substitute for the "real" name.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 14:55:27 -0500

> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); 
> sense. The term alias is used once in GRUU:
> with google is that you do get different results with 
> different browsers - I used IE.
> 
> an update to section 16.5 in RFC 3261 since the plan is to 
> define precise terms for the mechanisms by which the targets 
> are determined. 
> 
> Regards,
> Mary

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 22:32:59 +0200

We would use "synonym" when an AOR is replaced with an AOR pointing to
the same user, but the AOR is NOT an alias (per 3GPP definition).

>Alias has the connotation that it is just a substitute for the "real"
name.

Alias is whatver we define it to be - and that is why I think it has to
be very clear what we mean.

Regards,

Christer

>> Identity

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2009 16:53:58 -0400

> be very clear what we mean.

Yes, we can make the word mean whatever we want.
But if we make our word differ greatly from standard English usage then 
we are going to confuse people greatly.

If we use both "synonym" and "alias", and use them in such a way that 
the distinction between them is opposite of the difference between them 
in English usage, then we are really asking for trouble.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 16 Jun 2009 22:57:34 +0200

A solution would be to not use the term at all in the definitions, but 
just describe what we mean.

/Hans Erik

Paul Kyzivat wrote:
> But if we make our word differ greatly from standard English usage 
> then we are going to confuse people greatly.
>
> the distinction between them is opposite of the difference between 
> them in English usage, then we are really asking for trouble.
>
>     Thanks,
>     Paul
>
>> Christer Holmberg wrote:
>>>  
>>>
>>>> aliasing with DNS. Digging down to the 3rd page of hits, Hannes 
>>>> does use it in one of his docs about SPIT, but again the usage is 
>>>> interesting patent that uses the term. One thing I have found with 
>>>> google is that
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 23:03:46 +0200

Hi, 

>>>is calling "alias". If we we adopt the 3gpp usage of alias, then what
to you want to use "synonym" for?

>>Alias is whatver we define it to be - and that is why I think it has 
>>to be very clear what we mean.
>

We will confuse people even more if we use different definitions in
different SIP related specifications. And, if 3GPP at some point would
adopt 4244bis it would cause a mess, since there would be conflicting
definitions.

Regards.

Christer

>>> conflicting as it is used in a fairly general sense. The term alias 
>>> is used once in GRUU:

>>> Once we finally agree these terms, we are proposing to write an 
>>> update to section 16.5 in RFC 3261 since the plan is to define 
>>> precise terms
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Jun 2009 23:07:51 +0200

Yes. And, the small changes modifications that I propsed to a couple of
the tags earlier (and which Francois seemede to be fine with) did not
contain the work alias or synonym.

The "ic" definition doesn't mention "alias", and my proposed change to
"rt" doesn't mention "alias".

Regards,

Christer

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 11:58 PM
To: Paul Kyzivat
Cc: Christer Holmberg; Francois Audet; Mary Barnes; DRAGE, Keith
(Keith); Shida Schubert; [email-masked]
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

/Hans Erik

>> We would use "synonym" when an AOR is replaced with an AOR pointing 
>> to the same user, but the AOR is NOT an alias (per 3GPP definition).
>>
>>> Alias has the connotation that it is just a substitute for the
"real"

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 16 Jun 2009 17:53:22 -0500

So, if we keep the current narrow scope for alias in 4244bis, then I
think we need something else for things that are configured, but not
necessarily AORs or aliases. In which case, can we not use the "mapped"
that is defined in 4244bis?  

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 12:52 PM
To: Paul Kyzivat; Audet, Francois (SC100:3055)
Cc: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida Schubert;
[email-masked]
Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 17 Jun 2009 06:53:52 +0200

Hi, 

>So, if we keep the current narrow scope for alias in 4244bis, then I
think we need something else for things that are 
>configured, but not necessarily AORs or aliases. In which case, can we
not use the "mapped" that is defined in 4244bis?  

Again, then we are back at the situation where we are not able to
distinguish between the case when the AOR does represent the same user,
and when it doesn't.

I think Francois's current proposal for mapped (mp), where the user IS
changed, is good:

"mp	:	The request-URI is changed to a new URI that represent
another user."

"rt" works fine for the case where the user isn't changed, if we do the
small editorial changes I proposed to Francois earlier (and which he
seemed to be ok with).

And, as Hans Erik said, maybe we don't need to talk about aliases etc in
the fist place, in which case we don't need to worry about what it means
:)

Regards,

Christer

> Cc: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida 
> Schubert; [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 16 Jun 2009 22:01:49 -0700

lemme look into it tomorrow. Kinda getting late.

On Jun 16, 2009, at 21:53, "Christer Holmberg" <[email-masked]

---

From: <[email-masked]>
Date: Wed, 17 Jun 2009 08:00:38 +0200

I have slide concerns with that approach. Some network operators does not like to present all the way of messages.
Even if the entry is anonymous the amount of entries will show the network structure which could also raise security concerns.

BR, Roland 

-----Ursprüngliche Nachricht-----
Von: Francois Audet [mailto:[email-masked]] 
Gesendet: Dienstag, 16. Juni 2009 19:22
An: Jesske, Roland; [email-masked]; [email-masked]; Mary Barnes; [email-masked]
Cc: [email-masked]
Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

> irc, but I think we do).

---

From: <[email-masked]>
Date: Wed, 17 Jun 2009 08:34:31 +0200

Is it really a complete separate discussion?

In defining a parameter that is a hint that the uri was changed due to some "magic" in a server, why not to point to some existing mechanism and use it.

Either we could mention that a drafts exisists that has the possibility of "cause parameters" and some extensions are needed to express also other services than CDIV. And define a additional draft for this values.

Or add a section with some additional cause parameters.

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:[email-masked]] 
Gesendet: Dienstag, 16. Juni 2009 12:31
An: [email-masked]; Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 17 Jun 2009 09:24:08 +0200

Hi, 

>Is it really a complete separate discussion?

It is a separate requirement.
 
>In defining a parameter that is a hint that the uri was 
>changed due to some "magic" in a server, why not to point to 
>some existing mechanism and use it.
>
>Either we could mention that a drafts exisists that has the 
>possibility of "cause parameters" and some extensions are 
>needed to express also other services than CDIV. And define a 
>additional draft for this values.

We are working on a solution to in a generic way indicate WHAT has happened.

I believe you are talking about WHY it happended.

Again, I think it is an interesting topic, and maybe something we should look at, but I think we should keep it separated.

Regards,

Christer

> An: [email-masked]; Jesske, Roland; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Betreff: RE: [sipcore] FW: I-D

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 17 Jun 2009 10:26:43 +0200

Hi Roland,

For that you would use IBCF or SBC topology hiding functionality on the
boundary of you're network. This is not an issue for the 4424bis, if it
where it would be an issue with 4424 too.

BR,
/Hans Erik van Elburg

On Wed, Jun 17, 2009 at 8:00 AM, <[email-masked]> wrote:

> Even if the entry is anonymous the amount of entries will show the network
> structure which could also raise security concerns.
>
> BR, Roland
>
> An: Jesske, Roland; [email-masked];
> [email-masked]; Mary Barnes; [email-masked]
> Cc: [email-masked]
> > History-Info: <sip:[email-masked] <[email-masked]>>;index=1;aor
> > History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1;mp
> >
> > History-Info: <sip:[email-masked] <[email-masked]>>;index=1;aor
> > History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1;mp;aor
> > <- aor is added
> > History-Info: <sip:[email-masked] <[email-masked]>>;index=1.1.1;rt;aor
>    }
> >  Two entries are
> > History-Info: <sip:[email-masked] <[email-masked]>>;index=1.1.1.1;rc
>        }
> >  added at same time
> >
> > History-Info: <sip:[email-masked] <[email-masked]>>;index=1;aor
> > History-Info:
> > <sip:[email-masked] <[email-masked]>;user=phone>;index=1.1;mp;aor
> <-
> > aor is added
> > History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1.1;rt;aor
> > <- aor is added
> > History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1.1.1;rt;aor
> > }  Two entries are
> > History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1.1.1.1;rc
> > }  added at same time

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 17 Jun 2009 10:05:43 -0500

Roland,

If you need additional "cause" parameters, then we really should consider extensions to the Reason header in RFC 3326.  

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 1:35 AM
To: [email-masked]; [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); [email-masked]
Subject: AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Dienstag, 16. Juni 2009 12:31
An: [email-masked]; Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 17 Jun 2009 10:10:16 -0500

Roland,

There is still room in the document for the the functionality you mention in section 3.2:

   Thus, local policy MAY also be used to determine whether to include the History-Info
   header at all, whether to capture a specific Request-URI in the
   header as is, whether it be included only in the Request as it is
   retargeted within a specific domain, or whether it is anonymized when
   being retargeted outside a specific domain (PRIV-req-3).  The latter
   two cases can be accomplished with a new priv-value, history, added
   to the Privacy header [RFC3323].  The details as to the use of the
   new priv-value with the Privacy header are provided in section
   Section 4.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 1:01 AM
To: Audet, Francois (SC100:3055); [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

BR, Roland 

-----Ursprüngliche Nachricht-----
Von: Francois Audet [mailto:[email-masked]]
Gesendet: Dienstag, 16. Juni 2009 19:22
An: Jesske, Roland; [email-masked]; [email-masked]; Mary Barnes; [email-masked]
Cc: [email-masked]
Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

In the new draft, the entries are always there and never removed. It makes HI much more reliable.

> [email-masked]; [email-masked]; Barnes, Mary 
> (RICH2:AR00); [email-masked]
> Cc: [email-masked]
> Perhaps some of the networks needs the history only to indicate where 
> the URI were mapped ("mp") and others would really track the whole 
> history of each SIP proxy.
> <sip:[email-masked];user=phone>;index=1.1;mp;aor <- aor is 
> added

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 17 Jun 2009 10:51:46 -0500

This is no different than Via headers.

If the network decides to "remove" headers, then it's free to do it.
The consequences however are worst for History-Info than for Via because
then you can break services. This was even described in "old" 4244.

> Sent: Tuesday, June 16, 2009 23:01
> I have slide concerns with that approach. Some network 
> operators does not like to present all the way of messages.
> Even if the entry is anonymous the amount of entries will 
> show the network structure which could also raise security concerns.
> 
> BR, Roland 
> 
> indicate where 
> is known to 
> H-I with 
> UAC), and 
> it would be

---

From: <[email-masked]>
Date: Thu, 18 Jun 2009 12:15:39 +0200

OK agreed,
Thanks for clarification. 

Roland

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]] 
Gesendet: Mittwoch, 17. Juni 2009 17:10
An: Jesske, Roland; Francois Audet; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

Roland,

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 1:01 AM
To: Audet, Francois (SC100:3055); [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

BR, Roland

---

From: <[email-masked]>
Date: Thu, 18 Jun 2009 12:46:33 +0200

Mary,
Question is how to distinguish.
>From my understanding the Reason will only be included if a Service is based upon a received Response. E.g Call Forwarding on Busy. So If you would like to reach  a UA and the UA is busy and send back a 486 then a SIP AS would forward the call to an other UA so within the history INFO the Reason 486 will be included.
But if you forward based on provisioning within the AS then you will not include a Reason but you can include a cause param with a value 302.
Or you can forward the call based on a Response 302 (after 180 Ringing) and add a cause 487 Parameter for Call deflection during alerting.

So the REASON shows the SIP network response and the cause shows the service behaviour of a specific application (in RFC 4458 the only service putting a cause param into History is Call Diversion).

So I see such cause param more under service apsects like a Free phone call.

BR

Roland

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]] 
Gesendet: Mittwoch, 17. Juni 2009 17:06
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; Francois Audet; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Roland,

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 1:35 AM
To: [email-masked]; [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); [email-masked]
Subject: AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Dienstag, 16. Juni 2009 12:31
An: [email-masked]; Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: <[email-masked]>
Date: Thu, 18 Jun 2009 15:07:39 +0200

Roland, Mary,

According to rfc4244bis the History-Info header "is added to a Request when a new request is created by a UAC or forwarded by a Proxy, or when the target of a request is changed". I believe a couple of minor modifications would be required in 4.3.3.1.2. to enable adding a Reason parameter in case a Request is retargeted or is just forwarded (target unchanged) for a reason other than receipt of a SIP response.

Clause 4.3.3.1.2 already includes the following text: "For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted."

So it seems that Reason is not only associated to SIP Responses. However it is unclear to me how the Reason parameter is valued in case of internal events, especially the "protocol" field? A clarification would help. Then we can think about extending the Reason header with new values associated to internal events representing either standard or non-standard services.

Furthermore, if the Reason header can indeed be used for cases other than receipt of a SIP response, I believe we should add "or when a request is forwarded by a proxy" immediately after "internal events," and remove "that has been retargeted" at the end of the sentence. This would take care of the case where the Request is just forwarded.

BC

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 18 juin 2009 12:47
À : [email-masked]; [email-masked]; CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Objet : AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Mary,

BR

Roland

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Mittwoch, 17. Juni 2009 17:06
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; Francois Audet; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Roland,

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 17, 2009 1:35 AM
To: [email-masked]; [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); [email-masked]
Subject: AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Dienstag, 16. Juni 2009 12:31
An: [email-masked]; Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 18 Jun 2009 16:24:57 +0100

> Sent: 16 June 2009 21:54
> >> Alias has the connotation that it is just a substitute for 
> the "real"
> > name.
> > 
[JRE] Can somebody explain again the circumstances in which we would use
"synonym" or "alias". I thought there was some mention in the context of
operations like resolving a call center URI to a specific user URI. In
such cases I don't think either "synonym" or "alias" is an intuitive
term. The call center URI and the resolved-to user URI identify
different objects.

John

> >>> is
> >>> update

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 18 Jun 2009 11:48:28 -0500

Roland,

For some of the services you have in mind, the new tags being added to the hi-entries should facilitate those services, in particular in a pure SIP model.  Also, consider that you can add multiple reason headers. 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 18, 2009 5:47 AM
To: Barnes, Mary (RICH2:AR00); [email-masked]; [email-masked]; [email-masked]; Audet, Francois (SC100:3055); [email-masked]
Subject: AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Mary,

BR

Roland

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Mittwoch, 17. Juni 2009 17:06
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; Francois Audet; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Roland,

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 17, 2009 1:35 AM
To: [email-masked]; [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); [email-masked]
Subject: AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Dienstag, 16. Juni 2009 12:31
An: [email-masked]; Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 18 Jun 2009 12:05:30 -0500

Bruno,

We can look at this once we get the next version of the document out - I think the changes you suggest are okay. However, per my response to Roland, I'm not certain you'll need to add more Reasons (causes) with the new tags - you should be able to derive some of the information that would give you the equivalent of a cause. Your application could convert that to a cause if appropriate. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 18, 2009 8:08 AM
To: [email-masked]; Barnes, Mary (RICH2:AR00); [email-masked]; [email-masked]; Audet, Francois (SC100:3055); [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Roland, Mary,

BC

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] Envoyé : jeudi 18 juin 2009 12:47 À : [email-masked]; [email-masked]; CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked] Objet : AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Mary,

BR

Roland

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Mittwoch, 17. Juni 2009 17:06
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; Francois Audet; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Roland,

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 17, 2009 1:35 AM
To: [email-masked]; [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); [email-masked]
Subject: AW: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Dienstag, 16. Juni 2009 12:31
An: [email-masked]; Jesske, Roland; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi,

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 19 Jun 2009 14:17:41 +0200

Hi John, 

>[JRE] Can somebody explain again the circumstances in which we would
use "synonym" or "alias". I thought there was some mention in the
context of operations like resolving a call center URI to a specific 
>user URI. In such cases I don't think either "synonym" or "alias" is an
intuitive term. The call center URI and the resolved-to user URI
identify different objects.

I think we have agreed not to use "alias" and "synonym" wording, in
order to avoid confusion.

Regards,

Christer