Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

From: <[email-masked]>
Date: Thu, 4 Dec 2014 15:43:21 +0000

Hi,

I re-send my fist email with the correct draft title as subject.

I already plan to improve the text of the draft by defining a clear definition with a new wording to describe the scope of usage of the new cause URI parameter value.

This new vocabulary could be something like "service access number translation" with a definition that will be somewhere between a retargeting while the target user remain the same and a redirection to a new target. Indeed, for premium/toll-free services users are trying to contact a service which is the target service and not a particular user behind a UA as a "target user" as defined in RFC7044. The service access number could be seen as a super-alias pointing out to a set of UAs and a UAs could be pointed out by several service access numbers.

Comments and review are still welcome.

BR,

Marianne

------

This draft defines a new value for the SIP URI parameter "cause", which can be used to associate a SIP URI to a service access number that has been translated by a specific application.

Abstract:

RFC4458 defines a "cause" URI parameter as having predefined values for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons.  The "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header defined in RFC7044 that must be added in retargeted requests. This specification creates a new predefined value for cases when the retargeting is caused by a specific service action leading to a called number translation. This document updates RFC4458.

This draft is needed for 3GPP, but we've tried to write it in a way so that it can also be applied to other environments.

A first version of the draft can be seen under:

http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service-number-00.txt

This version is a very first version and for sure needs improvement.

Your comments are welcome.

Regards,

Marianne Mohali

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Fri, 5 Dec 2014 14:05:06 +0000

Hi Jan,

It is right, I saw it after submitted the draft.
I will correct it for the next version.

Thank you,

Kind Regards,
Marianne

De : VAN GEEL Jan (SPC/CSP) [mailto:[email-masked]]
Envoyé : vendredi 5 décembre 2014 07:47
À : MOHALI Marianne IMT/OLN; [email-masked]
Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Marianne,

My only comment is an editorial one: "tool free service" should be "toll free service"

Kind regards

Jan Van Geel
IT and Network Specialist
Belgacom CIS/SCC/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]<mailto:[email-masked]>

From: dispatch [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday 4 December 2014 16:43
To: [email-masked]<mailto:[email-masked]>
Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Hi,

BR,

Marianne

------

Abstract:

Regards,

Marianne Mohali

Thank you.

________________________________

***** Disclaimer *****
http://www.proximus.be/maildisclaimer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Dec 2014 15:11:19 +0000

Hi,

I have identified some editorial nits, which I can provide later, but in general I support this draft moving forward, and I will follow the work and provide comments.

Regards,

Christer

From: dispatch [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 4. joulukuuta 2014 17:43
To: [email-masked]
Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Hi,

BR,

Marianne

------

Abstract:

Regards,

Marianne Mohali

Thank you.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 15 Dec 2014 17:12:47 -0500

This draft seems valuable to me and I think it should progress.

One nit is the use of "IN".  I believe it means "Intelligent Network" in
the Q.1200 sense, but that acronym isn't commonly used in the SIP world,
so it would help if it was explained more fully when it is first used.

Dale

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 16 Dec 2014 10:23:38 +0000

Hello Marianne, all,

I also support to move this draft forward.

Kind regards,

Uwe

From: dispatch [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Monday, December 15, 2014 4:11 PM
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Hi,

Regards,

Christer

Hi,

BR,

Marianne

------

Abstract:

Regards,

Marianne Mohali

Thank you.

---

From: <[email-masked]>
Date: Wed, 17 Dec 2014 16:39:52 +0000

Hi,

Thank you Dale for your support!

Indeed, I think IN (for Intelligent Network) is not an acronym to be used in the SIP world. I would like to define a new vocabulary to define a clear context of the usage of this new cause value. I was thinking about something like "Service access number translation" : action to replace as received alias number identifying a service by a target number to be routed downstream.
Any opinion? 

BR,
Marianne

-----Message d'origine-----
De : Dale R. Worley [mailto:[email-masked]] 
Envoyé : lundi 15 décembre 2014 23:13
À : MOHALI Marianne IMT/OLN
Cc : [email-masked]
Objet : Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

One nit is the use of "IN".  I believe it means "Intelligent Network" in the Q.1200 sense, but that acronym isn't commonly used in the SIP world, so it would help if it was explained more fully when it is first used.

Dale

---

From: Jörgen Axell <[email-masked]>
Date: Thu, 18 Dec 2014 15:42:57 +0000

Bonjour Marianne,

I believe this is a useful case and Ihave some minor comments:

Please be consistent in specifying that it is the "cause" URI parameter (or SIP URI parameter). The confusion with the "cause" in Reason headers is well-known.

Section 2: " URIs that are issued form a retargeting" from a retargeting?

Section 3: "mp" tag seems to be a pre-requisite for the "cause" SIP URI parameter. Is this always true? Can't the number translation be seen as a replacement of the dialled number without changing the target user?

In section 3 you change to cause-param and target-param instead of "cause" SIP URI...

Section 4 hte-->the

Section 5: " new value for the "cause" parameter: 480" I thought 380 ;-), 480 is deflection immediate response.

Regards,
Jörgen
From: dispatch [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 05 December 2014 15:05
To: VAN GEEL Jan (SPC/CSP); [email-masked]
Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Hi Jan,

Thank you,

Kind Regards,
Marianne

De : VAN GEEL Jan (SPC/CSP) [mailto:[email-masked]]
Envoyé : vendredi 5 décembre 2014 07:47
À : MOHALI Marianne IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Marianne,

Kind regards

Jan Van Geel

Hi,

BR,

Marianne

------

Abstract:

Regards,

Marianne Mohali

Thank you.

***** Disclaimer *****

Thank you.

---

From: <[email-masked]>
Date: Fri, 19 Dec 2014 17:22:22 +0000

Hi Jörgen,

Many thanks for your review. I already saw some of your comments (eg. 480 instead of 380) and I will take them into account in the draft update.

>Section 3: "mp" tag seems to be a pre-requisite for the "cause" SIP URI parameter. Is this always true? Can't the number translation be seen as a replacement of the dialled number without changing t…

It sounds like a pending discussion we have in sipcore and indeed (I think we agree on that) we need to have this discussion and take the opportunity to provide clear statements concerning the History-Info header usage for the use case this draft is trying to solve.
Writing the draft, I chosen not to provide a complete call-flow in the example because of this weakness in RFC7044 I wanted to discuss before.

We have 3 possible solutions, the choice we will make, will impact the hi-target-param inserted in the History-info header by entities defined by this new draft:
1) The service access number translation is considered as a replacement of the dialed number (as an alias) without changing the target user (the contacted service) => In the hi-targeted-to entry: use of the "rc" param (+new index level ".1" and cause="380")
2) The service access number translation is considered as a retargeting (new target user) => In the hi-targeted-to entry: use of the "mp" param (+new index level ".1" and cause="380")
3) Nothing is stated in the draft and both can be possible depending on the implementor's interpretation...except if 3GPP decide to make a choice between 1 and 2 afterward. ;-)

My first thought was option 1) but my first action has been to check in RFC7131 and in section 3.11 (Toll-Free Number) it is option 2) that has been retained.

>From RFC7131:
To find the service number, the UAS can extract the hi-entry whose
   index matches the value of the first hi-entry with an "mp" tag.
   Technically, the call can be forwarded to these "special" numbers
   from non-special numbers; however, that is uncommon based on the way
   these services authorize translations.

On the other hand, in the same example it is mentioned the following:
In the telephone network, toll-free numbers are just aliases to
   actual numbers that are used for routing of the call.

Regarding RFC7044, for aliases it is more "rc" to be used...
Finally, my idea is more to choose option 2) only to be consistent with the example in RFC7131.

I would like to have people thought about this point to move forward and have a clear statement in this draft to avoid any further ambiguity and implementation troubles.

Best Regards,
Marianne

De : Jörgen Axell [mailto:[email-masked]]
Envoyé : jeudi 18 décembre 2014 16:43
À : MOHALI Marianne IMT/OLN; [email-masked]
Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Bonjour Marianne,

Section 4 hte-->the

Regards,
Jörgen
From: dispatch [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 05 December 2014 15:05
To: VAN GEEL Jan (SPC/CSP); [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00

Hi Jan,

Thank you,

Kind Regards,
Marianne

Marianne,

Kind regards

Jan Van Geel

Hi,

BR,

Marianne

------

Abstract:

Regards,

Marianne Mohali

Thank you.

***** Disclaimer *****

Thank you.