[asterisk-bugs] [JIRA] (ASTERISK-28139) RTP Stream Incorrect Payload Type Causes Asterisk To Drop Calls

[Michael L. Young (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=245300#comment-245300 ] 

Michael L. Young commented on ASTERISK-28139:
---------------------------------------------

I am wondering if this is the same issue that we were having... we were able to solve it by setting in pjsip.conf:

asymmetric_rtp_codec=yes

Our configuration only allows g711 as well.  From my investigation, the codec is negotiated properly but for whatever reason, the media server (only one was doing this, not sure if it was Verizon since the provider we use has multiple providers it uses for the media) would send at the very beginning of the call being answered a packet as g729.  When Asterisk received this, it automatically tried to change to that codec.  Since we do not have any g729 licenses, the call would fail because it could not use g729.

To bypass that code which switches to the packet that it received, turning on asymmetric_rtp_codec is skipping the entire if conditional statement and we proceed without any issues.

https://github.com/asterisk/asterisk/blob/fcd8e9d6ef6cad66ba3bfe58540aa1cdb372fc2c/channels/chan_pjsip.c#L834
{code:title=chan_pjsip.c}
        /*
	 * Asymmetric RTP only has one native format set at a time.
	 * Therefore we need to update the native format to the current
	 * raw read format BEFORE the native format check
	 */
	if (!session->endpoint->asymmetric_rtp_codec &&
		ast_format_cmp(ast_channel_rawwriteformat(ast), f->subclass.format) == AST_FORMAT_CMP_NOT_EQUAL) {
		struct ast_format_cap *caps;

		/* For maximum compatibility we ensure that the formats match that of the received media */
		ast_debug(1, "Oooh, got a frame with format of %s on channel '%s' when we're sending '%s', switching to match\n",
			ast_format_get_name(f->subclass.format), ast_channel_name(ast),
			ast_format_get_name(ast_channel_rawwriteformat(ast)));

		caps = ast_format_cap_alloc(AST_FORMAT_CAP_FLAG_DEFAULT);
		if (caps) {
			ast_format_cap_append_from_cap(caps, ast_channel_nativeformats(ast), AST_MEDIA_TYPE_UNKNOWN);
			ast_format_cap_remove_by_type(caps, AST_MEDIA_TYPE_AUDIO);
			ast_format_cap_append(caps, f->subclass.format, 0);
			ast_channel_nativeformats_set(ast, caps);
			ao2_ref(caps, -1);
		}

		ast_set_write_format_path(ast, ast_channel_writeformat(ast), f->subclass.format);
		ast_set_read_format_path(ast, ast_channel_readformat(ast), f->subclass.format);

		if (ast_channel_is_bridged(ast)) {
			ast_channel_set_unbridged_nolock(ast, 1);
		}
	}
{code}

I haven't had time yet to look further into the code and see if this is by design or if it is actually a bug or rather error in the logic.

> RTP Stream Incorrect Payload Type Causes Asterisk To Drop Calls
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-28139
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28139
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 16.0.0
>         Environment: Debian 9.5
>            Reporter: Paul Brooks
>            Assignee: Paul Brooks
>
> I represent a company offering hosted PBX service to various small businesses. We use Asterisk as our host. Last week we upgraded our Asterisk 14.6.2 server to the new Asterisk 16.0.0. We began to see many calls dropping upon answer. After a thorough investigation we had to roll back to the older version of Asterisk to alleviate the problem. Hopefully this issue can be recognized as a bug and corrected in a near-future version of Asterisk 16 so that we can attempt to upgrade to Asterisk 16 once again.
> The cause of the dropped calls turned out to be Asterisk's behavior in handling packet(s) received with the wrong payload type in the audio stream. One of our underlying carriers is Verizon Wholesale, and they deliver calls to us originated as either toll free or local dialed. Our dropped calls always involved Verizon's channels so we opened a ticket with them. Their support team helped us pinpoint the source of the dropped call problem.
> Our interconnection to Verizon is somewhat complex: they deliver calls to us over any one of 14 endpoints (in some seemingly random, quasi-round robin way). Every time a call is dropped by Asterisk 16, Asterisk logs errors similar to this,
> WARNING[11710][C-0000185e]: translate.c:485 ast_translator_build_path: No translator path: (ending codec is not valid)
> WARNING[11710][C-0000185e]: translate.c:485 ast_translator_build_path: No translator path: (starting codec is not valid)
> WARNING[11723][C-0000185e]: channel.c:5578 set_format: Unable to find a codec translation path: (g729) -> (ulaw)
> Our Asterisk is configured with all endpoints allowing ulaw only. Verizon's INVITE messages always offer media as 18 0 8 101 (g729, ulaw, alaw). Examination of SIP messages related to captured dropped calls between Verizon and our Asterisk shows normal negotiation. When the call is answered by Asterisk, it sends Verizon an answer message specifying type 0 for the media (ulaw/g711). But in a high percentage of the calls, Verizon will send a single g729 packet at the front of the resulting g711 stream. Verizon admitted to us that this is an old bug present in some of their DSP cards. They assert that they have an open case with their vendor involved but don't expect a fix anytime soon. Further, they point out that, "As a SIP wholesale connection, [Verizon will] interface [us] not only with Verizon PSTN gateways, but other wholesalers, retail customers, DSCIP carriers etc . . . [Verizon] cannot police the integrity of every RTP stream sent to [our] endpoint."
> Verizon pointed out to us further that RFC 3550 is pretty clear on the handling of incorrect payload types: "A receiver MUST ignore packets with payload types that it does not understand."
> So, from my perspective, assuming the RFC does say that Asterisk should be ignoring rtp packets containing the incorrect payload type, I must ask, why is Asterisk dropping the call when it encounters such a packet? It must be a bug. So I am reporting it as such. I must emphasize here that our previous versions of Asterisk that ran the same Verizon endpoints did not experience this dropped call issue.
> My hunch is that this undesirable behavior made its way into Asterisk beginning with version 15 when its framework for handling audio streams was significantly modified. It is well documented that prior to version 15, Asterisk had a "very loose" stream implementation that used a single pipe, and beginning with version 15, the framework was tightened up to allow for multiple streams for a single call. Here are a couple references on this topic: https://wiki.asterisk.org/wiki/display/AST/New+in+15, https://blogs.asterisk.org/2017/09/20/asterisk-15-multi-stream-media-sfu/
> I suspect now that Asterisk 15,16 allows multiple streams for a single call, it is being confused into thinking there is a simultaneous g729 stream alongside the g711 stream when it encounters the invalid g729 packet at the beginning of Verizon's g711 stream (I performed a packet capture on a live dropped call and indeed I saw the g729 packet at the beginning of the g711 stream).
> I believe Asterisk's implementation of this multi-stream concept needs to somehow be tweaked to recognize when a call has negotiated only a single media stream and therefore be prepared to discard any invalid packets that pop up into a live media stream. It appears that Asterisk 14 and prior had no trouble ignoring such invalid packets. Asterisk's 16 behavior of abruptly hanging up a call whenever it encounters an invalid media packets seems untenable.



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