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

From: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 12:45:57 +0200

Jeroen,
We discussed this several years ago in ITU-T to use the contact header and again in TISPAN and I think also within 3GPP.
But it was us told from SIP experts that the Contact header can include not the real contacted URI (E.G in 3XX responses) or can point to other uri's like a service line.
So it was decided not to use Contact for this purpose.

Roland

> -----Ursprüngliche Nachricht-----
> Von: Jeroen van Bemmel [mailto:[email-masked]] 
> Gesendet: Donnerstag, 7. Juli 2005 19:48
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: Re: [Sipping] TISPAN analysis- P-Additional-header
> 
> 
> 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
> 
> 
> > 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 
> 

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 13:37:46 +0200

Arjun,
>From my memory what IETF experts says is that the P-Asserted-Identity indicates from which user the SIP Message (Request/Response) was sent.
This is also inline with the specifications defined by 3GPP where RFC3325 is the basis.

RFC3325 says:

   The P-Asserted-Identity header field is used among trusted SIP
   entities (typically intermediaries) to carry the identity of the user
   sending a SIP message as it was verified by authentication.

So the P-Asserted-Identity can be sent in Requests and Responses.

Roland

> Von: Arjun Roychowdhury [mailto:[email-masked]] 
> Gesendet: Donnerstag, 7. Juli 2005 16:58
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]
> Betreff: Re: TISPAN analysis- P-Additional-header
> 
> 
> 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
> 
> 
> On 7/7/05, Jesske, R <[email-masked]> wrote:
> > Dear all,
> 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.
> > 
> > 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.
> 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.
> > 
> 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.
> > 
> and the From header.
> -- 
> Arjun Roychowdhury

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 8 Jul 2005 14:22:07 -0400

More specifically, on p. 8-9 or RFC3325 the where column is blank, and according to RFC3261, p. 160:

"An empty entry in the "where" column indicates that the header field may be present in all requests and responses."

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jesske, R
Sent: Friday, July 08, 2005 7:38 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Sipping] AW: TISPAN analysis- P-Additional-header

Arjun,

RFC3325 says:

Roland

> 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.
> > 
> like +496151-830 for Deutsche Telekom in Darmstadt and you will get 
> back a +496151-5940 for my extension.
> 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.
> > 
> 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.
> > 
> > > > request-uri/asserted-identity combination will not work ? 
> > > > accordingly we can judge if
> > > this is to be
> > > > remedied by
> > > P-Additional-Identity header field. In my opinion what we need 
> > > here is just the P-Asserted-Identity header field in responses. 
> > > Full period.
> > >
> > > >
> > 
> 
> 
> --
> Arjun Roychowdhury
>