[asterisk-bugs] [JIRA] (ASTERISK-26863) res_pjsip: Add endpoint identification scheme based on a configured SIP header/value

[Kevin Harwell (JIRA)]

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

Kevin Harwell updated ASTERISK-26863:
-------------------------------------

    Target Release Version/s: 13.4.0

> res_pjsip: Add endpoint identification scheme based on a configured SIP header/value
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26863
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26863
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Resources/res_pjsip
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>      Target Release: 13.4.0, 13.15.0
>
>
> h3. Background
> Consider a system in which we have an Asterisk server, on a private network, receiving requests from two pools of Kamailio proxies:
> {noformat}
>  a.a.a.a                  b.b.b.b
> +--------------+       +---------------+
> |              |       |               |
> |              |       |               |
> |  Kamailio a  |       |  Kamailio b   |
> |              |       |               |
> |              |       |               |
> +------+-------+       +-------+-------+
>        |                       |
>        |                       |
>        |                       |
>        |               +-------v------+
>        |               |              |
>        |               |              |
>        +--------------->   Asterisk   |
>                        |              |
>                        |              |
>                        +--------------+
> {noformat}
> In some scenarios, we won't want to identify all calls by {{From}} username (such as when the proxies are forwarding calls to Asterisk from an upstream PSTN provider). We can identify all of the requests coming from proxy pool {{a}} and proxy pool {{b}} by simply matching on their IP address. That is:
> {code}
> [kamailioA_matcher]
> type=identify
> endpoint=kamailioA
> match=a.a.a.a
> [kamailioB_matcher]
> type=identify
> endpoint=kamailioB
> match=b.b.b.b
> {code}
> And this works fine for most scenarios. However, there are a few major drawbacks with this:
> # If a proxy is replaced by a proxy with a new IP address, all of the Asterisk instances have to have their configuration be updated with new address mappings. While this can be alleviated by using DNS, the address resolution typically only occurs when the Sorcery object is created, which may not be when we'd want.
> # In scenarios where pools of services are grown/shrunk, the act of having to update IP address information is generally clunky and/or discouraged.
> # In a development environment, the above scenario is unworkable. It is *theoretically* possible (although maybe not wise) to run two Kamailio proxies and an Asterisk instance on the same machine. However, using an IP address matching object, Asterisk will be unable to differentiate between requests from the two proxy pools, as both will appear to have the same IP address (as... they do. The request origination address would only differ in port.)
> h3. Ye Olde Proposal
> While IP address matching is generally sufficient for most sane scenarios, something additional that is defined in the SIP messages would be nice. While this may not be generally applicable to a publicly accessible Asterisk, on a private instance fronted by proxies who can do the appropriate header manipulation, passing back a magic token to identify the source of the requests can be useful.
> Something like:
> {noformat}
> INVITE sip:echo at 127.0.0.1:5060 SIP/2.0
> Via: SIP/2.0/UDP 127.0.0.1:5064;branch=z9hG4bK-3683-1-3
> From: test1 <sip:unknown at 127.0.0.1:5064>;tag=1
> To: test <sip:test at 127.0.0.1:5060>
> Call-ID: 1-3683 at 127.0.0.1
> CSeq: 2 INVITE
> Contact: <sip:test at 127.0.0.1:5064;transport=UDP>
> Max-Forwards: 70
> Authorization: Digest username="alice",realm="asterisk",cnonce="6b8b4567",nc=00000001,qop=auth,uri="sip:127.0.0.1:5060",nonce="1489429230/435541671ee1149376151064e497eeed",response="1b5e7c1a6328cb1972db8cd5f07fc2b8",algorithm=md5,opaque="1e6934d175cf2b4a"
> Subject: Test
> User-Agent: Test
> X-ASTERISK-TOKEN: e7657250-07fa-11e7-92f8-1b946c0c7e84
> Content-Length: 0
> {noformat}
> A new identify matcher can then map this request to an endpoint using a configuration object:
> {code}
> [kamailioA_matcher]
> type=identify_header
> header=X-ASTERISK-TOKEN
> value=e7657250-07fa-11e7-92f8-1b946c0c7e84
> {code}
> Note that since the token is just a UUID, the Kamailio proxy can have whatever address it wants, and the Asterisk instance will never have to be updated.
> h3. Caveats
> # This is not a replacement for authentication.
> # The act of passing a token back and doing that correctly is still up to the proxies. Getting that right is an exercise for the reader.
> # Ideally we won't have different CLI/AMI commands/actions, even though this is currently proposing a new Sorcery object. (I wish we hadn't named the module {{res_pjsip_endpoint_identifier_ip.c}}). As such, there might need to be some mushing together of ... things.
> Alternatively, we can rename the module in master. (No more renames in release branches, plz).



--
This message was sent by Atlassian JIRA
(v6.2#6252)