Thank you George. I will pass along the rfc information to those responsible for the other switch.
I missed the match_header addition to Asterisk. Unfortunately, the only header field that seems appropriate is the To header. On a separate box I am now trying to configure the endpoint recognition. Planning on multiple endpoints to the same switch, so I am trying to use the match_header field. I tried programming the match_header with the To: header information. Unfortunately, it didn’t work. Apparently the To header doesn’t work with the match_header field. The Asterisk debug shows the following… DEBUG[2778] res_pjsip_endpoint_identifier_ip.c: SIP message contains header 'To' but value '' does not match value '<sip:2...@xxx.xxx.xxx.xxx>' for endpoint '286' From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of George Joseph Sent: Tuesday, December 19, 2017 7:57 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Is it possible to have two endpoints to the same IP address where one uses IP based authentication and the other requires asterisk to register to that system? On Mon, Dec 18, 2017 at 9:04 AM, Dan Cropp <d...@amtelco.com<mailto:d...@amtelco.com>> wrote: Thanks George I originally didn’t have the 1002@ for the identify. Changed that when things were not working. I changed it back. Unfortunately, the system I am connecting with doesn’t seem to support the line support. Looking at the SIP packets, I see Asterisk send it. Unfortunately, they do not send the line information as part of the INVITE. I checked with some developers of that system and they do not know anything about the line setting. Is there any rfcs I could refer them to? Yeah, I've found that some providers do and some providers don't. https://tools.ietf.org/html/rfc3261#section-19.1 An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI. The identify object also has the capability to match against a specific header and value but it looks like it only tries to match on header if it can't find a match by ip address. Here's some info on it anyway. If you're provider puts something unique and constant in the headers, like a User-Agent string that doesn't change, you can also try using the "match_header" parameter to an identify object. [my_provider] type = identify match_header = User-Agent: Something Unique 1.0.0 endpoint = provider It has to be an exact match though, no wildcards or regular expressions. I opened an issue[1] on separating ip matching from header matching so they can be re-ordered. [1] https://issues.asterisk.org/jira/browse/ASTERISK-27491 From: asterisk-users-boun...@lists.digium.com<mailto:asterisk-users-boun...@lists.digium.com> [mailto:asterisk-users-boun...@lists.digium.com<mailto:asterisk-users-boun...@lists.digium.com>] On Behalf Of George Joseph Sent: Thursday, December 14, 2017 10:59 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Is it possible to have two endpoints to the same IP address where one uses IP based authentication and the other requires asterisk to register to that system? On Wed, Dec 13, 2017 at 10:51 AM, Dan Cropp <d...@amtelco.com<mailto:d...@amtelco.com>> wrote: Currently using PJSIP. First, they want me to get this working with the existing PJSIP configuration, but then setup a second box using chan_sip performing similar work. For PJSIP… I currently have an endpoint configured to a system using IP based authentication. It is configured with a match setting in the endpoint section. All channels coming from that IP address go to this endpoint. They want me to keep this endpoint, but add a new endpoint where we register with them. Existing… [transport1] type = transport bind = 0.0.0.0 protocol = udp [1002] type = aor remove_existing = yes contact = sip:1...@xxx.xxx.xxx.xxx [1002] type = endpoint context = mycontext transport = transport1 accountcode = 6 dtmf_mode = inband device_state_busy_at = 48 force_rport = no identify_by = username from_user = 1002 disallow = all allow = ulaw acl = acl1 [identify112] type = identify endpoint = 1002 match = 1...@xxx.xxx.xxx.xxx<mailto:1...@xxx.xxx.xxx.xxx> Check this first... identify112 probably failed to load because the match parameter can only take an ip address plus an optional netmask, or a hostname. The '1002@' is invalid. I setup the registration and the endpoint. [286] type = aor remove_existing = yes contact = sip:2...@xxx.xxx.xxx.xxx qualify_frequency = 60 [auth8] type = auth username = 286 password = yyyyyyyyyyyyyyy [286] type = endpoint context = mycontext transport = transport1 outbound_auth = auth8 aors = 286 accountcode = 22 dtmf_mode = inband device_state_busy_at = 48 force_rport = no disallow = all allow = ulaw acl = acl1 [registration3] type = registration transport = transport1 client_uri = sip:2...@zzz.zzz.zzz.zzz server_uri = sip:xxx.xxx.xxx.xxx contact_user = 286 outbound_auth = auth8 expiration = 3600 The registration for the second endpoint works fine. However, when I call through the other system for 286, it is failing. For the INVITE from the other switch, the from_user varies depending on who is calling. Asterisk logs report “No matching endpoint found” when it processes the INVITE for 286. I believe the reason INVITEs work for the other channel is because they are programmed to support the match for this IP address. Can anyone offer some suggestions? You may be able to use the 'line and 'endpoint' registration parameters... [registration3] type = registration ... line = yes endpoint = 286 This causes asterisk to put the encoded endpoint name in the outgoing Contact header. If the provider properly echos back Contact parameters when sending responses or new requests, asterisk will use the line parameter to match an endpoint. I'll have to double check but I believe we do that BEFORE checking any identify object for a match. -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- George Joseph Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com<http://www.digium.com/> & www.asterisk.org<http://www.asterisk.org/> -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- George Joseph Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com<http://www.digium.com/> & www.asterisk.org<http://www.asterisk.org/>
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
