Arek Posted March 6, 2019 Report Posted March 6, 2019 Hi everyone, 4.3.22 update adds P-Asserted-Identity to INVITE and when you call forward with "Keep Original Caller ID" option checked it will still show account caller Id instead of original caller ID. And that's because many carriers will use P-Asserted-Identity as legit caller id information and use it instead of FROM header. I'm wondering if carriers I use should not be using it to set caller id or Kazoo should not be sending it this way. Arek
Barnaby Puttick Posted March 6, 2019 Report Posted March 6, 2019 Hi, Arek. Are you able to post example SIP INVITE packets before and after the update? Barney
Arek Posted March 6, 2019 Author Report Posted March 6, 2019 Sure, here is before: INVITE sip:forwarded_to_number@xxx SIP/2.0 Via: SIP/2.0/UDP XXX:11000;rport;branch=z9hG4bK89av9KNXj176g Max-Forwards: 70 From: "Caller Name" <sip:caller_number@xxx>;tag=yp3tSBpp9Xrtg To: <sip:forwarded_to_number@xxxx> Call-ID: 011c88ba-3ef8-11e9-b763-c17ba6c41aeb CSeq: 1324733 INVITE Contact: <sip:mod_sofia@xxx:11000> User-Agent: 2600hz Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 248 X-FS-Support: update_display,send_info Remote-Party-ID: "Caller Name" <sip:caller_number@xxx>;party=calling;screen=yes;privacy=off and here is after update: INVITE sip:forwarded_to_number@xxx SIP/2.0 Via: SIP/2.0/UDP xxx:11000;rport;branch=z9hG4bKgXQFF73QH5y8m Max-Forwards: 70 From: "caller name" <sip:caller_number@xxxx>;tag=N7eKFHF7QXa4a To: <sip:forwarded_to_number@xxx> Call-ID: a4c6701a-3edb-11e9-9c45-c17ba6c41aeb CSeq: 1318642 INVITE Contact: <sip:mod_sofia@xxx:11000> User-Agent: 2600hz Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 248 X-FS-Support: update_display,send_info P-Asserted-Identity: "Account Name" <sip:account_number@kazoo.realm>
Barnaby Puttick Posted March 7, 2019 Report Posted March 7, 2019 (edited) Arek, I can't seem to reproduce this.. I have tried various scenarios with call_forwarding with and without keep caller id and have set the caller id at various stages from device, user, account and the From: and P-Asserted-Identity always matches (and contains the CLI you'd expect) Can you explain your setup a little bit more please and provide where/how you have the CLI configured, ie on the device/user/account Barney Edited March 7, 2019 by Barnaby Puttick spelling (see edit history)
Arek Posted March 15, 2019 Author Report Posted March 15, 2019 Barnaby, Could you post your INVITES? Are you on 4.3.22? Arek
Barnaby Puttick Posted March 15, 2019 Report Posted March 15, 2019 (edited) I am afraid, I'd have to restage this to get them again, but they were the same as yours except the P-Asserted-Identity matched the From header. and they were either the original caller or the forwarding caller depending on the "keep original caller id" flag Edited March 15, 2019 by Barnaby Puttick (see edit history)
jeroen Posted March 26, 2019 Report Posted March 26, 2019 We face the same issue. Since this version the following header is added to the outbound calls (and also forwards). "custom_sip_headers": ⊖{ "p_asserted_identity": "\"Name\" <sip:+xxxxxxx@realm>"
Barnaby Puttick Posted April 1, 2019 Report Posted April 1, 2019 I have done some more tests and this scenario produces the same INVITE as Arek describes: User/Device A (External CID: +1400111111) dials Ext: 6666 Callflow sets up the endpoint for ext 6666 to call User/Device B User/Device B has an unconditional call forward to +1555888888 with "Keep Original Caller ID" set. User and Device B have no CID set, but the Account has +1400222222 set. So the INVITE packet will be something like: INVITE sip:+1555888888@realm SIP/2.0 From: <sip:+1400111111@realm>;tag=Sc0tZF8N07Kam To: <sip:+1555888888@realm> P-Asserted-Identity: <sip:+1400222222@realm> Kazoo will set the P-Asserted-Identity to what it believes to be the authoritative caller ID. This will be determined from the Device/User/Account in that order. So in the case of Arek's first example on the outbound (diverted leg) Device A will not be considered authoritative in Kazoo's eyes for the outbound diverted leg. The PAI header tells the carrier that irrespective of what's set in the From header, the PAI header is the CLI that should be "trusted" - this is used for authentication/billing and it's the choice of the upstream carrier based on the trust relationship you have with them whether they should use the From or the PAI for the released caller id. The question that rises from this is that if Device A and Device B belong to the same realm/account and Kazoo authoritatively establishes Device A's CID, then should that be used in preference to the Account's CID given that Device B has nothing set? Barnaby
jeroen Posted April 1, 2019 Report Posted April 1, 2019 I follow your steps @Barnaby Puttick. The account "default" number is indeed used for the P-Asserted-Identity. Will it be fixed in a future release?
Barnaby Puttick Posted April 1, 2019 Report Posted April 1, 2019 Jeroen, this is the correct behaviour - the only thing as I say is that maybe the calling device being on the same realm could be considered authoritative, but I think the issue is more down to your upstreams using the PAI for the CLI over the From header; which is something you'd need to discuss with them. Barnaby
brian Posted April 1, 2019 Report Posted April 1, 2019 I would suggest that this should be on a switch - most carriers will use PAI if present for caller ID
Barnaby Puttick Posted April 1, 2019 Report Posted April 1, 2019 (edited) 1 hour ago, brian said: I would suggest that this should be on a switch - most carriers will use PAI if present for caller ID Perhaps there should be a sendrpid=no|yes|pai option for the resource to fix it for carriers that don't support it as intended? It seems to work as expected with my carriers, but if it is most carriers then I guess there will be a lot of people complaining and this will get pushed through quickly. Barnaby Edited April 1, 2019 by Barnaby Puttick (see edit history)
Barnaby Puttick Posted April 1, 2019 Report Posted April 1, 2019 Happy to publish a PR for this if the demand is there..
Administrators Darren Schreiber Posted April 2, 2019 Administrators Report Posted April 2, 2019 This was already reverted in the latest build - please check it.
Barnaby Puttick Posted April 2, 2019 Report Posted April 2, 2019 I haven't tested this, but I can see that as of 4.3.26 an update (KAZOO-6067) was made to not make this the default action. If you want this behaviour you can turn it back on in callflow.resources system_config using "default_asserted_identity": true
Recommended Posts