Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

["Asveren, Tolga" <[e-mail]>]

Marianne,

Thanks for the reply. As I already indicated in my previous message, I am fine with that decision of yours.

Thanks,
Tolga

From: [e-mail] <[e-mail]>
Sent: Tuesday, May 22, 2018 6:36 AM
To: Asveren, Tolga <[e-mail]>; Christer Holmberg <[e-mail]>; [e-mail]
Subject: RE: WGLC: draft-ietf-sipcore-originating-cdiv-parameter

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi Tolga,

Sorry for the late feedback:
I can understand your point about considering the opportunity of this draft to introduce also symmetrical “term-cdiv” session case but there is already a solution to distinguish a term-cdiv session case by identifying the presence of the History-Info header (RFC7044) with cause uri parameters (RFC4458) that are embedded in case of diverted call.
As Paul commented, this draft is 3GPP requested and although it is an extension of SIP, it is to be considered in the IMS environment. In this context, introducing an additional session case that is not corresponding to any procedure in 3GPP specifications is a risk to confuse people.
I would really prefer to keep this use case in a separate discussion if you don’t mind.

Best regards,
Marianne

De : Asveren, Tolga [mailto:[e-mail]]
Envoyé : jeudi 29 mars 2018 13:38
À : Christer Holmberg; MOHALI Marianne IMT/OLN; [e-mail]<mailto:[e-mail]>
Objet : RE: WGLC: draft-ietf-sipcore-originating-cdiv-parameter

Although I also agree that it is preferable to keep chances limited during WGLC, this in principle shouldn’t mean that we ought to avoid what makes sense for the sake of “pushing it forward without hassle”.

As I already indicated before, I think the idea of enumerating different scenario combinations in IETF, which do not pertain to actual SIP semantics at all, is not an elegant idea IMHO. Not defining any values and expecting use of (if needed multiple) generic-params for P-Served-User could have been a cleaner approach. Actual values would be defined by other standard fora.

For a use case for term-cdiv: “Do not divert if already diverted”, “indicate in call records that call is diverted” (for example to apply a different charging scheme) could be applicable.

As a final word: I am not religious about this, it anyhow wouldn’t fix a broken model (honestly I rather would prefer that this draft is withdrawn and a new draft is submitted explaining that use cases requiring new P-Served-User parameter values should use the generic-param extension). Nonetheless, it  still sounds more reasonable to me to add it than not.

So, I will leave it here and hope the authors would think carefully/in a non-biased way and decide for the best course.

Thanks,
Tolga

From: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 28, 2018 1:43 PM
To: [e-mail]<mailto:[e-mail]>; Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: WGLC: draft-ietf-sipcore-originating-cdiv-parameter

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi,

My general opinion, not specific to this draft, is that we should avoid adding new functionality at WGLC - unless it is needed for the existing functionality.

In this case, once orid-div has been published, I assume it would not be very difficult to produce a separate term-div draft, if there is interest.

Regards,

Christer


-----Original Message-----
From: sipcore [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 28 March 2018 17:47
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

Hi Tolga, all,

Regarding your last comment and after a second thought, I don't know if there is a need for the "term-cdiv" case you propose except to be symmetrical.
I would like to have more feedback before adding a use case, changing the name and scope of the draft while it is now under working group last call status.
The name of the draft is "originating-cdiv" and its motivation from the beginning was the "orig-cdiv" use case.

Best regards,
Marianne


De : sipcore [mailto:[e-mail]] De la part de [e-mail]<mailto:[e-mail]> Envoyé : vendredi 16 mars 2018 15:18 À : Asveren, Tolga; [e-mail]<mailto:[e-mail]> Objet : Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

It is true that we could consider this “term-cdiv” case in the I-D to have a symmetric value even if for now no “need” has been identified.
I can work on this adding to the I-D.

Any other views on introducing the session case “term-cdiv” too?

BR,
Marianne

De : Asveren, Tolga [mailto:[e-mail]] Envoyé : vendredi 16 mars 2018 13:25 À : MOHALI Marianne IMT/OLN; [e-mail]<mailto:[e-mail]> Objet : RE: WGLC: draft-ietf-sipcore-originating-cdiv-parameter

Hi Marianne,

Thank you for the detailed explanation of the service. Yes, that is something used today. But how could we know that there wouldn’t be any services which would be triggered/not triggered on the diverting party based on whether it is the original initiator of the call or just the diverter? That it is not needed today -by a certain deployment model-, or that you(and I) are not aware of it does not necessarily mean it wouldn’t/is already used somewhere in the universe of real time sessions.

The ship for a more generic framework to facilitate “scenario based service invocation/interaction” may have sailed but at a minimum I would suggest adding “term-cdiv” as well.

Thanks,
Tolga

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 16, 2018 7:27 AM
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: WGLC: draft-ietf-sipcore-originating-cdiv-parameter

________________________________________
NOTICE: This email was received from an EXTERNAL sender ________________________________________

Hi Tolga,

First, thank you for the review of the draft.
To answer to the question in your first email, once a diversion has been processed, the outgoing leg will go to the diversion target but before that, the session case of the served-user has been changed with the following questions: who is the originating party? the caller or the diverting user? Does privacy of the diverting user applies? do we need to check the barring service of the diverting user for outgoing calls? OTOH, the caller remain the same and its originating services should still apply. For that particular situation somewhere between terminating and originating, the draft proposes to extend the P-Served-user.
At the diverted-to user level, it is different: It may indeed be possible to trigger a specific service for the terminating-after-diversion but this is not a new type session case. At the terminating side, the served user remains the terminating user and only its terminating services have to be triggered. Of course, terminating services based on the originating party identity are affected by the call diversion since we can discuss on who is the originating party but this is more a matter of service interaction. The served-user is the diversion target and the session case is terminating and it will not change (except if there is another call diversion ;). Just to let you know, there is a service to reject incoming forwarded calls and the trigger for this specific kind of barring is the presence of a diverting user identity in the incoming INVITE request. It is just a criterion (as for all barring services).

About your comment on the way SIP headers are extended, IMO, rules for standardization process of SIP are here for years and it is not the good time to change that. To be transparent, this extension was first defined only within 3GPP specification because there was a service need behind. Because it was an extension of an RFC and the was the syntax of the header is designed, the extension is to be done in IETF. We can discuss that but we are at the end of SIP protocol extension process...
Finally, RFC5502 defines a “private” (P- ) header so it is not surprising that its extension as a 3GPP flavor ☺

Best regards,
Marianne


De : sipcore [mailto:[e-mail]] De la part de Asveren, Tolga Envoyé : vendredi 16 mars 2018 09:06 À : [e-mail]<mailto:[e-mail]> Objet : Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

Some more musings from conceptual perspective:

SIP provides a toolbox to provide services. And yes, there is some special (if I may say “favored”) status of 3GPP when it comes to SIP standardization. OTOH, does the approach taken by RFC5502 go a little bit too far in terms of over-defining the generic SIP toolbox?

An alternative could be to define a header/parameter which refers to a “scenario” in an abstract way (with a generic syntax) and let other standards fora define the values they would like to use and/or rely on configuration alignment between relevant elements, e.g. S-CSCF/HSS/AS. Considering where we are right now (that RFC5502 is already there) this approach practically would mean that draft-ietf-sipcore-originating-cdiv-parameter is not defined and P-Served-User served-user-parm is extended by others as needed (as it allows that).

Otherwise, there would/could be the need to keep adding new values in different IETF specifications the more “deployment model specific use cases” are needed/discovered/invented.

Thanks,
Tolga
From: Asveren, Tolga
Sent: Thursday, March 15, 2018 4:23 PM
To: [e-mail]<mailto:[e-mail]>
Subject: WGLC: draft-ietf-sipcore-originating-cdiv-parameter

I reviewed the draft and have no technical issues with it except one question:

Is it envisioned that there would/could be a need for term-cdiv as well to trigger a different service set if the target is determined after diversion? It may be better to define it now rather than having yet another draft, at least to be future proof.

Thanks,
Tolga

_________________________________________________________________________________________________________________________

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.
_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_______________________________________________
sipcore mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sipcore

_________________________________________________________________________________________________________________________



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.