Jump to content

4.3.22 update and call forwarding issues


Arek

Recommended Posts

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

Link to comment
Share on other sites

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>

 

Link to comment
Share on other sites

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 by Barnaby Puttick
spelling (see edit history)
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by Barnaby Puttick (see edit history)
Link to comment
Share on other sites

×
×
  • Create New...