Barnaby Puttick

This was tested on 4.3.29 and seems to be still prevalent in master and 4.3 (untested)

Hi, I seem to have discovered a bit of an issue using crossbar to retrieve ledger entries. There is a situation where crossbar does not return all expected records due to a bug when chunking is used (the default) Crossbar expects the "key" to be unique so it can pass the next_key to get the following chunked result and to determine EOF when last_key==next_key (chunking exhausted). cb_ledger use the "list_by_source" view to iterate through the records which has the "key" defined as [{service}, {pvt_created}] - however if there are 2 or more service entries that were created at the same time (multiple legs) this key is no longer unique and when this falls on a chunked boundary crossbar misinterprets this as EOF returning an incomplete result. This can be easily demonstrated by setting the chuck_size to 1 so that every entry is a chunk boundary and any duplicate key triggers a result exhaustion. For most part, this chunk exhaustion will not occur because the default chunk_size and page_size are both 50 resulting in a page exhaustion first. The question is, should this be fixed in crossbar's chunking algorithm or should the ledger view be changed to force a unique key? A temporary fix is to use is_chunked=false query parameter to disable chunking if you're experiencing missing records. Barnaby

@Yuriy It appears that the callflow ring_group has the option "fail_on_single_reject"; which looks like will do what you want. https://github.com/2600hz/kazoo/blob/master/applications/callflow/doc/ring_group.md

@Yuriy, sorry I think I understand now... You want the mobile (second) device to drop/not ring if the the first device rejects the call? I am not sure that's possible.

@Yuriy if I understand correctly i don’t think you want a ring group but chain 2 devices together on the callflow. So the first device rings and if the device rejects the call before answering callflow will move on to the second

@rdg154 you can create blacklists and apply them to accounts https://github.com/2600hz/kazoo/blob/master/applications/crossbar/doc/blacklists.md

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

"pvt_used_by": "callflow"

Happy to publish a PR for this if the demand is there..

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

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

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

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

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

Hi, Arek. Are you able to post example SIP INVITE packets before and after the update? Barney