[asterisk-bugs] [JIRA] (ASTERISK-22023) SIP Caller ID - Logic of trust_id_inbound and trust_id_outbound may be off, plus help descriptions may be unclear

Rusty Newton (JIRA) noreply at issues.asterisk.org
Fri Jul 5 17:33:03 CDT 2013


     [ https://issues.asterisk.org/jira/browse/ASTERISK-22023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-22023:
------------------------------------

    Status: Open  (was: Triage)
    
> SIP Caller ID - Logic of trust_id_inbound and trust_id_outbound may be off, plus help descriptions may be unclear
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22023
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22023
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_sip
>    Affects Versions: SVN
>         Environment: SVN-trunk-r393757, Two Digium D40s with firmware 1_3_2_0_54993
>            Reporter: Rusty Newton
>            Severity: Minor
>         Attachments: full6001to6002_2.txt, full6001to6002.txt, full6002to6001_2.txt, full6002to6001.txt, res_sip.txt
>
>
> Two Digium D40 phones as Endpoints A and B
> I have trust_id_inbound=yes and trust_id_outbound=yes on endpoint A, and neither of those defined for endpoint B. 
> When A calls B, B displays a UUID on the screen where you would normally expect to see the display name from the "From:" header. 
> When B calls A, A shows the display name that you can find in B's From: header.     
> If I set the trust_id_* options for both endpoints in res_sip.conf, then they both show the display name as expected upon being called by the other.
> This behavior is confusing when set against the configuration documentation:
> {noformat}
> *CLI> config show help res_sip endpoint trust_id_inbound
> [endpoint]
> trust_id_inbound = [Boolean] (Default: no) (Regex: false)
> Trust inbound CallerID information from endpoint
> This option determines whether res_sip will accept identification from the
> endpoint received in a P-Asserted-Identity or Remote-Party-ID header. If
> 'no', the configured Caller-ID from res_sip.conf will always be used as the
> identity for the endpoint.
> *CLI> config show help res_sip endpoint trust_id_outbound
> [endpoint]
> trust_id_outbound = [Boolean] (Default: no) (Regex: false)
> Trust endpoint with private CallerID information
> This option determines whether res_sip will send identification information
> to the endpoint that has been marked as private. If 'no', private Caller-ID
> information will not be forwarded to the endpoint.
> {noformat}
> # The desc of trust_id_inbound only mentions the option applying to P-Asserted-Identity or Remote-Party-ID. The phones are sending neither of these headers and it seems the options affect the information that we use from the "From:" header. Is the description unclear?
> # I'm assuming that the usage of the terms inbound/outbound are speaking about inbound to Asterisk (from the endpoint) and outbound from Asterisk (to the endpoint). However the descriptions don't make this clear.
> # If we trust Caller ID info coming from A to Asterisk, then why do we not send it along to B if B has trust_id_outbound defaulting to NO? The description for trust_id_outbound with a 'no' value says that private Caller-ID information will not be forwarded to the endpoint. Are we marking the Caller-ID info private somehow?
> # Should we be setting the From:, user portion to a UUID when we don't trust the UA's info and don't have any Caller Id info set in the config? Why not set it something like "unknown", "not avail" or "private" (if that is the case)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list