Проверка вызова sip udp ошибка мегафон

[2014-10-13 16:12:17.349] DEBUG[27284]: res_pjsip_endpoint_identifier_user.c:106 username_identify: Could not identify endpoint by username 'eggowaffles'

or

[2014-10-13 16:13:07.201] DEBUG[27507]: res_pjsip_endpoint_identifier_ip.c:113 ip_identify_match_check: Source address 127.0.0.1:5061 does not match identify 'david-ident'

then this is a good indication that the request is being rejected because Asterisk cannot determine which endpoint the incoming request is coming from.

How does Asterisk determine which endpoint a request is coming from? Asterisk uses something called «endpoint identifiers» to determine this. There are three endpoint identifiers bundled with Asterisk: user, ip, and anonymous.

Identify by User

The user endpoint identifier is provided by the res_pjsip_endpoint_identifier_user.so module. If nothing has been explicitly configured with regards to endpoint identification, this endpoint identifier is the one being used. The way it works is to use the user portion of the From header from the incoming SIP request to determine which endpoint the request comes from. Here is an example INVITE:

<--- Received SIP request (541 bytes) from UDP:127.0.0.1:5061 --->
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-27600-1-0
From: breakfast <sip:[email protected]:5061>;tag=27600SIPpTag001
To: sut <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5061
Max-Forwards: 70
Content-Type: application/sdp
Content-Length:   163

v=0
o=user1 53655765 2353687637 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ptime:20

In this example, the URI in the From header is «sip:[email protected]:5061». The user portion is «eggowaffles», so Asterisk attempts to look up an endpoint called «eggowaffles» in its configuration. If such an endpoint is not configured, then the INVITE is rejected by Asterisk. The most common cause of the problem is that the user name referenced in the From header is not the name of a configured endpoint in Asterisk.

But what if you have configured an endpoint called «eggowaffles»? It is possible that there was an error in your configuration, such as an option name that Asterisk does not recognize. If this is the case, then the endpoint may not have been loaded at all. Here are some troubleshooting steps to see if this might be the case:

• From the CLI, issue the «pjsip show endpoints» command. If the endpoint in question does not show up, then there likely was a problem attempting to load the endpoint on startup.

• Go through the logs from Asterisk startup. You may find that there was an error reported that got lost in the rest of the startup messages. For instance, be on the lookout for messages like:

  [2014-10-13 16:25:01.674] ERROR[27771]: config_options.c:710 aco_process_var: Could not find option suitable for category 'eggowaffles' named 'setvar' at line 390 of 
  [2014-10-13 16:25:01.674] ERROR[27771]: res_sorcery_config.c:275 sorcery_config_internal_load: Could not create an object of type 'endpoint' with id 'eggowaffles' from configuration file 'pjsip.conf'

  In this case, I set an endpoint option called «setvar» instead of the appropriate «set_var». The result was that the endpoint was not loaded.

• If you do not see such error messages in the logs, but you do not see the endpoint listed in «pjsip show endpoints», it may be that you forgot to put type = endpoint in your endpoint section. In this case, the entire section would be ignored since Asterisk did not know that this was an endpoint section.

Identify by IP address

Asterisk can also recognize endpoints based on the source IP address of the SIP request. This requires setting up a type = identify section in your configuration to match IP addresses or networks to a specific endpoint. Here are some troubleshooting steps:

• Ensure that res_pjsip_endpoint_identifier_ip.so is loaded and running. From the CLI, run module show like res_pjsip_endpoint_identifier_ip.so. The output should look like the following:

  Module                         Description                              Use Count  Status      Support Level
  res_pjsip_endpoint_identifier_ip.so PJSIP IP endpoint identifier             0          Running              core

• Run the troubleshooting steps from the Identify by User section to ensure that the endpoint you have configured has actually been properly loaded.

• From the Asterisk CLI, run the command pjsip show endpoint <endpoint name>. Below the headers at the top of the output, you should see something like the following:

   Endpoint:  david/6001                                           Unavailable   0 of inf
       InAuth:  david-auth/david
          Aor:  david                                             10
    Transport:  main-transport            udp      0      0  0.0.0.0:5060
     Identify:  10.24.16.36/32

  Notice the bottom line. This states that the endpoint is matched based on the IP address 10.24.16.36. If you do not see such a line for the endpoint that you expect to be matched, then there is likely a configuration error. If the line does appear, then ensure that the IP address listed matches what you expect for the endpoint.

• If you are noticing that Asterisk is matching the incorrect endpoint by IP address, ensure that there are no conflicts in your configuration. Run the pjsip show endpoints command and look for issues such as the following:

   Endpoint:  carol/6000                                           Unavailable   0 of inf
       InAuth:  carol-auth/carol
          Aor:  carol                                             10
    Transport:  main-transport            udp      0      0  0.0.0.0:5060
     Identify:  10.0.0.0/8
  
   Endpoint:  david/6001                                           Unavailable   0 of inf
       InAuth:  david-auth/david
          Aor:  david                                             10
    Transport:  main-transport            udp      0      0  0.0.0.0:5060
     Identify:  10.24.16.36/32

  Notice that if a SIP request arrives from 10.24.16.36, it is ambiguous if the request should be matched to carol or david.

If you run pjsip show endpoint <endpoint name> and do not see an «Identify» line listed, then there is likely a configuration issue somewhere. Here are some common pitfalls

• Ensure that your identify section has type = identify in it. Without this, Asterisk will completely ignore the configuration section.
• Ensure that your identify section has an endpoint option set in it and that the endpoint is spelled correctly.
• Double-check your match lines for common errors:
  • You cannot use FQDNs or hostnames. You must use IP addresses.
  • Ensure that you do not have an invalid netmask (e.g. 10.9.3.4/255.255.255.300, 127.0.0.1/33).
  • Ensure that you have not mixed up /0 and /32 when using CIDR notation.

• If you are using a configuration method other than a config file, ensure that sorcery.conf is configured correctly. Since identify sections are not provided by the base res_pjsip.so module, you must ensure that the configuration resides in the res_pjsip_endpoint_identifier_ip section of sorcery.conf. For example, if you are using dynamic realtime, you might have the following configuration:

  [res_pjsip_endpoint_identifier_ip]
  identify = realtime,ps_endpoint_id_ips

  And then you would need the corresponding config in extconfig.conf:

  [settings]
  ps_endpoint_id_ips => odbc 

Anonymous Identification

Anonymous endpoint identification allows for a specially-named endpoint called «anonymous» to be matched if other endpoint identifiers are not able to determine which endpoint a request originates from. The res_pjsip_endpoint_identifier_anonymous.so module is responsible for matching the incoming request to the anonymous endpoint. If SIP traffic that you expect to be matched to the anonymous endpoint is being rejected, try the following troubleshooting steps:

• Ensure that res_pjsip_endpoint_identifier_anonymous.so is loaded and running. From the Asterisk CLI, run module show like res_pjsip_endpoint_identifier_anonymous.so. The output should look like the following:

  Module                         Description                              Use Count  Status      Support Level
  res_pjsip_endpoint_identifier_anonymous.so PJSIP Anonymous endpoint identifier      0          Running              core

• Ensure that the «anonymous» endpoint has been properly loaded. See the troubleshooting steps in the Identify by User section for more details about how to determine if an endpoint has been loaded.

Authentication is failing

The first thing you should check if you believe that authentication is failing is to ensure that this is the actual problem. Consider the following SIP call from endpoint 200 to Asterisk:

<--- Received SIP request (1053 bytes) from UDP:10.24.16.37:5060 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;branch=z9hG4bKPjQevrxvXqk9Lk5xSW.pzQQb8SAWnJ5Lll
Max-Forwards: 70
From: "200" <sip:[email protected]>;tag=DTD-tYEwFMmbPyu0YWalLQdbEUGSLGN5
To: <sip:[email protected]>
Contact: "200" <sip:[email protected]:5060;ob>
Call-ID: q.TF2SAaX3jn8dtaLTOCuIO8FRyDCsSR
CSeq: 9775 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: Digium D40 1_4_0_0_57389
Content-Type: application/sdp
Content-Length:   430

v=0
o=- 108683760 108683760 IN IP4 10.24.16.37
s=digphn
c=IN IP4 10.24.16.37
t=0 0
a=X-nat:0
m=audio 4046 RTP/AVP 0 8 9 111 18 58 118 58 96
a=rtcp:4047 IN IP4 10.24.16.37
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:18 G729/8000
a=rtpmap:58 L16/16000
a=rtpmap:118 L16/8000
a=rtpmap:58 L16-256/16000
a=sendrecv
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15


<--- Transmitting SIP response (543 bytes) to UDP:10.24.16.37:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;received=10.24.16.37;branch=z9hG4bKPjQevrxvXqk9Lk5xSW.pzQQb8SAWnJ5Lll
Call-ID: q.TF2SAaX3jn8dtaLTOCuIO8FRyDCsSR
From: "200" <sip:[email protected]>;tag=DTD-tYEwFMmbPyu0YWalLQdbEUGSLGN5
To: <sip:[email protected]>;tag=z9hG4bKPjQevrxvXqk9Lk5xSW.pzQQb8SAWnJ5Lll
CSeq: 9775 INVITE
WWW-Authenticate: Digest  realm="asterisk",nonce="1413305427/8dd1b7f56aba97da45754f7052d8a688",opaque="3b9c806b61adf911",algorithm=md5,qop="auth"
Content-Length:  0


<--- Received SIP request (370 bytes) from UDP:10.24.16.37:5060 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;branch=z9hG4bKPjQevrxvXqk9Lk5xSW.pzQQb8SAWnJ5Lll
Max-Forwards: 70
From: "200" <sip:[email protected]>;tag=DTD-tYEwFMmbPyu0YWalLQdbEUGSLGN5
To: <sip:[email protected]>;tag=z9hG4bKPjQevrxvXqk9Lk5xSW.pzQQb8SAWnJ5Lll
Call-ID: q.TF2SAaX3jn8dtaLTOCuIO8FRyDCsSR
CSeq: 9775 ACK
Content-Length:  0


<--- Received SIP request (1343 bytes) from UDP:10.24.16.37:5060 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;branch=z9hG4bKPjCrZnx79augJPtGcTbYlXEs2slZNtwYeC
Max-Forwards: 70
From: "200" <sip:[email protected]>;tag=DTD-tYEwFMmbPyu0YWalLQdbEUGSLGN5
To: <sip:[email protected]>
Contact: "200" <sip:[email protected]:5060;ob>
Call-ID: q.TF2SAaX3jn8dtaLTOCuIO8FRyDCsSR
CSeq: 9776 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: Digium D40 1_4_0_0_57389
Authorization: Digest username="200", realm="asterisk", nonce="1413305427/8dd1b7f56aba97da45754f7052d8a688", uri="sip:[email protected]", response="2da759314909af8507a59cd1b6bc0baa", algorithm=md5, cnonce="-me-qsYc.rGU-I5A6n-Dy8IhCBg9wKe8", opaque="3b9c806b61adf911", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length:   430

v=0
o=- 108683760 108683760 IN IP4 10.24.16.37
s=digphn
c=IN IP4 10.24.16.37
t=0 0
a=X-nat:0
m=audio 4046 RTP/AVP 0 8 9 111 18 58 118 58 96
a=rtcp:4047 IN IP4 10.24.16.37
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:18 G729/8000
a=rtpmap:58 L16/16000
a=rtpmap:118 L16/8000
a=rtpmap:58 L16-256/16000
a=sendrecv
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15


<--- Transmitting SIP response (543 bytes) to UDP:10.24.16.37:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;received=10.24.16.37;branch=z9hG4bKPjCrZnx79augJPtGcTbYlXEs2slZNtwYeC
Call-ID: q.TF2SAaX3jn8dtaLTOCuIO8FRyDCsSR
From: "200" <sip:[email protected]>;tag=DTD-tYEwFMmbPyu0YWalLQdbEUGSLGN5
To: <sip:[email protected]>;tag=z9hG4bKPjCrZnx79augJPtGcTbYlXEs2slZNtwYeC
CSeq: 9776 INVITE
WWW-Authenticate: Digest  realm="asterisk",nonce="1413305427/8dd1b7f56aba97da45754f7052d8a688",opaque="0b5a53ab6484480a",algorithm=md5,qop="auth"
Content-Length:  0


<--- Received SIP request (370 bytes) from UDP:10.24.16.37:5060 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;branch=z9hG4bKPjCrZnx79augJPtGcTbYlXEs2slZNtwYeC
Max-Forwards: 70
From: "200" <sip:[email protected]>;tag=DTD-tYEwFMmbPyu0YWalLQdbEUGSLGN5
To: <sip:[email protected]>;tag=z9hG4bKPjCrZnx79augJPtGcTbYlXEs2slZNtwYeC
Call-ID: q.TF2SAaX3jn8dtaLTOCuIO8FRyDCsSR
CSeq: 9776 ACK
Content-Length:  0

At first glance, it would appear that the incoming call was challenged for authentication, and that 200 then failed to authenticate on the second INVITE sent. The actual problem here is that the endpoint 200 does not exist within Asterisk. Whenever a SIP request arrives and Asterisk cannot match the request to a configured endpoint, Asterisk will respond to the request with a 401 Unauthorized response. The response will contain a WWW-Authenticate header to make it look as though Asterisk is requesting authentication. Since no endpoint was actually matched, the authentication challenge created by Asterisk is just dummy information and is actually impossible to authenticate against.

The reason this is done is to prevent an information leak. Consider an attacker that sends SIP INVITEs to an Asterisk box, each from a different user. If the attacker happens to send a SIP INVITE from a user name that matches an actual endpoint on the system, then Asterisk will respond to that INVITE with an authentication challenge using that endpoint’s authentication credentials. But what happens if the attacker sends a SIP INVITE from a user name that does not match an endpoint on the system? If Asterisk responds differently, then Asterisk has leaked information by responding differently. If Asterisk sends a response that looks the same, though, then the attacker is unable to easily determine what user names are valid for the Asterisk system.

So if you are seeing what appears to be authentication problems, the first thing you should do is to read the Unrecognized Endpoint section above and ensure that the endpoint you think the SIP request is coming from is actually configured properly. If it turns out that the endpoint is configured properly, here are some trouble-shooting steps to ensure that authentication is working as intended:

• Ensure that username and password in the type = auth section are spelled correctly and that they are using the correct case. If you have «Alice» as the username on your phone and «alice» as the username in Asterisk, things will go poorly.
• If you are using the md5_cred option in an auth section, ensure the following:
  • Ensure that you have set auth_type = md5.
  • Ensure that the calculated MD5 sum is composed of username:realm:password
  • Ensure that the calculated MD5 sum did not contain any extraneous whitespace, such as a newline character at the end.
  • Ensure there were no copy-paste errors. An MD5 sum is exactly 32 hexadecimal characters. If the option in your config file contains fewer or greater than 32 characters, or if any of the characters are not hexadecimal characters, then the MD5 sum is invalid.
• Ensure that you have specified a username. Asterisk does not imply a username based on the name of the auth section.
• Ensure that the configured realm is acceptable. In most cases, simple SIP devices like phones will authenticate to whatever realm is presented to them, so you do not need to configure one explicitly. However, if a specific realm is required, be sure it is configured. Be sure that if you are using the md5_cred option that this realm name is used in the calculation of the MD5 sum.
• Ensure that the endpoint that is communicating with Asterisk uses the «Digest» method of authentication and the «md5» algorithm. If they use something else, then Asterisk will not understand and reject the authentication attempt.

Authentication Not Attempted

The opposite problem of authentication failures is that incoming calls are not being challenged for authentication where it would be expected. Asterisk chooses to challenge for authentication if the endpoint from which the request arrives has a configured auth option on it. From the CLI, run the pjsip show endpoint <endpoint name> command. Below the initial headers should be something like the following:

 Endpoint:  david/6001                                           Unavailable   0 of inf
     InAuth:  david-auth/david
        Aor:  david                                             10
  Transport:  main-transport            udp      0      0  0.0.0.0:5060
   Identify:  10.24.16.36/32

Notice the «InAuth» on the second line of output. This shows that the endpoint’s auth is pointing to a configuration section called «david-auth» and that the auth section has a username of «david». If you do not see an «InAuth» specified for the endpoint, then this means that Asterisk does not see that the endpoint is configured for authentication. Check the following:

• Ensure that there is an auth line in your endpoint’s configuration.
• Ensure that the auth that your endpoint is pointing to actually exists. Spelling is important.
• Ensure that the auth that your endpoint is pointing to has type = auth specified in it.

Asterisk cannot find the specified extension

If you are seeing a message like the following on your CLI when you place an incoming call:

[2014-10-14 13:22:45.886] NOTICE[1583]: res_pjsip_session.c:1538 new_invite: Call from '201' (UDP:10.24.18.87:5060) to extension '456789' rejected because extension not found in context 'default'.

then it means that Asterisk was not able to direct the incoming call to an appropriate extension in the dialplan. In the case above, I dialled «456789» on the phone that corresponds with endpoint 201. Endpoint 201 is configured with context = default and the «default» context in my dialplan does not have an extension «456789».

The NOTICE message can be helpful in this case, since it tells what endpoint the call is from, what extension it is looking for, and in what context it is searching. Here are some helpful tips to be sure that calls are being directed where you expect:

• Be sure that the endpoint has the expected context configured. Be sure to check spelling.
• Be sure that the extension being dialled exists in the dialplan. From the Asterisk CLI, run dialplan show <context name> to see the extensions for a particular context. If the extension you are dialing is not listed, then Asterisk does not know about the extension.
  • Ensure that if you have modified extensions.conf recently that you have saved your changes and issued a dialplan reload from the Asterisk CLI.
  • Ensure that the extension being dialled has a 1 priority.
  • Ensure the the extension being dialled is in the expected dialplan context.

ARGH! NAT!

NAT is objectively terrible. Before having a look at this section, have a look at this page to be sure that you understand the options available to help combat the problems NAT can cause.

NAT can adversely affect all areas of SIP calls, but we’ll focus for now on how they can negatively affect the ability to allow for incoming calls to be set up. The most common issues are the following:

• Asterisk routes responses to incoming SIP requests to the wrong location.
• Asterisk gives the far end an unroutable private address to send SIP traffic to during the call.

Asterisk sends traffic to unroutable address

The endpoint option that controls how Asterisk routes responses is force_rport. By default, this option is enabled and causes Asterisk to send responses to the address and port from which the request was received. This default behavior works well when Asterisk is on a different side of a NAT from the device that is calling in. Since Asterisk presumably cannot route responses to the device itself, Asterisk instead routes the response back to where it received the request from.

Asterisk gives unroutable address to device

By default, Asterisk will place its own IP address into Contact headers when responding to SIP requests. This can be a problem if the Asterisk server is not routable from the remote device. The local_net, external_signaling_address, and external_signaling_port transport options can assist in preventing this. By setting these options, Asterisk can detect an address as being a «local» address and replace them with «external» addresses instead.

Outbound Calls

Asterisk says my endpoint does not exist

If you see a message like the following:

[2014-10-14 15:50:50.407] ERROR[2004]: chan_pjsip.c:1767 request: Unable to create PJSIP channel - endpoint 'hammerhead' was not found

then this means that Asterisk thinks the endpoint you are trying to dial does not exist. For troubleshooting tips about how to ensure that endpoints are loaded as expected, check the Identify by User subsection in the Incoming Calls section.

Alternatively, if you see a message like the following:

[2014-10-14 15:55:06.292] ERROR[2578][C-00000000]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("hammerhead", "(null)", ...): Name or service not known
[2014-10-14 15:55:06.292] WARNING[2578][C-00000000]: chan_sip.c:6116 create_addr: No such host: hammerhead
[2014-10-14 15:55:06.292] DEBUG[2578][C-00000000]: chan_sip.c:29587 sip_request_call: Cant create SIP call - target device not registered

or

[2014-10-14 15:55:58.440] WARNING[2700][C-00000000]: channel.c:5946 ast_request: No channel type registered for 'SIP'
[2014-10-14 15:55:58.440] WARNING[2700][C-00000000]: app_dial.c:2431 dial_exec_full: Unable to create channel of type 'SIP' (cause 66 - Channel not implemented)

then it means that your dialplan is referencing «SIP/hammerhead» instead of «PJSIP/hammerhead». Change your dialplan to refer to the correct channel driver, and don’t forget to dialplan reload when you are finished.

Asterisk cannot route my call

If Asterisk is finding your endpoint successfully, it may be that Asterisk has no address information when trying to dial the endpoint. You may see a message like the following:

[2014-10-14 15:58:06.690] WARNING[2743]: res_pjsip/location.c:155 ast_sip_location_retrieve_contact_from_aor_list: Unable to determine contacts from empty aor list
[2014-10-14 15:58:06.690] WARNING[2834][C-00000000]: app_dial.c:2431 dial_exec_full: Unable to create channel of type 'PJSIP' (cause 3 - No route to destination)

If you see this, then the endpoint you are dialling either has no associated address of record (AoR) or the associated AoR does not have any contact URIs bound to it. AoRs are necessary in order to determine the appropriate destination of the call. To see if your endpoint has an associated AoR, run pjsip show endpoint <endpoint name> from the Asterisk CLI. The following is sample output of an endpoint that does have an AoR configured on it:

 Endpoint:  david/6001                                           Unavailable   0 of inf
     InAuth:  david-auth/david
        Aor:  david                                             10
  Transport:  main-transport            udp      0      0  0.0.0.0:5060
   Identify:  10.24.16.36/32

Notice the third line. The endpoint points to the AoR section called «david». If your endpoint does not have an AoR associated with it, this third line will be absent.

If you think you have associated your endpoint with an AoR, but one does not appear in the CLI, then here are some troubleshooting steps:

• Ensure that you have set the aors option on the endpoint. Notice that the option is not aor (there is an ‘s’ at the end).
• Ensure that the AoR pointed to by the aors option exists. Check your spelling!

If those appear to be okay, it may be that there was an error when attempting to load the AoR from configuration. From the Asterisk CLI, run the command pjsip show aor <aor name>. If you see a message like

Unable to find object heman.

Then it means the AoR did not get loaded properly. Here are some troubleshooting steps to ensure your AoR is configured correctly:

• Ensure that your AoR has type = aor set on it.

• Ensure that there were no nonexistent configuration options set. You can check the logs at Asterisk startup to see if there were any options Asterisk did not understand. For instance, you may see something like:

  [2014-10-14 16:16:20.658] ERROR[2939]: config_options.c:710 aco_process_var: Could not find option suitable for category '1000' named 'awesomeness' at line 219 of 
  [2014-10-14 16:16:20.659] ERROR[2939]: res_sorcery_config.c:275 sorcery_config_internal_load: Could not create an object of type 'aor' with id '1000' from configuration file 'pjsip.conf'

  In this case, I tried to set an option called «awesomeness» on the AoR 1000. Since Asterisk did not recognize this option, AoR 1000 was unable to be loaded.
• The contact option can be a pitfall. There is an object type called «contact» that is documented on the wiki, which may make you think that the AoR option should point to the name of a contact object that you have configured. On the contrary, the contact option for an AoR is meant to be a SIP URI. The resulting contact object will be created by Asterisk based on the provided URI. Make sure when setting the contact that you use a full SIP URI and not just an IP address.

Another issue you may encounter is that you have properly configured an AoR on the endpoint but that this particular AoR has no contact URIs bound to it. From the CLI, run the pjsip show aor <aor name> command to see details about the AoR. Here is an example of an AoR that has a contact URI bound to it.

The «Contact:» line shows the URI «sip:[email protected]:5060;ob» is bound to the AoR 201. If the AoR does not have any contacts bound to it, then no Contact lines would appear. The absence of Contact lines can be explained by any of the following:

• If the device is expected to register, then it may be that the device is either not properly configured or that there was a registration failure. See the Inbound Registrations section for details on how to resolve that problem.
• If the device is not intended to register, then the AoR needs to have a contact option set on it. See the previous bulleted list for possible contact-related pitfalls.

ARGH! NAT! (Part 2)

NAT makes babies cry.

For outbound calls, the main NAT issue you are likely to come across is Asterisk publishing an unroutable private address in its Contact header. If this is an issue you are facing, this can be corrected by setting the local_net, external_signaling_address, and external_signaling_port options for the transport you are using when communicating with the endpoint. For more information on how this can be set up, please see this page.

Bridged Calls

Direct media is a feature that allows for media to bypass Asterisk and flow directly between two endpoints. This can save resources on the Asterisk system and allow for more simultaneous calls. The following conditions are required for direct media. If any are not met, then direct media is not possible:

• There must only be two endpoints involved in the call.
• Both endpoints involved in the call must have the direct_media option enabled.
• The call must be a regular person-to-person call. Calls through ConfBridge() and Meetme() cannot use direct media.
• The sets of codecs in use by each endpoint during the call must have a non-empty intersection. In other words, each endpoint must be using at least one codec that the other endpoint is using.
• Any features in Asterisk that manipulate, record, or inject media may not be used. This includes:
  • The Monitor() and Mixmonitor() applications
  • The Chanspy() application
  • The JACK() application
  • The VOLUME() function
  • The TALK_DETECT() function
  • The SPEEX() function
  • The PERIODIC_HOOK() function
  • The ‘L’ option to the Dial() application
  • An ARI snoop
  • A jitter buffer
  • A FAX gateway
• No features that require that Asterisk intercept DTMF may be used. This includes the T, t, K, k, W, w, X, and x options to the Dial() application.
• If either endpoint has the disable_direct_media_on_nat option set, and a possible media NAT is detected, then direct media will not be used. This option is disabled by default, so you would have to explicitly set this option for this to be a problem.
• The two endpoints must be in the same bridge with each other. If the two endpoints are in separate bridges, and those two bridges are connected with one or more local channels, then direct media is not possible.

Double-check that all requirements are met. Unfortunately, Asterisk does not provide much in the way of debug for determining why it has chosen not to use direct media.

Inbound Registrations

For inbound registrations, a lot of the same problems that can happen on inbound calls may occur. Asterisk goes through the same endpoint identification and authentication process as for incoming calls, so if your registrations are failing for those reasons, consult the troubleshooting guide for incoming calls to determine what the problem may be.

If your problem is not solved by looking in those sections, then you may have a problem that relates directly to the act of registering. Before continuing, here is a sample REGISTER request sent to an Asterisk server:

REGISTER sip:10.24.20.249:5060 SIP/2.0
Via: SIP/2.0/UDP 10.24.16.37:5060;rport;branch=z9hG4bKPj.rPtUH-P33vMFd68cLZjQj0QQxdu6mNx
Max-Forwards: 70
From: "200" <sip:[email protected]>;tag=BXs-nct8-XOe7Q7tspK3Vl3iqUa0cmzc
To: "200" <sip:[email protected]>
Call-ID: C0yYQJ8h776wbheBiUEqCin.ZhcBB.tZ
CSeq: 5200 REGISTER
User-Agent: Digium D40 1_4_0_0_57389
Contact: "200" <sip:[email protected]:5060;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length:  0

This REGISTER was sent by the endpoint 200. The URI in the To header is «sip:[email protected]». Asterisk extracts the username portion of this URI to determine the address of record (AoR) that the REGISTER pertains to. In this case, the AoR has the same name as the endpoint, 200. The URI in the Contact header is «sip:[email protected]:5060;ob». The REGISTER request is attempting to bind this contact URI to the AoR. Ultimately, what this means is that when someone requests to reach endpoint 200, Asterisk will check the AoRs associated with the endpoint, and send requests to all contact URIs that have been bound to the AoR. In other words, the REGISTER gives Asterisk the means to locate the endpoint.

You can ensure that your configuration is sane by running the the pjsip show endpoint <endpoint name> CLI command. Part of the output is to show all AoRs associated with a particular endpoint, as well as contact URIs that have been bound to those AoRs. Here is sample output from running pjsip show endpoint 200 on a system where registration has succeeded:

 Endpoint:  200/200                                              Not in use    0 of inf
        Aor:  200                                                1
      Contact:  200/sip:[email protected]:5060;ob                  Unknown               nan
  Transport:  main-transport            udp      0      0  0.0.0.0:5060

This shows that endpoint 200 has AoR 200 associated with it. And you can also see that the contact «sip:[email protected]:5060;ob» has been bound to the AoR.

If running this command shows no AoR, then ensure that the endpoint has the aors option set. Note that the name is aors, not aor.

More likely, the issue will be that an AoR will be listed, but there will be no associated contact. If this is the case, here are some possible troubleshooting steps:

• Ensure that the AoR has actually been loaded. Run the CLI command pjsip show aor <aor name>. If no AoR is displayed, then that means the AoR was not loaded.
  • Ensure that the configuration section has type = aor specified.
  • Ensure that all configuration options specified on the AoR are options that Asterisk recognizes.

• Ensure that the res_pjsip_registrar.so module is loaded and running. Running module show like res_pjsip_registrar.so should show the following:

  Module                         Description                              Use Count  Status      Support Level
  res_pjsip_registrar.so         PJSIP Registrar Support                  0          Running              core

• Ensure that the AoR has a max_contacts value configured on it. If this option is not set, then registration cannot succeed. You will see this message on the CLI:

  [2014-10-16 11:34:07.887] WARNING[2940]: res_pjsip_registrar.c:685 registrar_on_rx_request: AOR '200' has no configured max_contacts. Endpoint '200' unable to register

  Asterisk will transmit a 403 Forbidden in response to the registration attempt.

If you initially have successful registrations but they later start failing, then here are some further troubleshooting steps for you to try:

• If you intend for new registrations to replace old ones, then enable the remove_existing option for the AoR.

• Ensure that if you are attempting to bind multiple contacts to an AoR that the max_contacts for the AoR is large enough. If the max_contacts value is not high enough, you will see the following CLI message:

  [2014-10-16 11:34:07.887] WARNING[2940]: res_pjsip_registrar.c:411 rx_task: Registration attempt from endpoint '200' to AOR '200' will exceed max contacts of 1

  Asterisk will respond to the registration attempt with a 403 Forbidden.

Outbound Registrations

If you are having troubles with outbound registrations and unfamiliar with the mechanics involved, please see this page. It will explain quite a few of the concepts that Asterisk uses and may give you some clues for solving your issue.

If you are still having trouble, here are some troubleshooting steps:

• If Asterisk is not sending an outbound REGISTER at all, then it is likely that there was an error when trying to load the outbound registration.
  • Ensure that the outbound registration has type = registration in it.
  • Ensure that there are no configuration options that Asterisk does not recognize.

• Another reason Asterisk may not be sending an outbound REGISTER is that you do not have a valid SIP URI for your server_uri or client_uri. You may see a message like this on the CLI if this is the case:

  [2014-10-16 12:05:16.064] ERROR[3187]: res_pjsip_outbound_registration.c:724 sip_outbound_registration_regc_alloc: Invalid server URI '[email protected]' specified on outbound registration 'outreg'

  In this case, I left off the initial «sip:» from the URI.

• If your outbound REGISTER receives no response, then you may have misconfigured the server_uri to point somewhere the REGISTER is not meant to be sent.
• If Asterisk has stopped sending REGISTER requests, then either the maximum number of retries has been attempted or the response that Asterisk received from the registrar was considered to be a permanent failure. If you want to get Asterisk to start sending REGISTER requests again after making configuration adjustments, you can do so by running the module reload res_pjsip_registrar.so CLI command.

Inbound Subscriptions

The first thing to acknowledge with inbound subscriptions is that the handling of the inbound SUBSCRIBE messages starts the same as for inbound calls. This means that if you are having troubles where Asterisk does not recognize the endpoint sending the SUBSCRIBE or if authentication is failing, you should check the troubleshooting guide for incoming calls for details on how to solve these issues.

It is also important to ensure that res_pjsip_pubsub.so is loaded and running. This module is the core of all of Asterisk’s handling of subscriptions, and if it is not loaded, then Asterisk will not be able to set up subscriptions properly.

Presence/Dialog Info

A tutorial about subscribing to presence and dialog-info can be found on this page. Reading that page may point you towards how to resolve the issue you are facing.

If you are attempting to subscribe to the presence or dialog event packages, then here are some troubleshooting steps for determining what is going wrong.

• Ensure that the res_pjsip_exten_state.so module is loaded.
• Ensure that the Event header in inbound subscribe messages are one of «presence» or «dialog».
• Ensure all necessary modules are loaded, depending on what values are in the Accept header of inbound SUBSCRIBE requests.
  • Subscriptions that use Accept: application/pidf+xml will need to have res_pjsip_pidf_body_generator.so loaded.
  • Subscriptions that use Accept: application/xpidf+xml will need to have res_pjsip_xpidf_body_generator.so loaded.
  • Subscriptions that use Accept: application/dialog-info+xml will need to have res_pjsip_dialog_info_body_generator.so loaded.

• When subscribing, you may see a message like the following on the CLI:

  [2014-10-16 12:56:58.605] WARNING[3780]: res_pjsip_exten_state.c:337 new_subscribe: Extension blah does not exist or has no associated hint

  The warning message is self-explanatory. If you think you have placed extension «blah» in your extensions.conf file and it contains a hint, then be sure that it exists in the same context as the context option on the endpoint that is attempting to subscribe. Also be sure that if you have recently changed your extensions.conf file that you have saved the changes and run the dialplan reload CLI command.

MWI

If you are attempting to subscribe to the message-summary package, then here are some troubleshooting steps for determining what is going wrong.

• Ensure that the res_pjsip_mwi.so and the res_pjsip_mwi_body_generator.so modules are loaded.
• Ensure that the AoR that the MWI SUBSCRIBE is being sent to has mailboxes configured on it. Note that the option name is mailboxes and not mailbox.

• When subscribing to MWI, you may see a message like the following:

  [2014-10-16 13:06:51.323] NOTICE[3963]: res_pjsip_mwi.c:566 mwi_validate_for_aor: Endpoint '200' already configured for unsolicited MWI for mailbox '200'. Denying MWI subscription to 200

  The most likely cause of something like this is that you have an endpoint and an AoR that both have mailboxes = 200 in your configuration. The endpoint with mailboxes = 200 attempts to subscribe to the AoR that has mailboxes = 200. In this case, since Asterisk is already sending MWI notifications about mailbox 200 to the endpoint, the subscription to the AoR is denied. To fix this, remove the mailboxes option from your endpoint, or configure your device not to attempt to subscribe to MWI.

• Asterisk has multiple ways of having MWI state set, but the most common way is to use app_voicemail that comes with Asterisk. app_voicemail has a requirement that mailbox names must follow the format «[email protected]». If you are using app_voicemail and you configure MWI in pjsip.conf and only provide the mailbox name without a context, then you will not receive MWI updates when the state of the mailbox changes.

Configuration Issues

Can’t create an IPv6 transport

You’ve configured a transport in pjsip.conf to bind to an IPv6 address or block. However, Asterisk fails to create the transport when loading!

If you look into your logs you might messages similar to the following:

[Dec 12 00:58:31] ERROR[10157] config_options.c: Error parsing bind=:: at line 8 of 
[Dec 12 00:58:31] ERROR[10157] res_sorcery_config.c: Could not create an object of type 'transport' with id 'my-ipv6-transport' from configuration file 'pjsip.conf'

The most likely issue is that you have not compiled pjproject with support for IPv6. You can find instructions at PJSIP-pjproject.

1. Список команд для диагностики Asterisk 

2. Статусы IP-телефонов

Команда: asterisk -rx «sip show peers»

3. Статусы SIP-транков

Команда: asterisk -rx «sip show registry» и asterisk -rx «sip show peers»

4. Диагностика

4.1 Не работает исходящая и входящая связь

4.1.1 Проблема: у одного сотрудника

Входящие: не работает у одного сотрудника

Исходящие: не работает у одного сотрудника

Внутренние: не работает у одного сотрудника

Возможные причины

1. Нет регистрации IP-телефона

2. Не указан номер в профиле сотрудника в личном кабинете ВАТС

3. Ошибки при исходящем вызове от коммутатора оператора, предоставляющего номер

Диагностика

1. Проверить регистрацию IP-телефона

asterisk -rx «sip show peers»

Пример: root@MSCelecom1:~# sipteco_vm_peers virt21

Name/username              Host Dyn Nat ACL Port     Status Realtime

101/101                    95.213.157.34 D N 5060     OK (40 ms) Cached RT

102/102                    95.213.157.34 D N 5060     OK (40 ms) Cached RT

103/103                    95.213.157.34 D N 5060     OK (38 ms) Cached RT

104/104                    95.213.157.34 D N 5060     OK (39 ms) Cached RT

74956639622/74956639622    91.218.111.145 N 5060     OK (2 ms)

siptest/siptest            127.0.0.1 D A 5060     OK (1 ms)

6 sip peers [Monitored: 6 online, 0 offline Unmonitored: 0 online, 0 offline]

root@MSCelecom1:~#

Вывод команды показал

4.1.2 Проблема: внешние вызовы не работают, внутренние работают у всех сотрудников

Входящие: не работает у всех сотрудников

Исходящие: не работает у всех сотрудников

Внутренние: работают у всех сотрудников

Возможные причины

1. Недоступен SIP-сервер оператора связи

2. Указан неверный пароль для регистрации на SIP-сервере оператора связи

Диагностика

Шаг №1 Проверить состояние SIP-транков

Команда проверки: asterisk -rx «sip show registry»

Пример:

root@MSCelecom1:~# asterisk -rx «sip show registry»

Name/username              Host Dyn Nat ACL Port     Status Realtime

101/101                    95.213.157.34 D N 5060     OK (56 ms) Cached RT

102/102                    95.213.157.34 D N 5060     OK (40 ms) Cached RT

103/103                    95.213.157.34 D N 5060     OK (39 ms) Cached RT

104/104                    95.213.157.34 D N 5060     OK (40 ms) Cached RT

74956639622/74956639622    91.218.111.145 N 5060     OK (2 ms)

siptest/siptest            127.0.0.1 D A 5060     OK (1 ms)

6 sip peers [Monitored: 6 online, 0 offline Unmonitored: 0 online, 0 offline]

Host                           dnsmgr Username Refresh State                Reg.Time

91.218.111.145:5060            N 74956639622@ 105 Auth. sent          Thu, 07 May 2015 19:01:41

1 SIP registrations.

Вывод команды показал

4.1.3 Проблема: не работают ни внешние ни внутренние вызовы.

Входящие: не работает у всех сотрудников

Исходящие: не работает у всех сотрудников

Внутренние: не работает у всех сотрудников

Возможные причины

1. Проблемы с регистрацией IP-телефонов клиента, возможны проблемы во внутренней сети клиента.

2. Проблемы с сетью датацентра

Диагностика

Шаг №1 Проверка регистрации IP-телефонов клиента

Команда: sipteco_vm_peers VMname

root@MSCelecom1:~# asterisk -rx «sip show peers»

Name/username              Host Dyn Nat ACL Port     Status Realtime

101/101                    95.213.157.34 D N 5060     OK (69 ms) Cached RT

102/102                    95.213.157.34 D N 5060     OK (43 ms) Cached RT

103/103                    95.213.157.34 D N 5060     OK (78 ms) Cached RT

104/104                    95.213.157.34 D N 5060     OK (37 ms) Cached RT

74956639622/74956639622    91.218.111.145 N 5060     OK (2 ms)

siptest/siptest            127.0.0.1 D A 5060     OK (1 ms)

6 sip peers [Monitored: 6 online, 0 offline Unmonitored: 0 online, 0 offline]

Вывод команды показал

Шаг №2 Проверить регистрации телефонов в других доменах.

Если проблема в сети датацентра, в котором установлен сервер ВАТС, то проблема с регистрацией телефонов будет наблюдаться у всех доменов

4.2 Не работает SIP-транк

Возможные причины

1. Не работает SIP-транк оператора, предоставляющего номер

Диагностика

Шаг №1 Проверить регистрацию SIP-транка

Команда: asterisk -rx «sip show registry» 

Пример:

root@MSCelecom1:~# asterisk -rx «sip show registry»

asterisk -rx «sip show peers»

Host                           dnsmgr Username Refresh State                Reg.Time

91.218.111.145:5060            N 74996414100@ 105 Registered           Thu, 23 Apr 2015 15:00:46

1 SIP registrations.

Name/username              Host Dyn Nat ACL Port     Status Realtime

101/101                    (Unspecified) D N 0        UNREACHABLE Cached RT

102/102                    (Unspecified) D N 0        UNKNOWN Cached RT

103/103                    95.213.157.34 D N 5060     OK (489 ms) Cached RT

105/105                    (Unspecified) D N 0        UNREACHABLE Cached RT

106/106                    95.213.157.34 D N 5060     OK (101 ms) Cached RT

74996414100/74996414100    91.218.111.145 N 5060     OK (2 ms)

siptest/siptest            127.0.0.1 D A 5060     OK (1 ms)

7 sip peers [Monitored: 4 online, 3 offline Unmonitored: 0 online, 0 offline]

Вывод команды показал

4.4 Проблемы в сети клиента

Возможные причины

1. Проблемы в локальной сети клиента

2. Проблемы провайдера, предоставляющего интернет

Диагностика

Шаг №1 Проверить отключались ли телефоны клиента от ВАТС

Команда:  sipteco_vm_log_reach <название домена>

Пример:

root@MSCelecom1:~# sipteco_vm_log_reach virt57

[2015-04-23 00:26:04] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (70ms / 2000ms)

[2015-04-23 00:26:05] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (65ms / 2000ms)

[2015-04-23 01:00:08] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (48ms / 2000ms)

[2015-04-23 01:29:09] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (40ms / 2000ms)

[2015-04-23 03:43:59] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (30ms / 2000ms)

[2015-04-23 08:31:47] NOTICE[16674] chan_sip.c: Peer ‘106’ is now UNREACHABLE!  Last qualify: 41

[2015-04-23 09:13:51] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (148ms / 2000ms)

[2015-04-23 09:13:51] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (39ms / 2000ms)

[2015-04-23 09:23:56] NOTICE[16674] chan_sip.c: Peer ‘102’ is now UNREACHABLE!  Last qualify: 46

[2015-04-23 09:24:11] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (149ms / 2000ms)

Вывод команды показал

4.5 Нет регистрации телефона клиента

Возможные причины

1. Неправильные настройки телефона: не указан Outbound proxy, неверный пароль

2. Были произведены изменения в личном кабинете, после которых пропала регистрация телефона

Диагностика и устранение

1. Проверяем регистрацию телефона клиента

Команда: asterisk -rx «sip show peers»

Пример:

root@MSCelecom1:~# asterisk -rx «sip show peers»

Name/username              Host Dyn Nat ACL Port     Status Realtime

801/801                    95.213.157.34 D N 5060     OK (68 ms) Cached RT

802/802                    95.213.157.34 D N 5060     OK (66 ms) Cached RT

803/803                    95.213.157.34 D N 5060     OK (102 ms) Cached RT

804/804                    (Unspecified) D N 0        UNREACHABLE Cached RT

805/805                    95.213.157.34 D N 5060     OK (33 ms) Cached RT

celecom-74995196338/74995  91.218.111.145 N 5060     OK (1 ms)

siptest/siptest            127.0.0.1 D A 5060     OK (1 ms)

7 sip peers [Monitored: 6 online, 1 offline Unmonitored: 0 online, 0 offline]

Вывод команды показал

2. Проверить правильный ли пароль введен в телефон

1. Включаем слежение за логом ВАТС

2. Просим клиента перезагрузить телефон

Слежение за логом

Команда: tail -f /var/log/asterisk/messages

Если пароль неверный, то в логе появится запись:

[2015-04-23 15:42:24] NOTICE[3120] chan_sip.c: Registration from ‘110 <sip:110@ajuraudit.quickfon.ru>’ failed for ‘194.135.75.14’ — Wrong password

Если пароль верный, то в логе появится запись:

root@MSCelecom1:~# sipteco_vm_log_tail virt57

[2015-04-23 15:30:21] VERBOSE[16674] chan_sip.c:        > Saved useragent «Zoiper r30645» for peer 102

[2015-04-23 15:30:21] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (105ms / 2000ms)

3. Если в логе записей нет, то необходимо проверить настройки телефона — поля адрес сервера и Outbound proxy

Для телефонов Grandstream поле SIP-server заполняется полным именем домена virt57.s1.celecom.ru, а Outbound proxy указывается IP адрес

4.6 Клиент вбил неправильный пароль в телефон и не понимает почему не работает

Повторяем действия п. 3.5

4.7 Клиент жалуется на недозвон по направлению

Возможные причины

1. Проблемы у оператора, предоставляющего исходящую связь

Диагностика и устранение

1. Запускаем команду следить за логом  tail -f /var/log/asterisk/messages

2. Делаем тестовый вызов

3. В логах смотрим ошибки при исходящем вызове

Нормальный вызов:

1. [2015-03-25 14:37:55] VERBOSE[6970] app_dial.c:     — Called 79852927460@74992905059

2. [2015-03-25 14:37:55] VERBOSE[6968] app_dial.c:     — Local/79852927460@local-c580;1 is ringing

3. [2015-03-25 14:38:00] VERBOSE[6970] app_dial.c:     — SIP/74992905059-00000015 is making progress passing it to Local/79852927460@local-c580;2

4. [2015-03-25 14:38:00] VERBOSE[6970] app_dial.c:     — SIP/74992905059-00000015 is ringing

5. [2015-03-25 14:38:00] VERBOSE[6968] app_dial.c:     — Local/79852927460@local-c580;1 is ringing

6. [2015-03-25 14:38:04] VERBOSE[6970] app_dial.c:     — SIP/74992905059-00000015 answered Local/79852927460@local-c580;2

7. [2015-03-25 14:38:04] VERBOSE[6968] app_dial.c:     — Local/79852927460@local-c580;1 stopped sounds

8. [2015-03-25 14:38:04] VERBOSE[6968] app_dial.c:     — Local/79852927460@local-c580;1 answered SIP/74992905059-00000014

Строка №1 — звоним по номеру 79852927460 через канал SIP транк 74992905059

Строка №8  — ответ вызываемой стороны

Проблемный вызов

Закончится ошибкой SIP

4.8 Клиент жалуется на отсутствие связи конкретных внутренних номеров

Возможные причины

1. Как правило это связано с тем, что IP-телефоны клиента не зарегистрированы

Диагностика и устранение

asterisk -rx «sip show peers» 

Name/username              Host Dyn Nat ACL Port     Status Realtime

100/100                    95.213.157.34 D N 5060     OK (35 ms) Cached RT

101/101                    95.213.157.34 D N 5060     OK (34 ms) Cached RT

102/102                    95.213.157.34 D N 5060     OK (35 ms) Cached RT

103/103                    95.213.157.34 D N 5060     OK (35 ms) Cached RT

106/106                    95.213.157.34 D N 5060     OK (17 ms) Cached RT

107/107                    95.213.157.34 D N 5060     OK (16 ms) Cached RT

74995196141/74995196141    91.218.111.145 N 5060     OK (2 ms)

siptest/siptest            127.0.0.1 D A 5060     OK (1 ms)

Вывод: сейчас все телефоны зарегистрированы

cat /var/log/asterisk/messages|grep -i reach

[2015-03-25 08:58:10] NOTICE[1988] chan_sip.c: Peer ‘106’ is now UNREACHABLE!  Last qualify: 17

[2015-03-25 08:58:12] NOTICE[1988] chan_sip.c: Peer ‘107’ is now UNREACHABLE!  Last qualify: 16

[2015-03-25 13:21:58] NOTICE[1988] chan_sip.c: Peer ‘106’ is now Reachable. (65ms / 2000ms)

[2015-03-25 13:21:59] NOTICE[1988] chan_sip.c: Peer ‘107’ is now Reachable. (104ms / 2000ms)

[2015-03-25 13:46:03] NOTICE[1988] chan_sip.c: Peer ‘106’ is now UNREACHABLE!  Last qualify: 17

[2015-03-25 13:46:05] NOTICE[1988] chan_sip.c: Peer ‘107’ is now UNREACHABLE!  Last qualify: 18

[2015-03-25 13:47:23] NOTICE[1988] chan_sip.c: Peer ‘106’ is now Reachable. (154ms / 2000ms)

Вывод: в 08:58, 13:21, 13:46, 13:47 телефоны 106 и 107 отключались от АТС и не могли принимать входящие вызовы

4.9 Не работает перевод вызовов на внутренние номера

Возможные причины

1. IP-телефоны настроены на передачу DTMF в формате отличном от RFC2833

Решение:

1. Настроить формат передачи DTMF в RFC2833

4.10 Не работает переадресация

Возможные причины:

1. Проблемы с исходящей связью

Решение:

1. Диагностика проблемы аналогично разделу 6.1

4.11 Не работает последовательность отработки входящих вызовов

Возможные причины

1. Неверно настроена входящая маршрутизация

Решение

1. Запустить слежение за логом tail -f /var/log/asterisk/messages

2. Сделать тестовый входящий вызов и посмотреть последовательность отработки входящих вызовов

3. Отредактировать маршруты в личном кабинете

4.13 Клиент жалуется на плохую связь, пропадение голоса

Возможные причины

1. Проблемы в локальной сети клиента

2. Проблемы провайдера, предоставляющего интернет

Диагностика

Шаг №1 Послушать запись разговора в которой проблема

Если на записи слышны потери:

1. Вы слышите потери голоса нашего клиента — проблема в локальной сети клиента. Идем на шаг №2

2. Клиента вы слышите хорошо, но того с кем он разговаривает слышно плохо — проблемы на стороне оператора связи, который предоставляет городской номер. Сдаем заявку этому оператору

Если на записи потери не слышны потери в локальной сети клиента. Идем на шаг №2

Шаг №2 Проверить отключались ли телефоны клиента 

Команда:  cat /var/log/asterisk/messages |grep -I reach

Пример:

root@MSCelecom1:~# cat /var/log/asterisk/messages |grep -I reach

[2015-04-23 00:26:04] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (70ms / 2000ms)

[2015-04-23 00:26:05] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (65ms / 2000ms)

[2015-04-23 01:00:08] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (48ms / 2000ms)

[2015-04-23 01:29:09] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (40ms / 2000ms)

[2015-04-23 03:43:59] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (30ms / 2000ms)

[2015-04-23 08:31:47] NOTICE[16674] chan_sip.c: Peer ‘106’ is now UNREACHABLE!  Last qualify: 41

[2015-04-23 09:13:51] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (148ms / 2000ms)

[2015-04-23 09:13:51] NOTICE[16674] chan_sip.c: Peer ‘106’ is now Reachable. (39ms / 2000ms)

[2015-04-23 09:23:56] NOTICE[16674] chan_sip.c: Peer ‘102’ is now UNREACHABLE!  Last qualify: 46

[2015-04-23 09:24:11] NOTICE[16674] chan_sip.c: Peer ‘102’ is now Reachable. (149ms / 2000ms)

Вывод команды показал

Читайте другие страницы сайта.

Introduction[]

This article displays SIP error codes and a definition of such codes

Categories of SIP messages[]

• 1xx is ‘Informational’
• 2xx is ‘Success’
• 3xx is a ‘Redirection’
• 4xx is a ‘Client Error’
• 5xx is a ‘Server Error’
• 6xx is a ‘Global Failure’

1xx—Provisional Responses[]

As mentioned earlier, a 1xx SIP response code can be sent at anytime while a connection is being established. Some of the regularly received codes are

2xx—Successful Responses[]

The 2xx response codes are used to indicate that a SIP request has been successfully processed. You’ll typically see the following versions:

3xx—Redirection Responses[]

3xx responses give information about the user’s new location, or about alternative services that might be able to satisfy the call.

4xx—Client Failure Responses[]

4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.

5xx—Server Failure Responses[]

5xx responses relate to server error issues and are mostly generated by the likes of proxy servers, location servers, and redirect servers. You’ll be familiar with some of these: — 500 Server Internal Error — 501 Not Implemented — 502 Bad Gateway — 503 Service Unavailable — 504 Server Time-Out

6xx—Global Failure Responses[]

Finally, the 6xx response codes relate to Global Error issues. They include: — 600 Busy Everywhere — 603 Decline — 604 Does Not Exist Anywhere — 606 Not Acceptable

Introduction[]

This article displays SIP error codes and a definition of such codes

Categories of SIP messages[]

• 1xx is ‘Informational’
• 2xx is ‘Success’
• 3xx is a ‘Redirection’
• 4xx is a ‘Client Error’
• 5xx is a ‘Server Error’
• 6xx is a ‘Global Failure’

1xx—Provisional Responses[]

As mentioned earlier, a 1xx SIP response code can be sent at anytime while a connection is being established. Some of the regularly received codes are

2xx—Successful Responses[]

The 2xx response codes are used to indicate that a SIP request has been successfully processed. You’ll typically see the following versions:

3xx—Redirection Responses[]

3xx responses give information about the user’s new location, or about alternative services that might be able to satisfy the call.

4xx—Client Failure Responses[]

4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.

5xx—Server Failure Responses[]

5xx responses relate to server error issues and are mostly generated by the likes of proxy servers, location servers, and redirect servers. You’ll be familiar with some of these: — 500 Server Internal Error — 501 Not Implemented — 502 Bad Gateway — 503 Service Unavailable — 504 Server Time-Out

6xx—Global Failure Responses[]

Finally, the 6xx response codes relate to Global Error issues. They include: — 600 Busy Everywhere — 603 Decline — 604 Does Not Exist Anywhere — 606 Not Acceptable

Читайте другие страницы сайта.

Модератор: april22

Вернуться в Вопросы новичков

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8

У меня мобильный интернет от «Мегафона». Когда сёрфил по интернету несколько раз заметил, как вместо «404» ошибки от сервера сайта, на котором я находился появлялась «404» от «Мегафон» с предложением разных услуг.

Я заморочился и нагенерировал много искусственных страниц, затем запустил парсер этих страниц, и эта «404» снова появилась. На 100 искусственных URL приходится 1 «404» от «Мегафона». Зачем «Мегафон» «перехватывает» именно эти страницы и имеет ли он на это право?

Скриншот на всякий случай:

Помогите пожалуйста. Настраиваю связку Avaya IPO 500 + Microsoft Lync Server.
При попытке позвонить на внешний номер Avaya показывает следующее:
670286mS SIP Rx: TCP 192.168.0.94:52740 -> 192.168.0.7:5060
INVITE sip:98916xxx0379@192.168.0.7;user=phone SIP/2.0
FROM: «Ð›Ð¸Ñ‚винский Андрей Андреевич»<sip:4957872992@lync.xxx.ru;user=phone>;epid=F182909C87;tag=fa8db7831f
TO: <sip:98916xxx0379@192.168.0.7;user=phone>
CSEQ: 34 INVITE
CALL-ID: c731b9e9-1a15-4c2f-935e-8c3499717c97
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.0.94:52740;branch=z9hG4bK62ddc3c0
CONTACT: <sip:lync.xxx.ru:5060;transport=Tcp;maddr=192.168.0.94;ms-opaque=95af430f822a0cc5>
CONTENT-LENGTH: 338
SUPPORTED: 100rel
USER-AGENT: RTCC/4.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
ALLOW: ACK
Allow: CANCEL,BYE,INVITE,PRACK,UPDATE

v=0
o=- 5 1 IN IP4 192.168.0.94
s=session
c=IN IP4 192.168.0.94
b=CT:1000
t=0 0
m=audio 55650 RTP/AVP 97 101 13 0 8
c=IN IP4 192.168.0.94
a=rtcp:55651
a=label:Audio
a=sendrecv
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
670287mS Sip: SipTCPUser forwarding to Trunk!!!
670289mS Sip: SIPDialog TXN : Decoding of message Succeded 1
670290mS Sip: Create Incoming EndPoint voip
670290mS CMCallEvt: 0.1027.0 -1 BaseEP: NEW CMEndpoint f569869c TOTAL NOW=3 CALL_LIST=1
670290mS PRN: Created MH f569796c parent 0.1027.0 -1 SIPTrunk Endpoint
670290mS Sip: License, Valid 1, Available 4, Consumed 0
670291mS Sip: CheckLineMonitors on SIP Endpoint — KEY & LAMP for SIP Trunk!
670291mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) ExtractCallIdFrom Message: Call Id value c731b9e9-1a15-4c2f-935e-8c3499717c97
670291mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) ExtractCallerFromMessage: From Tag is fa8db7831f
670292mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) No Accept Header
670293mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) SendSIPResponse: INVITE SENT TO 192.168.0.94 5060
670293mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) Sending code 100 to method INVITE
670293mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) SendSIPResponse, Number of Tag Count, 0
670294mS SIP Tx: TCP 192.168.0.7:5060 -> 192.168.0.94:5060
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.0.94:52740;branch=z9hG4bK62ddc3c0
From: «Ð›Ð¸Ñ‚винский Андрей Андреевич» <sip:4957872992@lync.xxx.ru;user=phone>;tag=fa8db7831f;epid=F182909C87
To: <sip:98916xxx0379@192.168.0.7;user=phone>;tag=8ddc5a2387ec6168
Call-ID: c731b9e9-1a15-4c2f-935e-8c3499717c97
CSeq: 34 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO
Content-Length: 0

670294mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) INVITE Received ep 18.1027.1 -1 SIPTrunk Endpoint(f569869c), dialog f5697a78
670295mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) UpdateSIPCallState SIPDialog::INITIAL(0) -> SIPDialog::INVITE_RCVD(10)
670295mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) Present Call, no match (98916xxx0379) from URI in To header.
670295mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) Present Call, no match from URI in Request Line
670295mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) SendSIPResponse: INVITE SENT TO 192.168.0.94 5060
670296mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) Sending code 404 to method INVITE
670296mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) SendSIPResponse, Number of Tag Count, 1
670296mS SIP Tx: TCP 192.168.0.7:5060 -> 192.168.0.94:5060
SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 192.168.0.94:52740;branch=z9hG4bK62ddc3c0
From: «Ð›Ð¸Ñ‚винский Андрей Андреевич» <sip:4957872992@lync.xxx.ru;user=phone>;tag=fa8db7831f;epid=F182909C87
To: <sip:98916xxx0379@192.168.0.7;user=phone>;tag=8ddc5a2387ec6168
Call-ID: c731b9e9-1a15-4c2f-935e-8c3499717c97
CSeq: 34 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO
Content-Length: 0

670297mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) UpdateSIPCallState SIPDialog::INVITE_RCVD(10) -> SIPDialog::FINAL(40)
670297mS Sip: SIP Line (18): Freed Txn Key 2016
670301mS RES: Thu 15/3/2012 15:43:52 FreeMem=75513804(2) CMMsg=4 (4) Buff=200 960 1000 7424 5 Links=20729
670301mS RES2: RTEngine=0, CMRTEngine=0, Timer=54, Poll=0, Ready=1, CMReady=0, CMQueue=0, VPNNQueue=0
670303mS SIP Rx: TCP 192.168.0.94:52740 -> 192.168.0.7:5060
ACK sip:98916xxx0379@192.168.0.7;user=phone SIP/2.0
FROM: «Ð›Ð¸Ñ‚винский Андрей Андреевич»<sip:4957872992@lync.norbit.ru;user=phone>;tag=fa8db7831f;epid=F182909C87
TO: <sip:98916xxx0379@192.168.0.7;user=phone>;tag=8ddc5a2387ec6168
CSEQ: 34 ACK
CALL-ID: c731b9e9-1a15-4c2f-935e-8c3499717c97
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.0.94:52740;branch=z9hG4bK62ddc3c0
CONTENT-LENGTH: 0

670303mS Sip: SipTCPUser forwarding to Trunk!!!
670304mS Sip: SIPDialog TXN : Decoding of message Succeded 1
670305mS Sip: Find End Point 18.1027.1 -1 SIPTrunk Endpoint (f569869c) Sip CallId c731b9e9-1a15-4c2f-935e-8c3499717c97
670305mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) Process SIP request dialog f5697a78, method ACK in state SIPDialog::FINAL(40)
671306mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) EPTerminationTimeout, about to delete endpoint
671306mS Sip: SipTCPUser has 4 dialog open
671306mS Sip: 18.1027.1 -1 SIPTrunk Endpoint(f5697a78) SIPDialog destructor … f5697a78
671306mS CMCallEvt: 18.1027.1 -1 SIPTrunk Endpoint: StateChange: END=X CMCSIdle->CMCSDelete
671306mS Sip: ~SipTrunkEndpoint 18.1027.1 -1 SIPTrunk Endpoint
671307mS PRN: Destroyed MH f569796c parent unknown
671307mS CMTARGET: 18.1027.1 -1 BaseEP: ~CMTargetHandler
671308mS CMCallEvt: 18.1027.1 -1 BaseEP: DELETE CMEndpoint f569869c TOTAL NOW=2 CALL_LIST=1
677005mS PRN: ConferDSP is alive

Во вложенных файлах настройки SIP на Avaya. Заранее спасибо за помощь.

Ошибка 404 говорит о том, что вызываемый абонент не найден или нет такого sip абонента.

Сообщение 404 Not Found означает, что шлюз не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI. При этом известно что абонент с набираемым номером присутствует в списке абонентов устройства. Наиболее распространены и часто встречаются две причины возникновения такой проблемы:

• Номер абонента и IP адрес в поле Request-URI сообщения INVITE указаны верно, но неверно указан UDP порт для приема сигнализации по протоколу SIP для данного абонента. Решить проблему может корректировка конфигурации клиента, отправляющего запрос INVITE, в которой требуется изменить номер порта UDP для отправки сообщений SIP при вызове этого абонента или скорректировать номер UDP порта абонента на шлюзе в индивидуальных настройках абонентского порта.
• Номер абонента в поле Request-URI сообщения INVITE указан верно, но указанный SIP-домен отличается от того, в котором в действительности находится абонент. Эта проблема возникает при работе за NAT. В этом случае реальный адрес абонента и его адрес сформированный при регистрации на сервере регистрации будут отличаться. Для решения такой проблемы, на шлюзе требуется указать в конфигурации публичный IP адрес (IP адрес натирующего устройства в случае если IP адрес задан статически) или задать IP адрес STUN сервера расположенного за натирующим устройством (в случае если IP адрес натирующего устройства динамичен).

Принцип работы устройства при использовании публичного IP адреса и STUN описано здесь.