Cisco 79x0 - Conference fails unless ulaw allowed


(Tom Rymes) #1

I have a bit of an odd situation here. Using Cisco 79x0 phones, I am able to call to other extensions, other sites on the far side of a tunnel, accept incoming calls, and make outgoing calls. I never have codec problems, as the PBX transcodes as needed.

However, if I am on one call and use the phone’s built-in “Conference” or “Confrn” button to try and join two calls together, I found that it only works if my extension has ulaw enabled. Otherwise, it ends with a reorder and the following error:

chan_sip.c: No compatible codecs, not accepting this offer!

Digging a little deeper, I found that the Asterisk SIP Settings > General page only had g729 (for which we have licenses) and ulaw enabled. My extension only had g729 and gsm enabled ( allow=g729&gsm ). Either adding ulaw to my extension or adding gsm to the General settings made it work.

Why is this? Is it something I have misconfigured? an obscure Cisco setting I missed? I would assume that, if my extension were only allowed to use, say, gsm, that the PBX should handle transcoding the audio in this situation, but for some reason the second leg seems to use the codec specified in the general settings instead of the settings specified in the extension config - and oddly won’t work with g729 when we have plenty of available licenses.

PS: I should reiterate that I am not trying to use a conference room here, I am just trying to use the phones built-in conference capability.


#2

Probably, the 79x0 lacks sufficient horsepower (or perhaps, internal licensing) to simultaneously code and decode two G.729 streams, so when you do a three-way call, at least one leg must be G.711. This is true for Cisco ATAs and SPA IP phones; I’m guessing that it also affects the 79x0.

That’s somewhat surprising. If the extension does not have a disallow parameter (only the allow), I’d expect ulaw to still be enabled and the call to work without changing anything. And if it has disallow=all, that would imply that the phone can do GSM, which I believe it can’t. So there may be a bug here. Have you looked at what codecs actually get used in this situation?

However, why are you using G.729 in the first place? It’s 24 years old and voice quality is IMO poor, especially when the path includes a highly compressed mobile codec. If you have sufficient bandwidth, use ulaw (or better) everywhere. If your tunnel is satellite or G3 cellular, I’d recommend using ulaw on the phone and transcoding to/from Opus on each side of the tunnel (assuming sufficient horsepower in the PBX machines). This might also apply to DSL with very limited upstream speed. Please describe your network configuration and speeds.

Edit: It appears that I was mistaken and Cisco does support GSM in some configurations. However, that also IMO sounds pretty poor, so if you are bandwidth challenged consider transcoding in the PBX.


(Tom Rymes) #3

I actually think you may be right about the 79x0 and GSM. I just swapped my allow parameter to allow=gsm and it failed to work. BTW, I do have a disallow=all parameter.

As for the reason we are using g729a? Bandwidth, of course! Much cheaper to buy licenses for g729 once than to pay extra each and every month for enough bandwidth to carry potentially 200+ channels of ulaw (we’re using fiber, not G3 or cellular). I know some folks don’t like the sound quality of GSM or other low-bandwidth codecs, but I don’t think most people have expectations that high for a phone call. The extensions use g729 to keep the transcoding load down on the PBX, and because…why not? What I really need is a good way to play g729 call recordings on a computer, as we now record all incoming calls to a GSM-encoded WAV file and while that works great, the added load on the server to transcode all calls from g729 to gsm for the recording file would be nice to avoid. Unfortunately, recording in g729 eliminates the transcoding, but results in a file that’s hard to play. We can convert the file manually at the asterisk command prompt, but that’s not really scalable.

Back to the original question, which is why the second leg of this call uses the settings for the general section of sip.conf instead of the settings for this extension?


(Joshua C. Colp) #4

Instead of guessing what it’s using I’d suggest getting an actual packet capture of the failed call. This can confirm whether or not what @Stewart1 is saying is true. The phone itself may not be able to do G.729, and the offer thus contains ulaw.


(Tom Rymes) #5

@jcolp I’ll give that a go after hours when the amount of junk scrolling past the console is more manageable. However, even if the phone is unable to do g729 on two legs, it should still use the settings for the extension, not the SIP General settings, no? In other words, if the extension has allow=g729&ulaw and SIP General has ```allow=g729&gsm", shouldn’t the call go through, even if the phone requests ulaw?

FWIW: I found this thread, but the proposed solution of “preferred_codec: g729a” doesn’t work for me, as I already had that option set. https://community.asterisk.org/t/resolved-conferencing-on-cisco-7940-7960-using-g729-codec/14188/4


(Joshua C. Colp) #6

It should provided the phone continues to authenticate as itself, but I’d prefer not to guess without precisely seeing what the phone is doing.


(Tom Rymes) #7

OK, here we go. It looks like the first call offers g729a and ulaw/alaw, while when using the conference feature, the phone only offers ulaw/alaw. This is a normal call:

<--- SIP read from UDP:10.10.10.111:5060 --->
INVITE sip:4101@10.10.10.254 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.111:5060;branch=z9hG4bK27a57d89
From: "456" <sip:456@10.10.10.254>;tag=0008a3263636e7204b95b0cd-2daecfb9
To: <sip:4101@10.10.10.254>
Call-ID: 0008a326-3636013f-33d581c1-0ba496da@10.10.10.111
Max-Forwards: 70
Date: Mon, 03 Feb 2020 19:24:17 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP7960G/8.0
Contact: <sip:456@10.10.10.111:5060;transport=udp>
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Remote-Party-ID: "456" <sip:456@10.10.10.254>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,norefersub
Content-Length: 276
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 24354 0 IN IP4 10.10.10.111
s=SIP Call
t=0 0
m=audio 22234 RTP/AVP 18 0 8 101
c=IN IP4 10.10.10.111
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->

This is a call to the same extension, but as the second leg to a conference:

<--- SIP read from UDP:10.10.10.111:5060 --->
INVITE sip:4101@10.10.10.254 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.111:5060;branch=z9hG4bK1cb50ab3
From: "456" <sip:456@10.10.10.254>;tag=0008a3263636e7042277d4c0-71f0e24d
To: <sip:4101@10.10.10.254>
Call-ID: 0008a326-3636013d-37807c97-4309e0a5@10.10.10.111
Max-Forwards: 70
Date: Mon, 03 Feb 2020 19:12:01 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP7960G/8.0
Contact: <sip:456@10.10.10.111:5060;transport=udp>
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Remote-Party-ID: "456" <sip:456@10.10.10.254>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,norefersub
Content-Length: 229
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 19537 0 IN IP4 10.10.10.111
s=SIP Call
t=0 0
m=audio 29544 RTP/AVP 0 8 101
c=IN IP4 10.10.10.111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->

(Lorne Gaetz) #8

You may prefer sngrep for this: Virtuous Signalling


(Joshua C. Colp) #9

And the output of “sip show peer 456”?


(Tom Rymes) #10
[root@vox ~]# asterisk -rx "sip show peer 456"

  * Name       : 456
  Description  :
  Secret       : <Set>
  MD5Secret    : <Not set>
  Remote Secret: <Not set>
  Context      : from-internal
  Record On feature : automon
  Record Off feature : automon
  Subscr.Cont. : <Not set>
  Language     : en
  Tonezone     : <Not set>
  AMA flags    : Unknown
  Transfer mode: open
  CallingPres  : Presentation Allowed, Not Screened
  Callgroup    :
  Pickupgroup  :
  Named Callgr :
  Nam. Pickupgr:
  MOH Suggest  :
  Mailbox      : 456@default
  VM Extension : *96
  LastMsgsSent : 3/56
  Call limit   : 2147483647
  Max forwards : 0
  Dynamic      : Yes
  Callerid     : "Tom Rymes" <456>
  MaxCallBR    : 384 kbps
  Expire       : 2716
  Insecure     : no
  Force rport  : No
  Symmetric RTP: No
  ACL          : Yes
  DirectMedACL : No
  T.38 support : No
  T.38 EC mode : Unknown
  T.38 MaxDtgrm: 4294967295
  DirectMedia  : No
  PromiscRedir : No
  User=Phone   : No
  Video Support: No
  Text Support : No
  Ign SDP ver  : No
  Trust RPID   : Yes
  Send RPID    : Yes
  Path support : No
  Path         : N/A
  TrustIDOutbnd: Legacy
  Subscriptions: Yes
  Overlap dial : Yes
  DTMFmode     : rfc2833
  Timer T1     : 500
  Timer B      : 32000
  ToHost       :
  Addr->IP     : 10.10.10.111:5060
  Defaddr->IP  : (null)
  Prim.Transp. : UDP
  Allowed.Trsp : UDP
  Def. Username: 456
  SIP Options  : (none)
  Codecs       : (g729|gsm|ulaw)
  Auto-Framing : No
  Status       : OK (129 ms)
  Useragent    : Cisco-CP7960G/8.0
  Reg. Contact : sip:456@10.10.10.111:5060;transport=udp
  Qualify Freq : 60000 ms
  Keepalive    : 0 ms
  Sess-Timers  : Accept
  Sess-Refresh : uas
  Sess-Expires : 1800 secs
  Min-Sess     : 90 secs
  RTP Engine   : asterisk
  Parkinglot   :
  Use Reason   : No
  Encryption   : No
  RTCP Mux     : No

(Tom Rymes) #11

FWIW, this is now working as I would expect it. That is, if ulaw and/or alaw are enabled for the extension, then it works. Whether ulaw and alaw are enabled in SIP General is irrelevant. I’d swear that wasn’t the case before, but will assume I was just wrong before.

Thanks to all for the help, and it seems that the takeaway is that ulaw and/or alaw needs to be enabled to use the conference function with these 7940/7960 phones.


(system) closed #12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.