Can not make an outbound

Hi All,

In our environment , we make an outbound call to external number whose phone is setting VoLTE .
When external user answered this call , then the prompt “number-not-answering” and this call was ended .

Our extensions was registed by pjsip .
The trunk with provider was working on chan_sip already .
This issue is specifc to VoLTE only .
We already use G.722 in audio codecs .

I can also see the error message in 487 header

Here is trunk’s outgoing peer details :

My provider told me maybe something wrong with maxptime parameter .
Our maxptime is 150 . Our provider told us this must be set as multiples of 20 of ptime.

Is there something wrong with this parameter ? Do you know how to fix this issue ?

487 should only be used if the session setup is cancelled! It wasn’t.

Hi david551,
Thanks for your reply .
Response 487 shows us unrecognized SIP header .
My provider told me need to delete or modify maxptime parameter .
Our maxptime is 150 . Our provider told us this must be set as multiples of 20 of ptime.

Do you know how to modify or delete it ?


This isn’t the first time this particular quirk has come up [1]. Unfortunately, there isn’t a setting in Asterisk to tell it to strip or otherwise alter the transmitted maxptime header. It will generally always send whatever the value is defined for the negotiated format, which is usually whatever is defined in codec_builtin.c. For g722, that’s currently set to 150.

static struct ast_codec g722 = {
	.name = "g722",
	.description = "G722",
	.sample_rate = 16000,
	.minimum_ms = 10,
	.maximum_ms = 150,
	.default_ms = 20,
	.minimum_bytes = 80,
	.samples_count = g726_samples,
	.get_length = g726_length,
	.smooth = 1,

You could change that value, recompile Asterisk, and see if that alleviate’s your issues with your provider.

[1] Change maxptime parameter

1 Like

Responding to something in a PM.

487 definitely doesn’t mean unrecognised header; RFC 3261 says:

21.4.25 487 Request Terminated

The request was terminated by a BYE or CANCEL request. This response
is never returned for a CANCEL request itself.

As neither BYE nor CANCEL was sent, it is an invalid response by your ITSP’s system.

Hi david551,

I take a screenshot on 487 error .
That shows me “Unrecognised SIP header” .
I am puzzled, why would show this error .

Because your protocol analyser doesn’t understand the header in the response from the ITSP. One would need to see the raw message to go further. However it is the message from the ITSP that contains the unrecognised header, not one from Asterisk, and, as I say, 487 is not consistent with the rest of the session, as logged.