Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01

From: <[email-masked]>
Date: Thu, 3 Mar 2011 17:51:15 +0100

Hi Paul,

The purpose is to allow applications/services to be explicitely identified in the signaling path, so that others services/applications/telephony-AS can act accordingly. Either to apply a process taking into account the service interaction or on the contrary, do not execute a feature already covered by the application.   
For instance, a caller with a prepaid service calls a directory enquiries Server to ask for a restaurant phone number. The operator would suggest to connect the caller to the researched phone number EXCEPT if the caller has a prepaid service because it is not sure he has enough credit to pay for the communication. To allow this customized feature, the directory enquiries Application needs to know that the prepaid Application has been invocated. 

About your comment in case of several applications involved *simultaneously* in the call establishment, it is possible to add 1 more hi-entry for the second application Cause you want to be identified in the signaling path. 

Regards,
Marianne

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Paul Kyzivat
> Envoyé : mardi 1 mars 2011 00:16
> À : [email-masked]
> Objet : Re: [sipcore] I-DAction: 
> draft-mohali-sipcore-reason-extension-application-01
> 
> (As individual)
> 
> Marianne,
> 
> I'm still struggling to make sense of this in the form proposed.
> 
> I look at the various cause values, and all the descriptions 
> are of the form. E.g.:
> 
>        Cause value: 2
>        Reason text: Freephone
>        Description: A Freephone application has influenced 
> processing of
>        the call (e.g. by translating a dialed Free Phone number to a
>        routable directory number).
> 
> I can't figure out how to make any actionable decision based on this.
> Rather, it seems I need to make a number of leaps of faith 
> before I can decide what to do.
> 
> For instance, if I get an error, it *might* be because I 
> dialed a freephone number, and it isn't supported from my 
> calling location. (E.g. 
> maybe I'm dialing +1-800-555-1234, but I'm doing so from 
> France, and calling that number is only supported in the USA.
> 
> But getting a application reason code with cause 2 doesn't 
> really tell me that is what happened. It could be that the 
> call indeed was routed through a freephone application, and 
> it properly routed the call, and the call failed for some 
> other reason. But the cause is there because the application 
> *did* influence the call routing.
> 
> Also, these "applications" are not, AFAIK, mutually 
> exclusive. E.g. I could be using a prepaid service to make a 
> directory assistance call that costs extra $$$ that I don't 
> have credits to cover. But you can't include two cause values 
> for the same protocol. (But it is true that you
> *can* have a number of servers each put one cause into 
> *their* H-I entry.)
> 
> So *maybe* I would see that my call failed, and that there is 
> both a reason indicating a prepaid application on one H-I 
> entry, and another indicating a another H-I indicating a 
> directory service application. But what can I conclude from that?
> 
> Bottom line, I just can't make sense how this could be used 
> in a well defined and interoperable way.
> 
> 	Thanks,
> 	Paul
> 
> On 2/28/2011 9:58 AM, [email-masked] wrote:
> > Hello,
> >
> > Here is the new version of the draft.
> > Main changes are following:
> > - More details about the registration procedure for new values
> > - Clearer text in section 3.2
> > - Add of Public and Private status for registered values.
> > - Add of a range for cause values registration
> >
> > Best Regards,
> > Marianne Mohali
> >
> > -----Message d'origine-----
> > Objet : New Version Notification for
> > draft-mohali-sipcore-reason-extension-application-01
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> > 	Title           : Extending the Session Initiation Protocol
> > (SIP) Reason Header for Applications
> > 	Author(s)       : M. Mohali, B. Chatras
> > 	Filename        :
> > draft-mohali-sipcore-reason-extension-application-01.txt
> > 	Pages           : 10
> > 	Date            : 2011-02-24
> >
> > This document defines a new protocol value "Application" for the 
> > Reason Header field and a new IANA Registry for registering 
> > application types.  This new value enables signaling that a 
> request or 
> > response has been issued as a result of a decision made by a 
> > particular type of application or that an initial request has been 
> > retargeted as a result of an application decision.
> >
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extens
> > io
> > n-application-01.txt
> >
> > 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.
> >
> > 
> <ftp://ftp.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extens
> > io
> > n-application-01.txt>
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > _______________________________________________
> > sipcore mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Mar 2011 12:30:34 -0500

Marianne,

> For instance, a caller with a prepaid service calls a directory enquiries Server to ask for a restaurant phone number. The operator would suggest to connect the caller to the researched phone numbe…

So once again, we are back to your wanting to use Reason not to express 
a "reason" for anything, but rather as just a hook to hang something on H-I.

(With the causes you have defined, I can't imagine it making *any* sense 
to actually use one in a Reason header in a message, because they aren't 
specific enough to be actionable.)

I am now thinking there is a large overlap between what you are trying 
to accomplish this way, and what Christer is trying to accomplish with 
draft-holmberg-sipcore-proxy-feature.

Is that true?

(Christer: What do you think?)

> About your comment in case of several applications involved *simultaneously* in the call establishment, it is possible to add 1 more hi-entry for the second application Cause you want to be identif…

Sure, you can indicate that they are "involved". But you can't infer 
anything about which one "caused" something. They might have, but you 
can't tell it from the presence of these headers.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 3 Mar 2011 18:33:38 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 03 March 2011 16:51
> To: [email-masked]; [email-masked]
> Subject: Re: [sipcore] I-DAction: 
> The purpose is to allow applications/services to be 
> explicitely identified in the signaling path, so that others 
> services/applications/telephony-AS can act accordingly. 
> Either to apply a process taking into account the service 
> interaction or on the contrary, do not execute a feature 
> already covered by the application.   
> For instance, a caller with a prepaid service calls a 
> directory enquiries Server to ask for a restaurant phone 
> number. The operator would suggest to connect the caller to 
> the researched phone number EXCEPT if the caller has a 
> prepaid service because it is not sure he has enough credit 
> to pay for the communication. To allow this customized 
> feature, the directory enquiries Application needs to know 
> that the prepaid Application has been invocated. 
[JRE] This introduces completely new considerations for the security properties of History-Info. Hi-entries are expected to be informational - the application can make use of them on trust. For many purposes (e.g., displaying to Bob the fact that the call was originally targeted at Alice and forwarded) the security properties are sufficient. For making accounting decisions I rather doubt they are sufficient. For a start, the SIP entity doing the prepaid service might not support History-Info and/or the proposed Reason header field extension, and therefore a downstream entity will not know that a prepaid service has been used. Or an intermediate entity could remove the hi-entry or the Reason header field, for privacy or malicious reasons. In fact it sounds like the proposal is in violation of RFC5897, unless used within closed environments.

If the authors wish to use History-Info in this sort of way, I would suggest they review RFC5897 and the RFC4244bis security considerations very carefully.

John

> 
> About your comment in case of several applications involved 
> *simultaneously* in the call establishment, it is possible to 
> add 1 more hi-entry for the second application Cause you want 
> to be identified in the signaling path. 
> 
> Regards,
> Marianne
>  
>

---

From: <[email-masked]>
Date: Fri, 4 Mar 2011 17:59:50 +0100

Hi Paul,

My answer below [MM] 

Marianne
> De : Paul Kyzivat [mailto:[email-masked]] 
> Envoyé : jeudi 3 mars 2011 18:31
> À : MOHALI Marianne RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> So once again, we are back to your wanting to use Reason not 
> to express a "reason" for anything, but rather as just a hook 
> to hang something on H-I.
[MM] The *reason* why the call has been retargeted/rejected/modified is the invocation of a specific application. If you call a Service number and then the URI is changed for routing to the real destination, the *reason* of the URI modification (listed in H-I) is the application.
> 
> (With the causes you have defined, I can't imagine it making 
> *any* sense to actually use one in a Reason header in a 
> message, because they aren't specific enough to be actionable.)
> 
> I am now thinking there is a large overlap between what you 
> are trying to accomplish this way, and what Christer is 
> trying to accomplish with draft-holmberg-sipcore-proxy-feature.
> 
> Is that true?
> 
[MM] I don't see the overlap with Christer's draft because it is not about capabilities, it is about what's happened.
> Sure, you can indicate that they are "involved". But you 
> can't infer anything about which one "caused" something. They 
> might have, but you can't tell it from the presence of these headers.
> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> > Marianne
> >
> >
> >> [mailto:[email-masked]] De la part de Paul 
> Kyzivat Envoyé : 
> >> mardi 1 mars 2011 00:16 À : [email-masked] Objet : Re: [sipcore] 
> >> I-DAction:
> >> I look at the various cause values, and all the 
> descriptions are of 
> >> the form. E.g.:
> >>
> >>         Cause value: 2
> >>         Reason text: Freephone
> >> For instance, if I get an error, it *might* be because I dialed a 
> >> freephone number, and it isn't supported from my calling location. 
> >> (E.g.
> France, and 
> >> calling that number is only supported in the USA.
> >>
> >> But getting a application reason code with cause 2 doesn't really 
> >> tell me that is what happened. It could be that the call 
> indeed was 
> >> routed through a freephone application, and it properly routed the 
> >> call, and the call failed for some other reason. But the cause is 
> >> there because the application
> exclusive. E.g. I 
> >> could be using a prepaid service to make a directory 
> assistance call 
> >> that costs extra $$$ that I don't have credits to cover. But you 
> >> can't include two cause values for the same protocol. (But 
> it is true 
> >> that you
> >> So *maybe* I would see that my call failed, and that there 
> is both a 
> >> reason indicating a prepaid application on one H-I entry, 
> and another 
> >> indicating a another H-I indicating a directory service 
> application. 
> >> But what can I conclude from that?
> >>
> >> Bottom line, I just can't make sense how this could be 
> used in a well 
> >> defined and interoperable way.
> >>
> >> 	Thanks,
> >> 	Paul
> >>

---

From: <[email-masked]>
Date: Fri, 4 Mar 2011 18:33:33 +0100

Hi John, 

My answer inline [MM] 

Regards,
Marianne
> De : Elwell, John [mailto:[email-masked]] 
> Envoyé : jeudi 3 mars 2011 18:34
> À : MOHALI Marianne RD-CORE-ISS; [email-masked]; [email-masked]
> Objet : RE: [sipcore] 
> I-DAction:draft-mohali-sipcore-reason-extension-application-01
> 
>  
> 
> > The purpose is to allow applications/services to be explicitely 
> > identified in the signaling path, so that others 
> interaction 
> > or on the contrary, do not execute a feature
> > For instance, a caller with a prepaid service calls a directory 
> > enquiries Server to ask for a restaurant phone number. The operator 
> > would suggest to connect the caller to the researched phone number 
> > EXCEPT if the caller has a prepaid service because it is 
> not sure he 
> > has enough credit to pay for the communication. To allow this 
> > customized feature, the directory enquiries Application 
> needs to know 
> [JRE] This introduces completely new considerations for the 
> security properties of History-Info. Hi-entries are expected 
> to be informational - the application can make use of them on 
> trust. For many purposes (e.g., displaying to Bob the fact 
> that the call was originally targeted at Alice and forwarded) 
> the security properties are sufficient. For making accounting 
> decisions I rather doubt they are sufficient. For a start, 
> the SIP entity doing the prepaid service might not support 
> History-Info and/or the proposed Reason header field 
> extension, and therefore a downstream entity will not know 
> that a prepaid service has been used. Or an intermediate 
> entity could remove the hi-entry or the Reason header field, 
> for privacy or malicious reasons. In fact it sounds like the 
> proposal is in violation of RFC5897, unless used within 
> closed environments.
> 
> If the authors wish to use History-Info in this sort of way, 
> I would suggest they review RFC5897 and the RFC4244bis 
> security considerations very carefully.
> 
[MM] I agree that hi-entries are informational. The draft state that if you want to mark up an application in the signalling path, you can do it using the Reason header with a specific cause value. Obviously, it is up to the service interaction managment to ensure what are the trusted applications, networks, or operators with an interaction policy or to do it only in closed environments. That's why Public and Private values are proposed.
For 3GPP 24.604 CDIV service, the downstream entities rely on History-Info header to find the original called number for ISUP interworking. Even if hi-entries are informational. 
In your example, if the prepaid service is not identified, the 2nd application will act as usual or consider the caller untrusted and not propose the connection. 

> > *simultaneously* in the call establishment, it is possible to add 1 
> > more hi-entry for the second application Cause you want to be 
> > identified in the signaling path.
> > 
> > Regards,
> > Marianne
> >  
> > 
> Kyzivat Envoyé 
> > > : mardi 1 mars 2011 00:16 À : [email-masked] Objet : 
> Re: [sipcore] 
> > > I-DAction:
> > > Rather, it seems I need to make a number of leaps of 
> faith before I 
> > > can decide what to do.
> > > 
> exclusive. E.g. 
> > > I could be using a prepaid service to make a directory assistance 
> > > call that costs extra $$$ that I don't have credits to cover. But 
> > > you can't include two cause values for the same protocol. 
> (But it is 
> > > true that you
> > > So *maybe* I would see that my call failed, and that 
> there is both a 
> > > reason indicating a prepaid application on one H-I entry, and 
> > > another indicating a another H-I indicating a directory service 
> > > application. But what can I conclude from that?
> > > 
> > > Bottom line, I just can't make sense how this could be used in a 
> > > well defined and interoperable way.
> > > 
> > > 	Thanks,
> > > 	Paul
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Mar 2011 19:42:17 -0500

Marianne

On 3/4/2011 11:59 AM, [email-masked] wrote:
> [MM] The *reason* why the call has been retargeted/rejected/modified is the invocation of a specific application.
> If you call a Service number and then the URI is changed for routing to the real destination, the *reason* of the URI modification (listed in H-I) is the application.

Based on your other replies, this is not necessarily so.

In fact the example above is a counter-example.
The prepaid service is not responsible for any redirection, and the 
operator service is looking for it for a reason other than that it has 
been the cause of anything. Its looking for it because it might be the 
cause of something in the future.

> [MM] I don't see the overlap with Christer's draft because it is not about capabilities, it is about what's happened.

In your example above, it seems that the operator service is looking for 
the prepaid service because the prepaid service has the capability to 
influence billing, or something like that. This seems at least somewhat 
in line with what Christer is advocating. Looking in the Route header, 
or Record-Route header would make at least as much sense for this case 
as looking in H-I. H-I makes sense if you are indeed looking for 
something that has already happened, perhaps on a path other that the 
current one.

I think it would be helpful for the two of you to come to some 
reconciliation of what you are trying to accomplish.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Mar 2011 13:18:00 -0500

On 3/3/2011 11:51 AM, [email-masked] wrote:
> services/applications/telephony-AS can act accordingly. Either to
> apply a process taking into account the service interaction or on
> the contrary, do not execute a feature already covered by the
> application.
> 
> EXCEPT if the caller has a prepaid service because it is not sure he
> customized feature, the directory enquiries Application needs to
> know that the prepaid Application has been invocated.

Could we see an example of how this is expected to be done?  (Or have I
overlooked the example?)  There are various subtlties in a protocol
feature whose *absence* in the signaling tells another application that
a certain action may be taken.

Dale

---

From: <[email-masked]>
Date: Mon, 7 Mar 2011 19:29:40 +0100

Paul,

I think that Christer's draft (proxy-feature) is about capabilities while this one (reason-extension-application) is about what really happened (like reason in general). It is provided only when the event happens and the purpose is to give an accuate information for applicative events. 

Let me give you an other example:
A reception AS called with several premium rate numbers (1 per hosted application/service). The AS dispatches calls to several call centers (eg. Depending on charge, hour of the day/night...). The final destination needs to know the called service. The premuim rate number should be listed in the H-I header. Which entry? For which application/service invocated? 
As you can have a call forwarding reason associated to a 3xx or 486 Reason-cause, you could have an applicative reason to easily identify the premium rate dialed number.

Regards,
Marianne

> Envoyé : lundi 7 mars 2011 01:42
> >> De : Paul Kyzivat [mailto:[email-masked]] Envoyé : 
> jeudi 3 mars 
> >> 2011 18:31 À : MOHALI Marianne RD-CORE-ISS Cc : [email-masked]; 
> >> [email-masked] Objet : Re: [sipcore] I-DAction:
> >> or on the contrary, do not execute a feature already 
> covered by the 
> >> application.
> number. The 
> >> operator would suggest to connect the caller to the 
> researched phone 
> >> number EXCEPT if the caller has a prepaid service because 
> it is not 
> >> sure he has enough credit to pay for the communication. To 
> allow this 
> >> So once again, we are back to your wanting to use Reason not to 
> >> express a "reason" for anything, but rather as just a hook to hang 
> >> something on H-I.
> > [MM] The *reason* why the call has been 
> retargeted/rejected/modified is the invocation of a specific 
> application.
> > If you call a Service number and then the URI is changed 
> for routing to the real destination, the *reason* of the URI 
> modification (listed in H-I) is the application.
> 
> The prepaid service is not responsible for any redirection, 
> and the operator service is looking for it for a reason other 
> than that it has been the cause of anything. Its looking for 
> it because it might be the cause of something in the future.
> 
> >> *any* sense to actually use one in a Reason header in a message, 
> >> because they aren't specific enough to be actionable.)
> >>
> >> I am now thinking there is a large overlap between what you are 
> >> trying to accomplish this way, and what Christer is trying to 
> >> accomplish with draft-holmberg-sipcore-proxy-feature.
> >>
> >> Is that true?
> >>
> > [MM] I don't see the overlap with Christer's draft because 
> it is not about capabilities, it is about what's happened.
> 
> In your example above, it seems that the operator service is 
> looking for the prepaid service because the prepaid service 
> has the capability to influence billing, or something like 
> that. This seems at least somewhat in line with what Christer 
> is advocating. Looking in the Route header, or Record-Route 
> header would make at least as much sense for this case as 
> looking in H-I. H-I makes sense if you are indeed looking for 
> something that has already happened, perhaps on a path other 
> that the current one.
> 
> I think it would be helpful for the two of you to come to 
> some reconciliation of what you are trying to accomplish.
> 
> 	Thanks,
> 	Paul
> 
> can't infer 
> dialed a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Mar 2011 20:18:38 +0100

Hi,

>>>Either to apply a process taking into account the service interaction 
>>>or on the contrary, do not execute a feature already covered by the 
>>>application.
>>>directory enquiries Server to ask for a restaurant phone number. The 
>>>operator would suggest to connect the caller to the researched phone 
>>>number EXCEPT if the caller has a prepaid service because it is not 
>>>sure he has enough credit to pay for the communication. To allow this 
>>>customized feature, the directory enquiries Application needs to know 
>[MM] The *reason* why the call has been retargeted/rejected/modified is the 
>invocation of a specific application. If you call a Service number and then the 
>URI is changed for routing to the real destination, the *reason* of the URI 

Marianne is correct: proxy-feature is about entity capabilities - what they CAN do.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Mar 2011 20:24:39 +0100

Hi, 

>In your example above, it seems that the operator service is looking for the prepaid service because 
>the prepaid service has the capability to influence billing, or something like that. This seems at 
>least somewhat in line with what Christer is advocating. Looking in the Route header, or Record-Route 
>header would make at least as much sense for this case as looking in H-I. H-I makes sense if you are 
>indeed looking for something that has already happened, perhaps on a path other that the current one.

I haven't studies this specific use-case, but if it's about finding a service or capability in the network then I agree that proxy-feature is appropriate.

Without looking at it from a can-do/have-done perspective, another important thing with proxy-feature is that the entity that inserts a feature tag MUST NOT assume that other entities will understand and act upon it.

I am not claiming that Marianne's use-case is any different in that perspective, but just to keep in mind.

>I think it would be helpful for the two of you to come to some reconciliation of what you are trying to accomplish.

I am trying to indicate support of capabilities :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2011 14:59:40 -0500

On 3/7/2011 1:29 PM, [email-masked] wrote:
> A reception AS called with several premium rate numbers (1 per hosted application/service).

I'm sorry, but I'm not familiar with such services, so I don't fully 
understand this, though I can guess. Here is what I think you are saying:

There are some special URLs (premium rate numbers) that I can call.
A property of these is that when I call them my call is charged extra.
(I guess perhaps these are what we call "900" numbers in the US.)

Such calls are routed to a special server which handles this premium 
rate charging. When it receives an INVITE to a premium rate URL that it 
supports, it regargets the URL to a different one denoting the actual 
server, and then forwards the INVITE.

The ultimate server wants a way to determine whether a premium rate URL 
was used in reaching this server, and if so, which one.

And I suppose there may have been multiple translations, and so the goal 
is to identify one that was done by a premium rate server.

> The AS dispatches calls to several call centers (eg. Depending on charge, hour of the day/night...). The final destination needs to know the called service.

> The premuim rate number should be listed in the H-I header. Which entry? For which application/service invocated?

So you want to have an indication that the cause of the retargeting was 
"premium rate", or "premium rate server" or "premium rate service".

But frankly it doesn't sound like that is the reason for the 
retargeting. The reason for retargeting is that the address given 
terminated on something that delegates the actual work. It could as well 
have been a registrar, to which the actual services register.

ISTM that the URL has the property that calling it costs extra, or else 
its the behavior of the AS that it first landed on that charges a 
premium rate. Isn't it equally possible that the AS could have provided 
the service directly rather than retargeting.

If the AS actually does the billing, and needs to be in the route to do 
so, then Christer's proposal might make sense.

If its the ultimate recipient that does the billing, and does so based 
on the particular URL used to reach it, then its perhaps just the 
presence of that URL along the path that matters, and maybe even if the 
call was redirected.

If the URL called determines the service delivered and the price, why 
does it matter whether the retargetting was via a premium rate service 
or not? Wouldn't the server just look through the H-I at all the 
retargetings until it got to one that identifies a service it supports? 
If so, it wouldn't need a cause code at all.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 9 Mar 2011 18:32:15 +0100

> Envoyé : lundi 7 mars 2011 21:00
> > I think that Christer's draft (proxy-feature) is about 
> capabilities while this one (reason-extension-application) is 
> about what really happened (like reason in general). It is 
> provided only when the event happens and the purpose is to 
> give an accuate information for applicative events.
> >
> I'm sorry, but I'm not familiar with such services, so I 
> don't fully understand this, though I can guess. Here is what 
> I think you are saying:
> 

[MM] Not only this type of numbers but also "800" or other *welcome* numbers. The routing, the provided service are not linked to the charging. They can be extra charged, normally charged or free of charge. Changing is not the subject.
> 
> Such calls are routed to a special server which handles this 
> premium rate charging. When it receives an INVITE to a 
> premium rate URL that it supports, it regargets the URL to a 
> different one denoting the actual server, and then forwards 
> the INVITE.
> 
> The ultimate server wants a way to determine whether a 
> premium rate URL was used in reaching this server, and if so, 
> which one.
> 
> And I suppose there may have been multiple translations, and 
> so the goal is to identify one that was done by a premium rate server.

[MM] Exact! The goal is to identify the provided service.
> 
> > The AS dispatches calls to several call centers (eg. 
> Depending on charge, hour of the day/night...). The final 
> destination needs to know the called service.
> 
> > The premuim rate number should be listed in the H-I header. 
> Which entry? For which application/service invocated?
> > As you can have a call forwarding reason associated to a 
> 3xx or 486 Reason-cause, you could have an applicative reason 
> to easily identify the premium rate dialed number.
> 
> So you want to have an indication that the cause of the 
> retargeting was "premium rate", or "premium rate server" or 
> "premium rate service".
> 
> retargeting. The reason for retargeting is that the address 
> given terminated on something that delegates the actual work. 
> It could as well have been a registrar, to which the actual 
> services register.
> 
> ISTM that the URL has the property that calling it costs 
> extra, or else its the behavior of the AS that it first 
> landed on that charges a premium rate. Isn't it equally 
> possible that the AS could have provided the service directly 
> rather than retargeting.
> 
[MM] It is the reason why the call has been routed to this URL and what is happened.
Let me give you an other example: 
A call center provides hot line / help desk services on behalf of several enterprises (utility companies, mail order catalogue retailers, customer support for various products...). Call center agents can reply to calls destined to several enterprises. Customers of these enterprises call an 800 number that is specific to the enterprise. The 800 number is re-targeted by a SIP Application Server to the workstation of a call center agent whose location may depend on criteria such as the caller's location, the time of day... The call center agent needs to know the original number dialed by the customer so as to provide enterprise specific welcome messages and answers.

> If the AS actually does the billing, and needs to be in the 
> route to do so, then Christer's proposal might make sense.
> 
> If its the ultimate recipient that does the billing, and does 
> so based on the particular URL used to reach it, then its 
> perhaps just the presence of that URL along the path that 
> matters, and maybe even if the call was redirected.
> 
> If the URL called determines the service delivered and the 
> price, why does it matter whether the retargetting was via a 
> premium rate service or not? Wouldn't the server just look 
> through the H-I at all the retargetings until it got to one 
> that identifies a service it supports? 
> lundi 7 mars 
> >> 2011 01:42 À : MOHALI Marianne RD-CORE-ISS Cc : [email-masked]; 
> >> operator service is looking for it for a reason other than that it 
> >> has been the cause of anything. Its looking for it because 
> it might 
> >> be the cause of something in the future.
> >>
> >> In your example above, it seems that the operator service 
> is looking 
> >> for the prepaid service because the prepaid service has the 
> >> capability to influence billing, or something like that. 
> This seems 
> >> at least somewhat in line with what Christer is 
> advocating. Looking 
> >> in the Route header, or Record-Route header would make at least as 
> >> much sense for this case as looking in H-I. H-I makes sense if you 
> >> are indeed looking for something that has already 
> happened, perhaps 
> >> on a path other that the current one.
> >>

---

From: <[email-masked]>
Date: Wed, 9 Mar 2011 18:40:18 +0100

Hi Dale,

My answer below [MM]

Marianne 

> De : Worley, Dale R (Dale) [mailto:[email-masked]] 
> Envoyé : lundi 7 mars 2011 19:18
> À : Paul Kyzivat; MOHALI Marianne RD-CORE-ISS
> > apply a process taking into account the service interaction 
> or on the 
> > contrary, do not execute a feature already covered by the 
> application.
> > 
> Could we see an example of how this is expected to be done?  
> (Or have I overlooked the example?)  There are various 
> subtlties in a protocol feature whose *absence* in the 
> signaling tells another application that a certain action may 
> be taken.
[MM] In my network, I have an agreement with the Prepaid application that is to identify itself in the signaling (in the H-I header) when applied.
So that, I can offer to all of my clients a customized service with a connection to the reseached phone number except for prepaid callers.
Callers from other networks will not be able to enjoy the customized service (with the connection) as they are considered as untrusted.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 9 Mar 2011 13:31:42 -0500

________________________________________
From: [email-masked] [[email-masked]]

[MM] In my network, I have an agreement with the Prepaid application that is to identify itself in the signaling (in the H-I header) when applied.
So that, I can offer to all of my clients a customized service with a connection to the reseached phone number except for prepaid callers.
Callers from other networks will not be able to enjoy the customized service (with the connection) as they are considered as untrusted.
_______________________________________

I was thinking of a call flow, showing the critical header fields, the various proxies involved, etc.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Mar 2011 17:01:07 +0100

I have already commented that this sort of usage of H-I is appropriate only for closed networks.

In addition to that, what I seem to be hearing is that the UAS needs to look at H-I to determine how the request arrived, and in particular whether it arrived because of retargeting due to premium rate (for example). Am I correct so far?

The whole concept behind 4244bis is that the UAS, in order to discover how a request arrived, scans back through the hi-entries looking at the parameters. So far we have two such parameters: "rc" and "mp". Marianne seems to be asserting that these two parameters are insufficient, and that other information in the hi-entries needs to be viewed in order to determine that retargeting due to premium rate (for example) took place. However, the proposed solution is to add this in the "headers" component of the URI concerned, rather than add a new hi-entry parameter. So the UAS, in order to analyse the history of the request, now has to scan for both hi-entry parameters AND URI headers. I don't understand why hi-entry parameters are not proposed for such applications. Having said that, we had a longgggg discussion trying to hammer out the set of hi-entry parameters that we really needed, and the final consensus was just to have "rc" and "mp". I would not want to open up that discussion again, but on the other hand using a  different mechanism for solving a similar problem seems inappropriate.

John

> Sent: 07 March 2011 18:30
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> A reception AS called with several premium rate numbers (1 
> per hosted application/service). The AS dispatches calls to 
> several call centers (eg. Depending on charge, hour of the 
> day/night...). The final destination needs to know the called 
> service. The premuim rate number should be listed in the H-I 
> header. Which entry? For which application/service invocated? 
> As you can have a call forwarding reason associated to a 3xx 
> or 486 Reason-cause, you could have an applicative reason to 
> easily identify the premium rate dialed number.
> 
> Regards,
> Marianne
> 
>

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 17:30:43 +0100

Hi Dale,

Here is a simple call flow to illustrate the example mentioned in my email (you can see 2 more examples in the I-D with Reason header inside History-Info header or NOT):

Alice calls a Toll Free Directory service to retreive a restaurant phone number in Prague. 
She is calling from a public phone using her Prepaid card.

     Alice      Prepaid service  Toll Free Directory    Restaurant
       |                |                 |                 |
       |    INVITE F1   |                 |                 |
       |--------------->|   INVITE F2     |                 |
       |                |---------------->|                 |
       |                |                 |    INVITE F3    |
       |                |                 |---------------->|  

F1: INVITE Alice -> Prepaid

INVITE sip:[email-masked];user=phone SIP/2.0
From: Alice <sip:[email-masked]>; tag=1234567
To: Prepaid service <sip:[email-masked]>
Supported: histinfo
...

F2: INVITE Prepaid -> Toll Free Directory

INVITE sip:[email-masked] SIP/2.0
From: Alice <sip:[email-masked]>; tag=1234567
To: sip:[email-masked];user=phone
Supported: histinfo
History-Info: <sip:[email-masked];user=phone?Reason=application
              %3Bcause%3D9%3B text%3D "Prepaid">;index=1
              <sip:[email-masked]>;index=1.1;mp=1
...
 
F3: INVITE Toll Free Directory -> Restaurant

INVITE sip:[email-masked] SIP/2.0
From: Alice <sip:[email-masked]>; tag=1234567
To: sip:[email-masked];user=phone
Supported: histinfo
History-Info: <sip:[email-masked];user=phone?Reason=application
              %3Bcause%3D9%3B text%3D "Prepaid">;index=1,
              <sip:[email-masked]?Reason=application
              %3Bcause%3D11%3B text%3D "Toll Free">;index=1.1;mp=1,
		  <sip:[email-masked]>index=1.1.1
...

Regards,
Marianne

> Envoyé : mercredi 9 mars 2011 19:32
> À : MOHALI Marianne RD-CORE-ISS; [email-masked]
> subtlties in a 
> > protocol feature whose *absence* in the signaling tells another 
> > application that a certain action may be taken.
> 
> [MM] In my network, I have an agreement with the Prepaid 
> application that is to identify itself in the signaling (in 
> the H-I header) when applied.
> So that, I can offer to all of my clients a customized 
> service with a connection to the reseached phone number 
> except for prepaid callers.
> Callers from other networks will not be able to enjoy the 
> customized service (with the connection) as they are 
> considered as untrusted.
> I was thinking of a call flow, showing the critical header 
> fields, the various proxies involved, etc.
> 
> Dale
>

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 17:40:10 +0100

Oups, to following my example, 
F3 flow should be a 200 OK (to Alice)
And F4 would be a BYE from the Toll Free Directory to Alice (Alice is a prepaid card caller so it would not be proposed a connection to the Restaurant).  

Sorry

> [mailto:[email-masked]] De la part de 
> Envoyé : jeudi 17 mars 2011 17:31
> À : [email-masked]; [email-masked]
> Objet : Re: 
> [sipcore]I-DAction:draft-mohali-sipcore-reason-extension-appli
> cation-01
> 
> 
> Hi Dale,
> 
> Here is a simple call flow to illustrate the example 
> mentioned in my email (you can see 2 more examples in the I-D 
> with Reason header inside History-Info header or NOT):
> 
> History-Info: 
> <sip:[email-masked];user=phone?Reason=application
> History-Info: 
> <sip:[email-masked];user=phone?Reason=application
> > De : Worley, Dale R (Dale) [mailto:[email-masked]] Envoyé : 
> > mercredi 9 mars 2011 19:32 À : MOHALI Marianne RD-CORE-ISS; 
> > [email-masked] Cc : [email-masked]; 
> > [email-masked] Objet : RE: [sipcore]
> application 
> > that is to identify itself in the signaling (in the H-I 
> header) when 
> > applied.
> service with a 
> > connection to the reseached phone number except for prepaid callers.
> customized 
> > service (with the connection) as they are considered as untrusted.

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 22:16:34 +0100

Hi John, 

> Envoyé : jeudi 10 mars 2011 17:01
[MM] Correct.  The draft extends the Reason header not only for H-I case, but also for *normal* use of Reason header field. 
> 
> In addition to that, what I seem to be hearing is that the 
> UAS needs to look at H-I to determine how the request 
> arrived, and in particular whether it arrived because of 
> retargeting due to premium rate (for example). Am I correct so far?
[MM] The UAS should be itself a service using this information. It is not considered as a need for the UAS, but as an enhanced feature for the service and the customers. 
> 
> The whole concept behind 4244bis is that the UAS, in order to 
> discover how a request arrived, scans back through the 
> hi-entries looking at the parameters. So far we have two such 
> parameters: "rc" and "mp". Marianne seems to be asserting 
> that these two parameters are insufficient, and that other 
> information in the hi-entries needs to be viewed in order to 
> determine that retargeting due to premium rate (for example) 
> took place. However, the proposed solution is to add this in 
> the "headers" component of the URI concerned, rather than add 
> a new hi-entry parameter. So the UAS, in order to analyse the 
> history of the request, now has to scan for both hi-entry 
> parameters AND URI headers. I don't understand why hi-entry 
> parameters are not proposed for such applications. Having 
> said that, we had a longgggg discussion trying to hammer out 
> the set of hi-entry parameters that we really needed, and the 
> final consensus was just to have "rc" and "mp". I would not 
> want to open up that discussion again, but on the other hand 
> using a  different mechanism for solving a similar problem 
> seems inappropriate.
[MM] UAS already has to scan URI headers to apply Privacy or to find the call forwarding reason (according to 3GPP 24.604).
"rc" and "mp" could be usefull but are not sufficient for enhanced supplementary services needs. I expressed the need for applications when discussion started for "rc" and "mp"... 
About having a H-I parameter, I'm not against it. The cons is that it may not be possible to have this application-specific reason for SIP responses and other SIP methods where Reason header field can be used.

Marianne  
> > I think that Christer's draft (proxy-feature) is about capabilities 
> > while this one (reason-extension-application) is about what really 
> > happened (like reason in general). It is provided only when 
> the event 
> > happens and the purpose is to give an accuate information for 
> > applicative events.
> > 
> per hosted 
> > application/service). The AS dispatches calls to several 
> call centers 
> > (eg. Depending on charge, hour of the day/night...). The final 
> > destination needs to know the called service. The premuim 
> rate number 
> > should be listed in the H-I header. Which entry? For which 
> > application/service invocated?
> > As you can have a call forwarding reason associated to a 3xx or 486 
> > Reason-cause, you could have an applicative reason to 
> easily identify 
> > > has been the cause of anything. Its looking for it 
> because it might 
> > > >>>> On 2/28/2011 9:58 AM, 
> [email-masked] wrote:
> > > >>>>> Hello,
> > > >>>>>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Mar 2011 08:33:45 +0100

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 17 March 2011 21:17
> To: Elwell, John; [email-masked]
> Subject: RE: [sipcore]
> [MM] Correct.  The draft extends the Reason header not only
> for H-I case, but also for *normal* use of Reason header field.
> >
> [MM] The UAS should be itself a service using this
> information. It is not considered as a need for the UAS, but
> as an enhanced feature for the service and the customers.
> >
> [MM] UAS already has to scan URI headers to apply Privacy or
> to find the call forwarding reason (according to 3GPP 24.604).
> "rc" and "mp" could be usefull but are not sufficient for
> enhanced supplementary services needs. I expressed the need
> for applications when discussion started for "rc" and "mp"...
> About having a H-I parameter, I'm not against it. The cons is
> that it may not be possible to have this application-specific
> reason for SIP responses and other SIP methods where Reason
> header field can be used.
[JRE] This does not fully address the point I was making. I was making the point that to find the particular hi-entry you are interested in you need, at present, to scan hi-entries looking at their parameters - you do not need to look at the URIs in those hi-entries and the URIs' "headers" components in order to find the hi-entry you are looking for. Of course, once you have found the hi-entry you are looking for, you will be interested in the URI and in anything attached to it, including Privacy and Reason header fields within its "headers" component. The draft under discussion seems to change that principle so that in order to find the hi-entry you are looking for you need to look inside the URIs. This seems to me like a change of principle - the logic of including the proposed application information in the URI as a header field, rather than in hi-entry parameters, is not at all clear to me.

John

> capabilities
> 3xx or 486
> > > > >> On 3/3/2011 11:51 AM,

---

From: <[email-masked]>
Date: Fri, 18 Mar 2011 10:29:35 +0100

> Envoyé : vendredi 18 mars 2011 08:34
> > > À : MOHALI Marianne RD-CORE-ISS; [email-masked] Cc : 
> > > [email-masked]; [email-masked] Objet : RE: 
> > > [sipcore]
> > [MM] Correct.  The draft extends the Reason header not only for H-I 
> > case, but also for *normal* use of Reason header field.
> > >
> > > In addition to that, what I seem to be hearing is that 
> the UAS needs 
> > > to look at H-I to determine how the request arrived, and in 
> > > particular whether it arrived because of retargeting due 
> to premium 
> > > rate (for example). Am I correct so far?
> information. It is 
> > not considered as a need for the UAS, but as an enhanced 
> feature for 
> > the service and the customers.
> > >
> > > discover how a request arrived, scans back through the hi-entries 
> > > looking at the parameters. So far we have two such
> that these 
> > > two parameters are insufficient, and that other 
> information in the 
> > > hi-entries needs to be viewed in order to determine that 
> retargeting 
> > > due to premium rate (for example) took place. However, 
> the proposed 
> > > solution is to add this in the "headers" component of the URI 
> > > concerned, rather than add a new hi-entry parameter. So 
> the UAS, in 
> > > order to analyse the history of the request, now has to scan for 
> > > both hi-entry parameters AND URI headers. I don't understand why 
> > > hi-entry parameters are not proposed for such 
> applications. Having 
> > > said that, we had a longgggg discussion trying to hammer 
> out the set 
> > > of hi-entry parameters that we really needed, and the final 
> > > consensus was just to have "rc" and "mp". I would not 
> want to open 
> > > up that discussion again, but on the other hand using a  
> different 
> > > mechanism for solving a similar problem seems inappropriate.
> > [MM] UAS already has to scan URI headers to apply Privacy 
> or to find 
> > the call forwarding reason (according to 3GPP 24.604).
> > "rc" and "mp" could be usefull but are not sufficient for enhanced 
> > supplementary services needs. I expressed the need for applications 
> > when discussion started for "rc" and "mp"...
> > About having a H-I parameter, I'm not against it. The cons 
> is that it 
> > may not be possible to have this application-specific 
> reason for SIP 
> > responses and other SIP methods where Reason header field 
> can be used.
> [JRE] This does not fully address the point I was making. I 
> was making the point that to find the particular hi-entry you 
> are interested in you need, at present, to scan hi-entries 
> looking at their parameters - you do not need to look at the 
> URIs in those hi-entries and the URIs' "headers" components 
> in order to find the hi-entry you are looking for. Of course, 
> once you have found the hi-entry you are looking for, you 
> will be interested in the URI and in anything attached to it, 
> including Privacy and Reason header fields within its 
> "headers" component. The draft under discussion seems to 
> change that principle so that in order to find the hi-entry 
> you are looking for you need to look inside the URIs. This 
> seems to me like a change of principle - the logic of 
> including the proposed application information in the URI as 
> a header field, rather than in hi-entry parameters, is not at 
> all clear to me.
[MM] I don't see the problem with your point. hi-entry parameters 
are not incompatible with URIs' headers.
hi-entry parameters, allow to do a first sort in hi-entries, then, 
according to UAS needs, URI headers or parameters give a complementary
 information.  
Imagine a situation where you have Alice calling Bob with a prepaid 
calling card and Bod doesn't answer so the call is retargeted to the 
voicemail.
You would have the following sequence in the last INVITE (last leg): 
I didn't show possible intermediary proxies entries)
History-Info:
	<sip:[email-masked];user=phone?Reason=application
      ;cause=9;text="Prepaid">;index=1,
      <sip:[email-masked];user=phone?Privacy=history>;index=1.1;mp=1,
      <sip:[email-masked];user=phone;cause=408>index=1.1.1;mp=1.1

Marianne
> > > > > On 3/4/2011 11:59 AM, 
> > > > > >>>> -----Message d'origine----- De : 
> [email-masked] 
> > > > > >>>>          the call (e.g. by translating a dialed 
> Free Phone
> > > > > >> number to a
> > > > > >>>>> -----Message d'origine----- Objet : New Version 
> > > > > >>>>> Notification for
> > > > > >>>>> particular type of application or that an 
> initial request
> > > > > >> has been

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Mar 2011 11:51:40 +0100

</snip>
> <sip:[email-masked];user=phone;cause=408>index=1.1.1;mp=1.1

[JRE] So in this particular case, the application might search for the earliest entry marked mp, which points to the hi-entry with index 1, and that contains the Prepaid reason. I suppose that works (subject to my earlier caveat about needing to be in a closed network to rely on that information). However, the fact that it works in this particular scenario does not necessarily mean it is the correct mechanism, and I would like to hear other opinions.

John

> > > > > > >> *simultaneously* in the call establishment, it
> is possible
> > > > > > to add 1
> > > > > > >>>> mardi 1 mars 2011 00:16 À : [email-masked]
> Objet : Re:
> > > > > > [sipcore]
> > > > > > >>>> I-DAction:
> > > > > > >>>> freephone number, and it isn't supported from
> my calling
> > > > > > location.
> > > > > > >>>> (E.g.
> > > > > > >>>> call, and the call failed for some other
> reason. But the
> > > > > > cause is

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Mar 2011 08:43:32 -0400

>        <sip:[email-masked];user=phone;cause=408>index=1.1.1;mp=1.1

Where is Alice in this? Shouldn't Alice be index=1?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Mar 2011 08:50:50 -0400

[as individual]

IMO the question John asks is pertinent to almost *any* piece of 
information you might want to derive from H-I. I have the feeling that 
generally the algorithm you might come up with will be highly dependent 
on the individual behaviors of elements in the network, and so will be 
highly fragile, except in specific closed environments.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 18 Mar 2011 14:03:21 +0100

> Envoyé : vendredi 18 mars 2011 13:44
> Cc : [email-masked]; [email-masked]; 
> [email-masked]
> Objet : Re: [sipcore] 
[MM] Alice is in the From header field. No?

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Mar 2011 09:25:22 -0400

At end...

> [MM] Alice is in the From header field. No?

Well, presumably.

But IIUC, either Alice should make the first H-I entry for herself, or 
the first element that supports H-I should do so on her behalf.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 18 Mar 2011 14:50:21 +0100

My answer below 

> Envoyé : vendredi 18 mars 2011 14:25
> >> De : Paul Kyzivat [mailto:[email-masked]] Envoyé : vendredi 18 
> >> mars 2011 13:44 À : MOHALI Marianne RD-CORE-ISS Cc : 
> >> [email-masked]; [email-masked]; 
> >> [email-masked] Objet : Re: [sipcore]
[MM] Not in my understanding. According to 4244bis and the call flow draft, the originating UA should insert a "supported: histinfo" but no H-I header.
It would be the first retageting entity that insert a H-I header with 2 hi-entries : a 1st for itself and a 2nd for the new target (old and new values of the R-URI). After that, each retageting/proxying entity should add a hi-entry with the new target and complete its own hi-entry if necessary.
No?

Marianne

---

From: Mary Barnes <[email-masked]>
Date: Fri, 18 Mar 2011 09:35:44 -0500

Marianne,

The intent is for the originating UAC to add the hi-entry, although maybe we
should fix figure one to emphasize that. The functionality in both RFC4244
and rfc4244bis is that anytime an entity that supports HI receives an
incoming request that doesn't have an hi-entry for the Request-URI in the
incoming request, the entity adds the hi-entry on behalf of the previous
entity (and then adds one for the Request-URI in the outgoing request that
it generates).   The situation can occur not just in the case of the UAC
sending the request without an hi-entry - it can occur in cases where there
might be an intermediary that doesn't support History-info.

The supported:histinfo is used by the UAC to indicate that it wants to
receive the hi-entries in the response.

Mary.

On Fri, Mar 18, 2011 at 8:50 AM, <[email-masked]> wrote:

> [MM] Not in my understanding. According to 4244bis and the call flow draft,
> the originating UA should insert a "supported: histinfo" but no H-I header.
> It would be the first retageting entity that insert a H-I header with 2
> hi-entries : a 1st for itself and a 2nd for the new target (old and new
> values of the R-URI). After that, each retageting/proxying entity should add
> a hi-entry with the new target and complete its own hi-entry if necessary.
> No?
>
> Marianne
> >
> >       Thanks,
> >       Paul
> >

---

From: <[email-masked]>
Date: Fri, 18 Mar 2011 16:45:08 +0100

Mary,
 
I think that you missed my point: Even if UAC adds a hi-entry, it should be with the URI contained in the Request-URI (as hi-targeted-to-uri captures the R-URIs) and not the URI contained in the From header. 
So, in my example, Alice's URI should not be present in the H-I. Right?
Marianne

________________________________

	De : Mary Barnes [mailto:[email-masked]] 
	Envoyé : vendredi 18 mars 2011 15:36
	À : MOHALI Marianne RD-CORE-ISS
	Cc : [email-masked]; [email-masked]; [email-masked]
	Objet : Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01

	Marianne,

	The intent is for the originating UAC to add the hi-entry, although maybe we should fix figure one to emphasize that. The functionality in both RFC4244 and rfc4244bis is that anytime an entity that supports HI receives an incoming request that doesn't have an hi-entry for the Request-URI in the incoming request, the entity adds the hi-entry on behalf of the previous entity (and then adds one for the Request-URI in the outgoing request that it generates).   The situation can occur not just in the case of the UAC sending the request without an hi-entry - it can occur in cases where there might be an intermediary that doesn't support History-info. 

	The supported:histinfo is used by the UAC to indicate that it wants to receive the hi-entries in the response. 

	Mary. 

		My answer below

		> >>>   <sip:[email-masked] <mailto:[email-masked]> ;user=phone?Reason=application
		> <sip:[email-masked] <mailto:[email-masked]> ;user=phone?Privacy=history>;index=1.1;mp=1,
		> >>>
		> >>>
		> >>
		> <sip:[email-masked] <mailto:[email-masked]> ;user=phone;cause=408>index=1.1.1;mp=1.1
		> >>

		Marianne

---

From: Mary Barnes <[email-masked]>
Date: Fri, 18 Mar 2011 11:15:46 -0500

Correct - Alice's URI would not be in the hi-entries at all.  There is an
error in your example in F2 for the first hi-entry which should contain:
sip:[email-masked]   rather than:   sip:[email-masked].

What I was suggesting was that this is the preferred way to do this
(skipping the example.com entry):

INVITE sip:[email-masked];user=phone SIP/2.0
From: Alice <sip:[email-masked]>; tag=1234567
To: Prepaid service <sip:[email-masked]>
Supported: histinfo
History-Info: <sip:[email-masked];user=phone?>;index=1,
...

             <sip:[email-masked]>;index=1.1.;mp=1
...

             <sip:[email-masked]?Reason=application<http://sip:[email-masked]/?Reason=application>

On Fri, Mar 18, 2011 at 10:45 AM, <[email-masked]>wrote:

>  Mary,
>
> I think that you missed my point: Even if UAC adds a hi-entry, it should
> be with the URI contained in the Request-URI (as hi-targeted-to-uri captures
> the R-URIs) and not the URI contained in the From header.
>  ------------------------------
> *De :* Mary Barnes [mailto:[email-masked]]
> *Envoyé :* vendredi 18 mars 2011 15:36
>
> *À :* MOHALI Marianne RD-CORE-ISS
> *Cc :* [email-masked]; [email-masked];
> *Objet :* Re: [sipcore]
> The intent is for the originating UAC to add the hi-entry, although maybe
> we should fix figure one to emphasize that. The functionality in both
> RFC4244 and rfc4244bis is that anytime an entity that supports HI receives
> an incoming request that doesn't have an hi-entry for the Request-URI in the
> On Fri, Mar 18, 2011 at 8:50 AM, <[email-masked]>wrote:
>
>> My answer below
>>
>> [MM] Not in my understanding. According to 4244bis and the call flow
>> draft, the originating UA should insert a "supported: histinfo" but no H-I
>> header.

---

From: <[email-masked]>
Date: Fri, 18 Mar 2011 17:25:26 +0100

OK !
There is also a missing "mp" (mp=1.1) in the last hi-entry in F3
Sorry, I do this example too quickly.
 
Marianne

	Envoyé : vendredi 18 mars 2011 17:16

	Correct - Alice's URI would not be in the hi-entries at all.  There is an error in your example in F2 for the first hi-entry which should contain:  sip:[email-masked] <mailto:[email-masked]>    rather than:   sip:[email-masked] <mailto:[email-masked]> .    

	What I was suggesting was that this is the preferred way to do this (skipping the example.com entry):

	INVITE sip:[email-masked] <mailto:[email-masked]> ;user=phone SIP/2.0
	From: Alice <sip:[email-masked] <mailto:[email-masked]> >; tag=1234567
	To: Prepaid service <sip:[email-masked] <mailto:[email-masked]> >
	Supported: histinfo
	History-Info: <sip:[email-masked] <mailto:[email-masked]> ;user=phone?>;index=1,
	...

	INVITE sip:[email-masked] <mailto:[email-masked]>  SIP/2.0
	From: Alice <sip:[email-masked] <mailto:[email-masked]> >; tag=1234567
	To: sip:[email-masked] <mailto:[email-masked]> ;user=phone
	Supported: histinfo
	History-Info: <sip:[email-masked] <mailto:[email-masked]> ;user=phone?Reason=application
	             %3Bcause%3D9%3B text%3D "Prepaid">;index=1 
	             <sip:[email-masked] <mailto:[email-masked]> >;index=1.1.;mp=1
	...

	INVITE sip:[email-masked] <mailto:[email-masked]>  SIP/2.0
	From: Alice <sip:[email-masked] <mailto:[email-masked]> >; tag=1234567
	To: sip:[email-masked] <mailto:[email-masked]> ;user=phone
	Supported: histinfo
	History-Info: <sip:[email-masked] <mailto:[email-masked]> ;user=phone?Reason=application
	             %3Bcause%3D9%3B text%3D "Prepaid">;index=1,
	             <sip:[email-masked]?Reason=application <http://sip:[email-masked]/?Reason=application> 
	             %3Bcause%3D11%3B text%3D "Toll Free">;index=1.1;mp=1,
	                 <sip:[email-masked] <mailto:[email-masked]> >index=1.1.1
	...

	On Fri, Mar 18, 2011 at 10:45 AM, <[email-masked]> wrote:

		Mary,
		 
		I think that you missed my point: Even if UAC adds a hi-entry, it should be with the URI contained in the Request-URI (as hi-targeted-to-uri captures the R-URIs) and not the URI contained in the >From header. 
		So, in my example, Alice's URI should not be present in the H-I. Right?
		Marianne

			

			Marianne,

			Mary. 

				My answer below

				
				Marianne

---

From: <[email-masked]>
Date: Mon, 21 Mar 2011 17:31:56 +0100

Paul,

> Envoyé : vendredi 18 mars 2011 13:51
> À : Elwell, John
> Cc : MOHALI Marianne RD-CORE-ISS; [email-masked]; 
> IMO the question John asks is pertinent to almost *any* piece 
> of information you might want to derive from H-I. I have the 
> feeling that generally the algorithm you might come up with 
> will be highly dependent on the individual behaviors of 
> elements in the network, and so will be highly fragile, 
> except in specific closed environments.

[MM] Each service interaction is a specific case and only a closed environment can ensure a end-to-end information BUT:
First, this comment is also valid for other information in the H-I (eg. Call forwarding information); 
Second, the only solution to avoid case by case solutions for having enhanced services between networks is to have a shared standard.
This example was showing a specific case but the Reason extension intend to be also used in SIP request (see eg with a BYE in the draft) or answers (eg. 4xx, 5xx..).

Marianne
> >>> [JRE] This does not fully address the point I was making. I was 
> >>> making the point that to find the particular hi-entry you are 
> >>> interested in you need, at present, to scan hi-entries looking at 
> >>> their parameters - you do not need to look at the URIs in those 
> >>> hi-entries and the URIs' "headers" components in order to 
> find the 
> >>> hi-entry you are looking for. Of course, once you have found the 
> >>> hi-entry you are looking for, you will be interested in 
> the URI and 
> >>> in anything attached to it, including Privacy and Reason header 
> >>> fields within its "headers" component. The draft under discussion 
> >>> seems to change that principle so that in order to find 
> the hi-entry 
> >>> you are looking for you need to look inside the URIs. 
> This seems to 
> >>> me like a change of principle - the logic of including 
> the proposed 
> >>> application information in the URI as a header field, 
> rather than in 
> >>> hi-entry parameters, is not at all clear to me.
> >> [MM] I don't see the problem with your point. hi-entry 
> parameters are 
> >> not incompatible with URIs' headers.
> > [JRE] So in this particular case, the application might 
> search for the earliest entry marked mp, which points to the 
> hi-entry with index 1, and that contains the Prepaid reason. 
> I suppose that works (subject to my earlier caveat about 
> needing to be in a closed network to rely on that 
> information). However, the fact that it works in this 
> particular scenario does not necessarily mean it is the 
> correct mechanism, and I would like to hear other opinions.
> >
> > John
> >
> >>
> >> Marianne
> >>>
> >>> John
> >>>
> >>>
> >>>>
> >>>> Marianne
> >>>>>
> >>>>> John
> >>>>>
> >>>>>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 24 Mar 2011 16:39:18 -0400

I'm behind on this discussion, but I think that the example has some data misplaced, in that the "Reason"
header item is attached to the URI for which it gives the reason for its creation or invocation.
So if the prepaid service is invoked by 18005555555 and turns the request into 18005551212,
the "prepaid" Reason would be on 18005551212:

INVITE sip:[email-masked] SIP/2.0
From: Alice <sip:[email-masked]>; tag=1234567
To: sip:[email-masked];user=phone
Supported: histinfo
History-Info: <sip:[email-masked];user=phone>;index=1
             <sip:[email-masked]?Reason=application
             %3Bcause%3D9%3B text%3D "Prepaid">;index=1.1.;mp=1
...

INVITE sip:[email-masked] SIP/2.0
From: Alice <sip:[email-masked]>; tag=1234567
To: sip:[email-masked];user=phone
Supported: histinfo
History-Info: <sip:[email-masked];user=phone>;index=1,
             <sip:[email-masked]?Reason=application
             %3Bcause%3D9%3B text%3D "Prepaid">;index=1.1;mp=1,
                 <sip:[email-masked]?Reason=application
             %3Bcause%3D11%3B text%3D "Toll Free">index=1.1.1

Or am I mistaken?

Dale

---

From: Shida Schubert <[email-masked]>
Date: Sat, 26 Mar 2011 10:39:16 +0100

My apology for joining the conversation late. 

 We discussed few things related to this in the past. 

 To distinguish the service such as the ones described in the 
draft, I had proposed using URN schema that we can attach 
and expand to H-I when we first start discussing 4244bis and 
target draft. 
  
 Hadriel also mentioned a potential need for a parameter beside 
mp and rc that can distinguish diversion from another mapping 
(toll-free etc.) prior or during the WGLC last year. 

 Although these additional information may be nice to have, 
because of how premium or toll-free services are usually 
implemented and deployed, I believe current specification 
is sufficient as illustrated/described in the  call-flow spec 
we recently submitted. 

 I believe because these services affect billing greatly, and 
can raise potential lawsuits etc, the service will always be 
implemented/deployed in rather predictable way. Allowing 
receiving entity to easily scan the H-I to find that the call is  
a toll-free call or premium call. 

 For example, what would happen if you call a toll-free number 
and it gets forwarded to premium number? You think you are 
calling a number for free but realize later that what you thought 
was a call free has ballooned your phone bill. This doesn't 
happen in practice. 

 Regards
  Shida

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 18:55:41 +0200

Hi Shida,

First, note that the discussion will be moved to DISPATCH as recommended by Paul and Adam.

About your comments, I want to remind the 3 distinct uses we want to address:

1) To convey a list of services having "acted" on the call, in order to allow a downstream application to manage services interactions. This could be done with a separate parameter from H-I and Reason headers.

2) To convey the identity (dialled number) of the application having caused a specific number translation and allow the transfer target to find out the good application number in case of successive number translation. This can only be done in H-I (in Reason or anywhere else).

3) To convey the identity of the application having released the call, towards an upstream application that can take specific decisions. This could be done with a totally new parameter (independent from the Reason header).

Finally, to address the point Hadriel mentionned about the call forwarding identification, I've thought about registering a public cause value in this draft dedicated to "call forwarding" that can be used to identify H-I entries representing diverting users (in the sense of 3GPP 24.602).

Our though is that Reason header can address all these needs.

'mp' H-I parameter could be a macro information and the Reason a detailed information when needed.

Best Regards,
Marianne 

> De : Shida Schubert [mailto:[email-masked]] 
> Envoyé : samedi 26 mars 2011 10:39
> À : Elwell, John
> Cc : MOHALI Marianne RD-CORE-ISS; [email-masked]; 
> [email-masked]; [email-masked]
> Objet : Re: [sipcore] 
> draft, I had proposed using URN schema that we can attach and 
> expand to H-I when we first start discussing 4244bis and 
> target draft. 
>   
>  Hadriel also mentioned a potential need for a parameter 
> beside mp and rc that can distinguish diversion from another 
> mapping (toll-free etc.) prior or during the WGLC last year. 
> 
> implemented and deployed, I believe current specification is 
> sufficient as illustrated/described in the  call-flow spec we 
> recently submitted. 
> 
> receiving entity to easily scan the H-I to find that the call 
> is a toll-free call or premium call. 
> 
>  For example, what would happen if you call a toll-free 
> number and it gets forwarded to premium number? You think you 
> are calling a number for free but realize later that what you 
> thought was a call free has ballooned your phone bill. This 
> doesn't happen in practice. 
> 
>  Regards
>   Shida
> 
> >> responses and other SIP methods where Reason header field can be 
> >> used.