Hi all,
I have specific question, how add SIP Header “P-Asserted-Identity” or change it "Contact " to “P-Asserted-Identity” for case Terminating Indentification Presentation (TIP)?
It is one from requirements of the provider according:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.3940-201801-I!!PDF-E&type=items
You cannot change Contact, and the provider should not be making any use of the the user part of a Contact URI.
For chan_sip, use “sendrpid=pai”. I’m sure chan_pjsip has something similar and the connected party ID should be sent automatically.
Thank you David for your response…I use chan_sip, “sendrpid=pai” not working for this case.
Can you be more precise about what is not working. What is it sending? What do you expect it to send?
Also note that you will need trustrpid=yes on the B side if you want it to update you with the remote party to forward to the A side.
Hi David,
I think that we do not understand each other.
P-Asserted-Identity is sent to Originating Identification Presentation (OIP) but is not sent at Terminating Identification Presentation (TIP), by the way, it is sent but in the parameter “Contact”.
It is used for both, by correct implementation of connected line updating.
Contact is a URI that , if placed in the request URI field of a request will get you back to the same entity to handle the dialogue. As such, the domain part needs to reflect that, but the user part is only meaningful to that entity. Any SIP implementation that assumes it has any more meaning than that is broken.
chan_sip has no means of manipulating Contact. I think chan_pjsip, has limited features to allow the domain part to be manipulated, but I’m not sure if that allows a specific value, to be set.
In practice, I think Asterisk ignores the user part of in session request URIs, so it doesn’t care.
Also, I believe current best practice is to use Remote-Party-ID, rather than P-Asserted-Identity.
Hi David,
thank you for your response,
but provider require P-Asserted-Identity (PAI) calle according TIP send for status 200 OK for and provider not support RPID…Is it possible doing via chan_pjsip?
Thank you.
Both chan_sip and chan_pjsip pretty much behave the same way in that regard.
Hi JColp,
thank you, but is the “Asterisk” able to send the PAI according to ITU Q.3940 scenario SE.23 Terminating Identification Presentation (TIP)? It’s neccesary according this document.
I’m not prepared to go through an ITU document and decipher it in comparison to Asterisk. If you can provide actual example call flows with headers and such, then I can answer. From a general perspective we place connected line information into requests (INVITE and UPDATE) when we can, and also if configured some responses (like in a 180 Ringing).
The scope of the document doesn’t appear include end users connections, only international and network operator to network operator interfaces.
The document is a test specification, not a requirements document.
The document only applies is certain optional services (TIR) are contracted.
Although it refers to P-Asserted-ID, that is not the preferred method of providing connected line ID. I think the P- means a private use, non-standard, header. Remote-Party-ID is the current preferred method.
It appears to me that SE 23 isn’t about sending PAI, but about the circumstances under which it will not be sent,
Asterisk does have support for honouring presentation restrictions, but, off the top of my head, I can’t tell whether they completely support the scenarios in that document.
This is the first time anyone has ever asked about conformance to that document.
Support for RPID and PAI is not a requirement for SIP user agents.
Hi JColp,
here is example callflow with use PAI with status 200 OK. I can provide dump “pcap” for viewing.
Thank you all for response.
…this is from provider added PAI.
Well, tel URI is not supported for that for one thing so if they require that - then no. I also don’t think we’ll do it on the 200 OK either but I’m not certain.
… thanks for support JColp…please send me information if you implement this feature.
This is a peer support forum. No one is going to keep a list of people to inform about specific changes. You will need to monitor for changes, yourself.
