Jump to content

Barnaby Puttick

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Barnaby Puttick

  1. 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.



  2. 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.


  3. 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.


  4. 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? 



  5. 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


  • Create New...