[Home]

Summary:ASTERISK-23251: chan_sip - RTP Packetization set in general section not applied when Dialing direct to a SIP URI
Reporter:Jarrod Sears (jsears)Labels:
Date Opened:2014-02-04 09:09:34.000-0600Date Closed:2021-05-03 12:50:32
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling Codecs/General Core/CodecInterface
Versions:1.8.11.1 11.7.0 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS release 6.5 (Final) x64 MySQL Database Dell R320 Server and Dell R210II ServerAttachments:( 0) asterisk-db.sql
( 1) asterisk-g72960-problem-nonrealtime-CLI.txt
( 2) asterisk-g72960-problem-nonrealtime-log.txt
( 3) g729_issue.log
( 4) nonrealtime-extensions.conf
( 5) nonrealtime-sip.conf
( 6) sip.conf
Description:[Edit by Rusty]
Issue is easily reproduced by Dialing or originating calls to any SIP URI, where RTP packetization is specified for a codec allowed in the general section of sip.conf. The codec specified will be used, but the packetization will not be applied. It may happen with peers as well, but I was unable to reproduce it there.
[End edit]

Incoming calls to the server correctly negotiate to g729:60.

The sip.conf is set to:
disallow=all
allow=g729:60

The outbound leg of the server then sends a SIP invite out specifying g729:20.

I've tried setting up specific SIP peers and also using the general codec settings, both experience the same issue.

I have also tried using the SET(SIP_CODEC=G729:60) command, which does not work.

I have tried using the a server with Digium's g729 codec. I've also tried on a server without a g729 codec. Both experience the same issue.

I originally experienced the issue on the 1.8.11.1 (Asterisk 1.8.11-cert1) version that we are using generally for production. I recently installed a new copy of Asterisk 11.7.0 and have the same problem.


Comments:By: Jarrod Sears (jsears) 2014-02-04 09:11:37.743-0600

Full trace per Asterisk Issue Guidelines
By: Jarrod Sears (jsears) 2014-02-04 09:12:49.895-0600

sip.conf used when initially experiencing problem.
By: Rusty Newton (rnewton) 2014-02-10 13:30:35.186-0600

Can't reproduce this in a non-realtime environment, using your sip.conf with an added extension like:

{noformat}
[6001]
type=friend
host=dynamic
secret=6001
context=from-internal
{noformat}

"sip show peer 6001" shows the peers codec as set to allow "g729:60" and that is what I see go out in INVITE messages and 200 OKs (a ptime of 60).

Either this is a misconfiguration, or maybe the issue only occurs with a realtime configuration.

Can you provide:

* a database dump of the sip peer experiencing the issue? Also the output of "sip show peer <peername>" for the peer?
* any /etc/asterisk config files relevant to your realtime configuration
* Your sip peers table schema

You might also want to test for yourself, the same scenario outside of a realtime configuration to make sure I didn't miss something.
By: Jarrod Sears (jsears) 2014-02-10 13:48:13.247-0600

We are not using realtime peers.

We are using realtime for the extensions/dialplan functionality to dynamically create variable IVRs. There is nothing in our /etc/asterisk/extensions.conf file except the switch directly into realtime.

I will try it outside of realtime as a comparison. I'll also try again with a realtime peer configured and show you the sip show peer result.

Thanks
By: Jarrod Sears (jsears) 2014-02-12 10:46:22.680-0600

CLI trace and log file for dialplan not using asterisk realtime.

Realtime sip users were not used in the test and are not used in production. The database is only being used for the dialplan and CDRs
By: Jarrod Sears (jsears) 2014-02-12 10:53:32.550-0600

I included the sip show peer <peer> results in the file "asterisk-g72960-problem-nonrealtime-CLI.txt"

I also included a core show channel <channel> for the call in that file.
By: Jarrod Sears (jsears) 2014-02-13 08:26:14.507-0600

I've added in the requested information
By: Rusty Newton (rnewton) 2014-02-18 20:00:37.680-0600

You dialed direct to a SIP URI instead of using a SIP peer.

{noformat}
-- Executing [999017@default:1] Dial("SIP/10.10.19.28-00000014", "SIP/5555@10.10.4.58,,e") in new stack
{noformat}

{noformat}
hcc-dev1-avp*CLI> sip show peer peerHSRP
{noformat}

You showed the settings for peerHSRP, which unfortunately is not useful, since it wasn't involved in this call.


I noticed that in your description you said

bq. I've tried setting up specific SIP peers and also using the general codec settings, both experience the same issue.

So I went ahead and tried outbound calls, setting the RTP packetization in the general section like you had in your sip.conf and like you were doing in your debug log. That replicated the issue!

I then tested side-by-side, originating calls to peers set with "allow=g729:60" and non-peer SIP URI's like 6003@ipaddress where the general section had "allow=g729:60".

In my tests every call direct to a SIP URI would result in the codec from the general settings being used, but the RTP packetization setting not being applied.

For calls to peers in sip.conf, the RTP packetization was applied, with G729 and with other codecs.. so I wasn't able to reproduce it there.

Since you didn't show the issue with a call to a peer in your debug I wasn't able to gather anything further from that. If you can post debug (with the related sip.conf) for a call to a peer, where the issue occurs, then that would be interesting to see as well. If you do, be sure the debug log has the DEBUG type messages enabled and turned up to level 5. [see the wiki|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information]

However, it looks like there is definitely a bug where RTP packetization is not applied to calls direct to a SIP URI with no peer involved, so I'm going to go ahead and open this up, then modify the summary and description.



By: Jarrod Sears (jsears) 2014-02-19 08:39:12.234-0600

You are completely correct Rusty. I will go ahead and try dialing properly with the SIP peer. My apologies for the confusion.
By: Jarrod Sears (jsears) 2014-02-19 09:16:32.913-0600

Retesting with the Dial command properly using the SIP peer resulted in g729:60 being used.

It is only when dialing directly to an IP address that the codec is not set correctly the the "allow=g729:60" that is in the general section.
By: Rusty Newton (rnewton) 2014-02-19 09:28:16.887-0600

bq. Retesting with the Dial command properly using the SIP peer resulted in g729:60 being used.

It is still "proper" to direct dial a SIP URI when you don't want to use a peer (though in most cases it makes more sense to use a peer), so I still believe you found a bug. I didn't find it documented anywhere that RTP packetization should only be usable through peer dialing.

Thanks for the report and confirming the mode of failure.
By: Sean Bright (seanbright) 2021-05-03 12:50:32.572-0500

I am not able to reproduce this with Asterisk 16 from Git. If you are able to reproduce this on a supported version of Asterisk, please feel free to re-open.