How to set P-Asserted-Identity in 180 Ringing response to SIP Invite

Hi all,

My SIP provider expects that the P-Asserted-Identity is set in my 180 ringing response to their Sip Invite. How can I achieve that in Asterisk 11 ?

You basically set the PAI header with a pre-dial handler for an outgoing call, but that would affect only the INVITE. That would refer to the PJSIP stack, that does not exist in Asterisk 11, if I remember correctly.

Are you sure that they what this parameter in the ringing response? They already have a unique Call-Id to look up things, if necessary.

The provider is being unreasonable as PAI isn’t a mandatory SIP header, and doesn’t even have a proper RFC. My guess is they are misusing it.

However, have you set sendrpid=pai, in your configuration?

Adding headers which Asterisk generates itself is not generally a good idea, and I don’t think the chan_sip header adding mechanism works for initial responses.

At the time that 180 is sent, Asterisk’s idea of PAI is unlikely to differ from the request URI for the transaction.

Note that Asterisk 11 hasn’t been fully supported for more than four and a half years, and will have unfixed security vulnerabilities/

Also, any value of PAI other than the request URI, is likely to be meaningless to the provider, unless you to to significant trouble to map it to a a PSTN number. They are not going to know what to do with your local extension number.

I am not sure in the parameter is very necessary. Yes, I have set sendrpid=pai, in my configuration. The provider is unable to tell me why their gateway is not accepting my 100 Trying and 180 Ringing. Their gateway keeps re-sending the Invite. So what I did was to compare my SIP trace to another that works. I noticed some differences.
Below are the two traces (I have changed the phone numbers):

From Asterisk 11 which does not work:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.120.1:5060;branch=z9hG4bK00000042144547386236;received=172.16.120.1
Record-Route: <sip:172.16.120.1:5060;transport=UDP;lr>
From: <sip:3333@172.16.120.1;user=phone>;tag=12002087495733
To: <sip:7777@172.16.150.44;user=phone>
Call-ID: )<fQ1511118150o!bcGhEfGhFlI0l@172.16.120.1
CSeq: 193860353 INVITE
Server: IPBX-2.11.0(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:7777@172.16.150.44:5060>
Content-Length: 0


SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.16.120.1:5060;branch=z9hG4bK00000042144547386236;received=172.16.120.1
Record-Route: <sip:172.16.120.1:5060;transport=UDP;lr>
From: <sip:3333@172.16.120.1;user=phone>;tag=12002087495733
To: <sip:7777@172.16.150.44;user=phone>;tag=as16b6a2d3
Call-ID: )<fQ1511118150o!bcGhEfGhFlI0l@172.16.120.1
CSeq: 193860353 INVITE
Server: IPBX-2.11.0(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:7777@172.16.150.44:5060>
Content-Length: 0


SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.120.1:5060;branch=z9hG4bK00000042144547386236;received=172.16.120.1
Record-Route: <sip:172.16.120.1:5060;transport=UDP;lr>
From: <sip:3333@172.16.120.1;user=phone>;tag=12002087495733
To: <sip:7777@172.16.150.44;user=phone>;tag=as16b6a2d3
Call-ID: )<fQ1511118150o!bcGhEfGhFlI0l@172.16.120.1
CSeq: 193860353 INVITE
Server: IPBX-2.11.0(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:7777@172.16.150.44:5060>
Content-Type: application/sdp
Content-Length: 233
v=0
o=root 771524264 771524264 IN IP4 172.16.150.44
s=Asterisk PBX 11.25.3
c=IN IP4 172.16.150.44
t=0 0
m=audio 18588 RTP/AVP 8 96
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=sendrecv

And here is the trace from another server that works:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.120.1:5060;branch=z9hG4bK00000120230867305389
From: <sip:3333@172.16.120.1;user=phone>;tag=09000330945057
To: <sip:7777@172.16.150.44;user=phone>
Call-ID: sgdT4372810140tybcGhEfEfNmF0i@172.16.120.1
CSeq: 849768641 INVITE
User-Agent: FreeSWITCH
Content-Length: 0


Via: SIP/2.0/UDP 172.16.120.1:5060;branch=z9hG4bK00000120230867305389
Record-Route: <sip:172.16.120.1:5060;transport=UDP;lr>
From: <sip:3333@172.16.120.1;user=phone>;tag=09000330945057
To: <sip:7777@172.16.150.44;user=phone>;tag=mmN3UU734BB7p
Call-ID: sgdT4372810140tybcGhEfEfNmF0i@172.16.120.1
CSeq: 849768641 INVITE
Contact: <sip:7777@172.16.150.44:5060;transport=udp>
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0
P-Asserted-Identity: "7777" <sip:7777@172.16.150.44>


Via: SIP/2.0/UDP 172.16.120.1:5060;branch=z9hG4bK00000120230867305389
Record-Route: <sip:172.16.120.1:5060;transport=UDP;lr>
From: <sip:3333@172.16.120.1;user=phone>;tag=09000330945057
To: <sip:7777@172.16.150.44;user=phone>;tag=mmN3UU734BB7p
Call-ID: sgdT4372810140tybcGhEfEfNmF0i@172.16.120.1
CSeq: 849768641 INVITE
Contact: <sip:7777@172.16.150.44:5060;transport=udp>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 246
P-Asserted-Identity: "7777" <sip:7777@172.16.150.44>
v=0
o=FreeSWITCH 1620959650 1620959651 IN IP4 172.16.150.44
s=FreeSWITCH
c=IN IP4 172.16.150.44
t=0 0
m=audio 32050 RTP/AVP 8 96
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=silenceSupp:off - - - -
a=ptime:20

You haven’t provided the corresponding requests.

The Call-ID is pushing the envelope, but does seem to be valid, but is it what was received?

Only Call-ID, tag, and branch should matter, as far as determining whether a response was received.

This was the initial Invite from the provider:

INVITE sip:7777@172.16.150.44;user=phone SIP/2.0
From: <sip:3333@172.16.120.1;user=phone>;tag=12002087495733
To: <sip:7777@172.16.150.44;user=phone>
Max-Forwards: 70
Via: SIP/2.0/UDP  172.16.120.1:5060;branch=z9hG4bK00000042144547386236
Record-Route: <sip:172.16.120.1:5060;transport=UDP;lr>
Call-ID: )<fQ1511118150o!bcGhEfGhFlI0l@172.16.120.1
CSeq: 193860353 INVITE
P-Asserted-Identity: <sip:3333;cpc=ordinary@172.16.120.1;user=phone>
Accept: application/sdp
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,PRACK,UPDATE
P-Charging-Vector: icid-value=47AC981000-0515-18114801;icid-generated-at=172.16.120.1;orig-ioi=TIGO.COM.GH
Supported: 100rel
Content-Type: application/sdp
Contact: <sip:172.16.120.1:5060;transport=UDP>
Content-Length:  293
v=0
o=- 5532922 5532922 IN IP4 172.16.120.1
s=-
c=IN IP4 172.16.32.5
t=0 0
a=sendrecv
m=audio 56880 RTP/AVP 18 8 96
c=IN IP4 172.16.32.5
b=RR:0
b=RS:0
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=maxptime:40

Your Server header is technically invalid, but I’m surprised anything would care about that. A space mandated by the syntax, before the comment, is missing.

I will check on that. Many thanks.