[Home]

Summary:ASTERISK-00195: G729 (and other codecs?) cannot be specified on a per-peer basis
Reporter:John Todd (jtodd)Labels:
Date Opened:2003-08-29 15:24:48Date Closed:2011-06-07 14:05:06
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:For inbound SIP calls, Asterisk seems to not be honoring the "disallow=" and "allow=" on a per peer basis in sip.conf.  However, those same lines do seem to be honored in the [general] stanza in sip.conf on a global basis for UA->*.  Additionally, calls from *->SIP-UA seem to honor the per-peer settings.   This essentially almost quadruples bandwidth on the  SIP<->UA network, since most of the calls in this situation are originated from the SIP devices.

****** ADDITIONAL INFORMATION ******

[5054441234]  
disallow=all
allow=g729  
username=5054441234
type=friend
secret=rugrats
host=dynamic
context=generic-customer1
nat=1
canreinvite=no

With the above peer settings, I would expect any inbound calls from that SIP device to be refused unless they were offering g729 as a codec, and then the connection would actually use g729.  However, that is not the case - calls keep coming in, using ULAW (the preference on the device, a Cisco 7960.)  

Outbound calls with the per-peer restrictions seem to work correctly, meaning that RTP sessions between Asterisk and the device communicate via G729 (at least, "sip show channels" indicates that this is the case.)

If I configure "disallow=all" "allow=g729" in the [general] stanza, inbound and outbound calls work as expected, so perhaps this is a parsing problem in the peer stanza sections?

Perhaps I am mis-understanding how the "allow=" and "disallow=" lines are supposed to function, but I clearly recall using these to regulate inbound codec use, so I suspect this is a bug.

My version: Asterisk CVS-08/28/03-23:27:10


A "sip debug" of a call from the Cisco to/through the Asterisk server, with the per-peer G729 restrictions in place:

voip1*CLI>
voip1*CLI>
voip1*CLI>
Sip read:  
INVITE sip:14109850123@146.145.155.162 SIP/2.0
Via: SIP/2.0/UDP 68.38.121.217:5060
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 101 INVITE
User-Agent: CSCO/4
Contact: <sip:5054441234@68.38.121.217:5060>
Expires: 180
Content-Type: application/sdp
Content-Length: 248
Accept: application/sdp
Remote-Party-ID: "5054441234" <sip:5054441234@68.38.121.217>;party=calling;id-type=subscriber;privacy=off;screen=no

v=0
o=Cisco-SIPUA 26975 6936 IN IP4 68.38.121.217
s=SIP Call
c=IN IP4 68.38.121.217
t=0 0
m=audio 21362 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

13 headers, 11 lines
Using latest request as basis request
Sending to 68.38.121.217 : 5060 (non-NAT)
Found audio format UNKN                                                                                                        
Found audio format UNKN
Found audio format ALAW
Found audio format UNKN
Found description format G729
Found description format PCMU
Found description format PCMA
Found description format telephone-event
Capabilities: us - 524302, them - 268/0, combined - 12
Non-codec capabilities: us - 1, them - 1, combined - 1
Reliably Transmitting (NAT):
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 68.38.121.217:5060;received=68.38.121.217
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as5050016d
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact:
Proxy-Authenticate: Digest realm="asterisk", nonce="1141eae2"
Content-Length: 0


to 68.38.121.217:15061
Sip read:  
ACK sip:14109850123@146.145.155.162 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.90:5060
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as5050016d
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 101 ACK
Content-Length: 0


7 headers, 0 lines
Sip read:  
INVITE sip:14109850123@146.145.155.162 SIP/2.0
Via: SIP/2.0/UDP 68.38.121.217:5060
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 102 INVITE
User-Agent: CSCO/4
Contact: <sip:5054441234@68.38.121.217:5060>
Proxy-Authorization: Digest username="5054441234",realm="asterisk",uri="sip:146.145.155.162",response="21b810792ab3858c670675d1c182e2ac",nonce="1141eae2",algorithm=md5
Expires: 180
Content-Type: application/sdp
Content-Length: 248
Remote-Party-ID: "5054441234" <sip:5054441234@68.38.121.217>;party=calling;id-type=subscriber;privacy=off;screen=no

v=0
o=Cisco-SIPUA 26975 6936 IN IP4 68.38.121.217
s=SIP Call
c=IN IP4 68.38.121.217
t=0 0
m=audio 21362 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

13 headers, 11 lines
Using latest request as basis request
Sending to 68.38.121.217 : 5060 (NAT)
Found audio format UNKN
Found audio format UNKN
Found audio format ALAW
Found audio format UNKN
Found description format G729
Found description format PCMU
Found description format PCMA
Found description format telephone-event
Capabilities: us - 524302, them - 268/0, combined - 12
Non-codec capabilities: us - 1, them - 1, combined - 1
Looking for 14109850123 in generic-customer1
list_route: hop: <sip:5054441234@68.38.121.217:5060>
Transmitting (NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 68.38.121.217:5060;received=68.38.121.217
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as0445b58c
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:14109850123@146.145.155.162>
Content-Length: 0


to 68.38.121.217:15061
   -- Executing GotoIf("SIP/5054441234-a378", "0?2:generic-customer2|14109850123|1") in new stack
   -- Goto (generic-customer2,14109850123,1)
   -- Executing SetCallerID("SIP/5054441234-a378", "6092422211") in new stack
   -- Executing Dial("SIP/5054441234-a378", "IAX2/compro2@coloco1/14109850123") in new stack
   -- Called compro2@coloco1/14109850123
   -- Call accepted by 199.34.53.108 (format ULAW)
   -- Format for call is ULAW
We're at 146.145.155.162 port 17752
Answering with capability 4
Answering with capability 8
Answering with non-codec capability 1
Transmitting (NAT):
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 68.38.121.217:5060;received=68.38.121.217
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as0445b58c
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:14109850123@146.145.155.162>
Content-Type: application/sdp
Content-Length: 219

v=0
o=root 11910 11910 IN IP4 146.145.155.162
s=session
c=IN IP4 146.145.155.162
t=0 0
m=audio 17752 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

to 68.38.121.217:15061
   -- IAX2[coloco1]/16384 is ringing
   -- IAX2[coloco1]/16384 stopped sounds
   -- IAX2[coloco1]/16384 answered SIP/5054441234-a378
We're at 146.145.155.162 port 17752
Answering with capability 4
Answering with capability 8
Answering with non-codec capability 1
Reliably Transmitting (NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 68.38.121.217:5060;received=68.38.121.217
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as0445b58c
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:14109850123@146.145.155.162>
Content-Type: application/sdp
Content-Length: 219

v=0
o=root 11910 11910 IN IP4 146.145.155.162
s=session
c=IN IP4 146.145.155.162
t=0 0
m=audio 17752 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

to 68.38.121.217:15061
Sip read:  
ACK sip:14109850123@146.145.155.162:5060 SIP/2.0
Via: SIP/2.0/UDP 68.38.121.217:5060
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as0445b58c
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 102 ACK
User-Agent: CSCO/4
Content-Length: 0

voip1*CLI>
voip1*CLI>
voip1*CLI>
Sip read:  
BYE sip:14109850123@146.145.155.162:5060 SIP/2.0
Via: SIP/2.0/UDP 68.38.121.217:5060
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as0445b58c
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 103 BYE
User-Agent: CSCO/4
Content-Length: 0
Proxy-Authorization: Digest username="5054441234",realm="asterisk",uri="sip:146.145.155.162",response="34ac7e20b9d4a4e2912972894cce75fe",nonce="1141eae2",algorithm=md5


9 headers, 0 lines
Sending to 68.38.121.217 : 5060 (NAT)
Transmitting (NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 68.38.121.217:5060;received=68.38.121.217
From: "5054441234" <sip:5054441234@146.145.155.162>;tag=00070ec46b620008631c265d-0d09c3ac
To: <sip:14109850123@146.145.155.162>;tag=as0445b58c
Call-ID: 00070ec4-6b62001c-092d8a82-1db952eb@68.38.121.217
CSeq: 103 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:14109850123@146.145.155.162>
Content-Length: 0


to 68.38.121.217:15061
   -- Hungup 'IAX2[coloco1]/16384'
 == Spawn extension (generic-customer2, 14109850123, 2) exited non-zero on 'SIP/5054441234-a378'
   -- Executing Hangup("SIP/5054441234-a378", "") in new stack
 == Spawn extension (generic-customer2, h, 1) exited non-zero on 'SIP/5054441234-a378'
voip1*CLI>
Comments:By: zoa (zoa) 2003-09-22 15:43:47

it doesnt seem to be a bug, the handbook draft says the codec is in the [general] part of the sip.conf

However this would be very usefull option (e.g. to have all users use g729 or iLBC except some priviledged ones that can't because they have an phone that only has g711)

By: John Todd (jtodd) 2003-09-22 21:53:02

errrgh... that sucks, if that's the case.  In iax.conf, one can specify the codec on a per-peer basis; I would expect SIP to behave similarly.

By: Mark Spencer (markster) 2003-10-09 21:05:03

This should be fixed now, please confirm.

By: John Todd (jtodd) 2003-10-10 15:24:11

I'll give it a shot, though I don't see any changes to any of the files as of 3 minutes ago in the CVS tree that seem to reflect any changes to this extent... did the changes get committed?

By: John Todd (jtodd) 2003-10-10 16:23:12

No, I don't see a change in functionality.  Adding "disallow=all" and "allow=g729" lines to a friend did not change the fact that it accepted a G711u call from that friend.

By: John Todd (jtodd) 2003-10-22 22:45:43

Added to CVS by mark, tested by me.  seems to work.

By: John Todd (jtodd) 2003-10-23 21:59:37

Note: it may be a good idea to alter the sip.conf.sample file to include the following lines at the top of the file in the [general] section:

disallow=all
allow=all

The reason for this is that Grandstream phones will choke on the codec list if it is the "default" that currently puts GSM (a non-supported codec for GS phones) at the top of the list.  I have no idea why the GS barfs on this, but it does, and only the addition of explicit disallow and allow lines (using "all" or a list of valid codecs)  in the [general] or specific peer entries will solve the problem.

By: pliew (pliew) 2003-10-26 04:47:40.000-0600

I've tested with G729/ulaw/alaw for GrandStream and X-Lite for both incoming/outgoing and changing codecs preferences in sip.conf for most permutations and it works for me. Good stuff.

By: John Todd (jtodd) 2003-10-26 12:43:00.000-0600

Marking as resolved.