Summary:ASTERISK-22023: SIP Caller ID - Logic of trust_id_inbound and trust_id_outbound may be off, plus help descriptions may be unclear
Reporter:Rusty Newton (rnewton)Labels:
Date Opened:2013-07-05 17:25:34Date Closed:2013-07-29 11:20:01
Versions:SVN Frequency of
Environment:SVN-trunk-r393757, Two Digium D40s with firmware 1_3_2_0_54993Attachments:( 0) full6001to6002_2.txt
( 1) full6001to6002.txt
( 2) full6002to6001_2.txt
( 3) full6002to6001.txt
( 4) res_sip.txt
Description: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:

*CLI> config show help res_sip endpoint trust_id_inbound
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
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.

# 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)
Comments:By: Rusty Newton (rnewton) 2013-07-05 17:31:25.164-0500

Attaching Asterisk SIP logs and res_sip config.

Files ending with _2 have calls where both endpoints have trust_id_* options set to yes.

Files without _2 have calls where only 6001 has the trust_id_* options set to yes and 6002 has them commented out.

By: Mark Michelson (mmichelson) 2013-07-08 09:03:05.035-0500

Try revision 393793. Prior to that, the trust_id_outbound option was required even if sending non-private caller ID. It should be fixed now.  To answer your questions:

1. The description is off if it only mentions specific headers. It should be more general and just mention not sending identification. P-Asserted-Identity and Remote-Party-ID can be used as examples of identification headers, but From is a valid header to be sending identification in as well (and is affected by trust_id_outbound).

2. Yes, the usage of inbound/outbound is as you mention. There was no specific mention of this in the SIP documentation because this usage of inbound/outbound is always how they are used in Asterisk. In other words, everything is from Asterisk's perspective.

3. This was the bug that should be fixed now. The fact that the ID was not private should have made trust_id_outbound have no effect on whether we sent outbound identification.

4. I have a feeling that the UUID setting is a temporary placeholder that is meant to be replaced before release. We'll likely have an option similar to chan_sip's "fromuser" setting so that it can be customized to be what the administrator wants it to be, with "anonymous" as the likely default.

By: Rusty Newton (rnewton) 2013-07-24 16:52:06.362-0500

Try revision 393793. Prior to that, the trust_id_outbound option was required even if sending non-private caller ID. It should be fixed now.

Verified. Tested in 393816. Now all I needed was trust_id_inbound=yes for each endpoint where I wanted to use the endpoints provided CallerID.