Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

From: N WEINRONK <[email-masked]>
Date: Sat, 12 Mar 2016 08:58:11 +0000 (GMT)

I realise I have to tread carefully - however to me I am trying to have a header for diverted calls like P-Asserted-Identity for basic calls.
I have had a look at 3GPP P-headers and could not find a good fit.
I agree that the information I want in the new header will have to be used by STIR for diverted calls.
For mappings to SS7 - at least in the UK - we already have a parameter to convey this information - therefore the mapping is 'easy'.
This is not about pure transit operators but about operators who provide service to subscribers hosted on another network - via Carrier Pre-Selection or Indirect Access for example.
I hope I have detailed the requirements for this work in the ID.
I believe I have investigated the use of History-Info and as far as can see I cannot fit this into its structure and even if I could I am not sure it would be a good thing to do as explain in previous answers.
Thanks,
Nigel
----Original message----
>From : [email-masked]
Date : 10/03/2016 - 00:05 (GMTST)
To : [email-masked], [email-masked], [email-masked], [email-masked]
Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
Nigel,
 
You are treading on a variety of current SIP headers for:
-          Tracking redirections
-          Presentation of the source of the call
-          Billing for the call.
 
Could you address the 3GPP P-header for billing indication?
 
I mention STIR because there are issues around how to properly attribute the source of a call.
Which is precisely what you are attempting to do.
That affects not only billing but fighting robo-calls which are a concern even in the UK.
 
Having suffered through the mapping issues in IETF and in ITU-T SG11 some years ago, 
I would caution you to proceed carefully, as every new header adds a new complicating factor.
 
And if you are just doing purely transit operations between SS7 systems, 
I could even suggest you look into Q.1980.1.  J
 
I raised a red flag here only because this seemed like déjà vu all over again.
And am looking for more thorough investigation.
I will have to refresh my memory to provide more complete response to your requirements.
But, in the meantime explicitly detailing all those requirements will help with this process..
 
________________________________
Michael Hammer
[email-masked]
+1 408 202 9291
© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 09, 2016 5:41 PM
To: [email-masked]; Michael Hammer <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
 
Dear Nigel,
 
After a reading of the draft, I have the following comments :
-          First, I wonder about having a standard, even informational, to solve a country-specific need to convey an ISUP National parameter…hum
-          Second, I do think we can find a solution to solve your issue by using the History-Info header. I don’t know yet how. J
 
IIUC, you need to convey the asserted identity of the diverting user into the forwarded leg even when he has been called to his declarative identity.
I see several mechanisms in History-Info header that could be used for this purpose:
-          first you should know that it can be added additional entries in the History-Info header even when the Request URI does not change. In this case, the index should be increased (1->2) and not extended (1 -> 1.1) as when forking is executed
-          to be able to distinguish this identity from the normal diverting identity, you could use the "rc" hi-target-param to refer to the normal History-Info entry for the diversion and link both. With this mechanism, at the interworking you could find the last diverting identity as described in 29.163 and then search for the entry having a "rc" parameter having a value equals to the current (last diverting address) hi-entry index value. 
-          finally, you could imagine a dedicated cause URI parameter (different from those defined in RFC4458 for call diversion service)

Best regards,
Marianne
 
De : dispatch [mailto:[email-masked]] De la part de N WEINRONK
Envoyé : mercredi 9 mars 2016 23:08
À : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Not sure I agree with the non-sequitur statement but lets move on.
Let us explore the statement that History-Info "should" work a little more:
 
Can you explain how 1 entry can have a 'presentation' and a 'network asserted' identity that can be different - were you thinking of the hi-extension ?
Just to add to this in the UK (I can only really comment on this) the specification of ETSI ISDN diversion services mandates that both the 'network asserted' and the 'presentation' identities of the Diverting Party are passed between operator networks on Diverted calls.
This allows 'transit' operators handling Carrier Pre-select Diverted calls to verify and bill the user. 
All the documents I have seen be it 3GPP/IETF maps History-Info into Redirecting Number - Redirecting Number does not have a screening indicator and is used directly for display in ETSI ISDN. 
In cases where the 'network asserted' identify is different from the 'presentation' identity it is not clear to me how the information in the History-Info header can be 'network asserted'.
 
I do not think it is 'this diversion' that is different it is the ability to consistently pass 'network asserted' and 'presentation' identities for Diversion information. 
 
Not sure how STIR is related ? 
 
Thanks,
Nigel

----Original message----
>From : [email-masked]
Date : 09/03/2016 - 20:13 (GMTST)
To : [email-masked], [email-masked], [email-masked]
Subject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
Nigel,
 
Your logic was a non-sequitor.
Like saying cats like milk, therefore don’t give chocolate to a dog.  
The conclusion has nothing to do with cats and milk.
 
So, while such logic is not conclusive for or against a separate header, 
the burden of proof for a separate header should lie on the one proposing a new header, 
when face with the existing of a header that “should” work.  (the question at hand)
 
A separate header is warranted when an existing header has the wrong semantics 
and the existing syntax just won’t work.  However, that doesn’t seem to be the case.
 
If another implementation judges that the H-I header is a perfect fit, then you won’t be looking there.
Some existing implementations just might be doing this already.
So, just want to be careful about willy nilly adding new headers.
 
I would note that both the Route header and the H-I header can be “network asserted”.
So, what makes this particular diversion different from H-I envisaged?
 
You make it sound like it should be part of the STIR discussion, when you compare to P-Asserted-ID.
Have you looked into that WG?
 
________________________________
Michael Hammer
[email-masked]
+1 408 202 9291
© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
 
From: N WEINRONK [mailto:[email-masked]] 
Sent: Wednesday, March 09, 2016 2:00 PM
To: Michael Hammer <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Thanks for your time.
 
Please explain the negative consequences of a separate header ?
 
The only place I saw that this could have been placed in History-Info was as an hi-extension because it is really a 'network asserted id' of the hi-targeted-to-uri and this would place requirements on lots of functions to search History-Info entries to remove this 'network asserted' identity when required. 
To me this is the same as From / P-Asserted-Identity - the P-Asserted_Identity was not place in the From header as a parameter - I guess it could have been.
I think the same argument applies here in keeping the 'network asserted identity' and the 'presentation identity' for the same user apart in the signalling.
Note: This also matches the ISUP implementation - a separate distinct parameter.
I see nothing illogical in a separate header.
Thanks,
Nigel
 
----Original message----
>From : [email-masked]
Date : 09/03/2016 - 17:20 (GMTST)
To : [email-masked], [email-masked], [email-masked]
Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
There is a danger here that this purpose could be supported by two different headers 
(a new header or an old header) with potential negative consequences.
 
Please show what prevents you from supporting this purpose with History-Info?
 
The argument that because A is supported by B, therefore C is not supported by B, is illogical.
 
________________________________
Michael Hammer
[email-masked]
+1 408 202 9291
© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
 
From: dispatch [mailto:[email-masked]] On Behalf Of N WEINRONK
Sent: Wednesday, March 09, 2016 6:05 AM
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Thank you for your comments on this Internet Draft – I will try and answer your points.
Do you believe it is legacy from the early ISDN definitions or do you believe it is new? 
Neither it a consequence of the way ETSI ISDN was implemented in the UK in the 1990s that is still in use today – see below.
Note: I assume by early ISDN definitions you mean where ETSI ISDN was mapped to DASS and I am not talking about this.
Can you explain where a proposed UK requirement comes from that is not contained within the ETSI and ITU-T service definitions for the ISDN? 
This comes from current implementations in the UK based on NICC ND1007.
In UK ISUP there is a parameter optional in the IAM – Last Diverted Line Identity in additional to the ITU/ETSI parameter Redirecting Number.
There are times when these parameters are both present and can hold different information.
You could see this as being analogous to FROM and P-Asserted-Id headers in SIP with the Last Diverted Line Identity parameter being the ‘network asserted identity’ used by networks other that the network diverting the call to verify service and the Redirecting Number parameter being the ‘presentation number’.
The cases I am aware of where these parameters can hold different information come from ETSI ISDN diversion scenarios – Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection / Partial Rerouting.
For Partial Rerouting the Last Diverted Line Identity parameter is based on the ‘administration number’ as understood by the network doing the diversion and the network doing the verification and billing for these calls. The Redirecting Number parameter is set from the lastReroutingNr from the ASN.1 the private network sets in the Q.931 SETUP message – these can/will be different.
For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection the Last Diverted Line Identity parameter is based on the ‘administration number’ as understood by the network doing the diversion and the network doing the verification and billing for these calls. The Redirecting Number parameter is set to the Called Party Number used to reach the diverting party – these are not necessarily the same.
I’d also note that I believe if this is required then an addition to the History-Info header field would be more appropriate. 
We (myself and the UK NICC SIP Task Group) did consider using the History-Info header for this but as the mappings are already defined from Redirecting Number parameter to History-Info by the IETF / ETSI / ITU it was felt this would be confusing and make the mappings complicated.
Also I would expect this header to (like the Last Diverted Line Identity parameter in UK ISUP) be limited in where it can be sent ie. between network operators and not to end users again making use of History-Info more complicated.
Nigel Weinronk
 
----Original message----
>From : [email-masked]
Date : 09/03/2016 - 02:47 (GMTST)
To : [email-masked], [email-masked]
Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
Can you explain where a proposed UK requirement comes from that is not contained within the ETSI and ITU-T service definitions for the ISDN?
 
Do you believe it is legacy from the early ISDN definitions or do you believe it is new?
 
I’d also note that I believe if this is required then an addition to the History-Info header field would be more appropriate.
 
Regards
 
Keith Drage
 
From: dispatch [mailto:[email-masked]] On Behalf Of EXT Hutchison, Phil
Sent: 04 March 2016 08:20
To: [email-masked]'
Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
 
Hi,
 
I believe that this is required in the UK, and therefore would like to see the draft accepted.
 
Regards
 
Phil 
~~~~~~~~~~~~~~~~~ 
Phil Hutchison 
Liberty Global CAO - Communications Architecture 
Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email [email-masked] 
Meet Me Conference: 0808 1074444  [+44 1723204444] PIN 1256450#
Visit www.virginmedia.co.uk for more information, and more fun 
Save paper - do you really need to print this email?
 
--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?
Visit www.virginmedia.com for more information, and more fun.
This email and any attachments are or may be confidential and legally privileged
and are sent solely for the attention of the addressee(s). If you have received this
email in error, please delete it from your system: its use, disclosure or copying is
unauthorised. Statements and opinions expressed in this email may not represent
those of Virgin Media. Any representations or commitments in this email are
subject to contract. 
Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire, RG27 9UP
Registered in England and Wales with number 2591237

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