Subject: [Sipping] TISPAN analysis- P-Additional-header

From: "Jesske, R" <[email-masked]>
Date: Thu, 7 Jul 2005 12:57:09 +0200

Dear all,
What I/we need is two identities sent back from the destination to the caller.

Within the PSTN/ISDN world we have two identities sent back to the originating user called:
Connected number and additional connected number. This is due to an special arrangement feature that allows a user to send back an official trusted and screened number and a number of the user of the end client.

Used within the PSTN for PBX. 

So If you call a PBX you will get back the official number like +496151-830 for Deutsche Telekom in Darmstadt and you will get back a +496151-5940 for my extension.
It will be used for Call Centres with one incoming number e.G. a 0800 number that diverts the traffic to several extensions. And then the extension itself sent back the true number of the connected party e.g. +4969111111.

Within SIP we need a equivalent functionality that is interoperable with the PSTN/ISDN, because in the interworking case only the 0800 will be mapped to the P-Asserted-Identity but there is no mapping of the additional connected number.

So we need an additional identity field including a second identity.

In SIP forward direction we have  The P-Asserted-Identity and the From header.

In backward direction my proposal was this P-Additional-header.

So is there something existing id to include this.

Other solutions?

Best Regards

Roland

> > 
> > 2.3.1: P-Additional-Identity
> > 
> > I am concerned that from an overall perspective, figuring out who a
> > call came from
> > is becoming a huge mess for the called party. We already 
> have request uri, from,
> > asserted-identity. Adding a p-additional-identity just adds to the
> > melee. Can this document
> > describe scenarios as to why adding this information to the
> > request-uri/asserted-identity
> > combination will not work ? accordingly we can judge if 
> this is to be
> > remedied by
> > sticking another header or requesting that intermediaries follow a
> > certain standard
> > procedure for callflow to make the identification work.
> 
> I fully agree with you, and although I am author in the analysis 
> documents, I don't agree with the existance of the 
> P-Additional-Identity 
> header field. In my opinion what we need here is just the 
> P-Asserted-Identity header field in responses. Full period.
> 
> > 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 7 Jul 2005 10:58:20 -0400

Roland,
I am not really sure I understood the 0800 call centre example wrt.
what needs to be returned (and more importantly, how it will be used
by the recipient)

One of the things that RFC 3325 does not explictly mention is "where"
P-Asserted-Identity can be used. It cites examples of requests but
there is no text that says it cannot be used in responses. Infact,
around a year ago this was raised in one of the sip-xxx mailing lists
and at that time the participators of the thread seemed to agree that
PAI in responses  were useful too.

If this is true, does it not meet your requirement of a asserted
identity being passed back by the called party ?

regds
arjun

-- 
Arjun Roychowdhury

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 7 Jul 2005 19:48:00 +0200

Roland,

What about using the Contact header to return the extension?

Jeroen

----- Original Message ----- 
From: "Jesske, R" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 07, 2005 12:57 PM
Subject: [Sipping] TISPAN analysis- P-Additional-header

> Connected number and additional connected number. This is due to an 
> special arrangement feature that allows a user to send back an official 
> trusted and screened number and a number of the user of the end client.
>
> So If you call a PBX you will get back the official number like 
> +496151-830 for Deutsche Telekom in Darmstadt and you will get back a 
> +496151-5940 for my extension.
> It will be used for Call Centres with one incoming number e.G. a 0800 
> number that diverts the traffic to several extensions. And then the 
> extension itself sent back the true number of the connected party e.g. 
> +4969111111.
>
> Within SIP we need a equivalent functionality that is interoperable with 
> the PSTN/ISDN, because in the interworking case only the 0800 will be 
> mapped to the P-Asserted-Identity but there is no mapping of the 
> additional connected number.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2005 14:31:27 -0400

> It will be used for Call Centres with one incoming number e.G. a 0800 number that diverts the traffic to several extensions. And then the extension itself sent back the true number of the connected…

As with many PSTN-isms, this seems more or less incomprehensible to 
those who have not been thoroughly indoctrinated with PSTN dogma.

The names give no hint at the intended semantics. Of what use are two 
numbers to the caller? Is it expected that both will be displayed? If 
so, which one should a caller save for future reference and use?

> Within SIP we need a equivalent functionality that is interoperable with the PSTN/ISDN, because in the interworking case only the 0800 will be mapped to the P-Asserted-Identity but there is no mapp…

IMO one of the major goals of SIP is to improve upon the PSTN. Part of 
improving upon it is to remove things that make no sense or have 
outlived their usefulness. Another is to clarify things that are 
ambiguous. I think one or the other of those probably apply in this case.

> In SIP forward direction we have  The P-Asserted-Identity and the From header.

I think it is generally understood that the From header is useless for 
identification purposes when the P-Asserted-Identity header is being 
used. The P-A-Id header was introduced because technical reasons 
prevented the updating of From by intermediaries.

Similarly, the To header is also useless for identification purposes.

> In backward direction my proposal was this P-Additional-header.

There have been proposals before for a Connected-Party header of some 
sort. See

   www.softarmor.com/wgdb/docs/draft-jennings-sipping-connected-00.html

I'm sure somebody will point to newer material.

	Paul