Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2358
Views
0
Helpful
5
Replies

Unity Express Auto Attendant Codec Problems

Scott Pettit
Level 9
Level 9

‎07-04-2010 10:18 PM - edited ‎03-15-2019 11:32 PM

Hi,

Have a problem I can't get my head around a solution to:

PSTN Connection is a SIP trunk that supports g711ulaw/g711alaw/g729r8/g722
Running on UC520 with IOS 15.0(1)XA2 (Call Manager Express)

Unity Express 8.0.1

Call flow as follows:

PSTN SIP Trunk ---> Unity Express Auto Attendant ---> Hunt Group (that includes an external PSTN Mobile Number for emergency support for clients)

Basically the calls keep on terminating as soon as the incoming g711u call tries to bridge with a g729 call.  I would have thought the transcoding resources on Call Manager Express should begin transcoding rather than attempting to bridge the call with mis-matched codecs?

Additional SIP messaging cut out for clarity.

The call comes in preferring g729r8, g711a, g711u

Received:
INVITE sip:649950xxxx@202.180.67.xxx;user=phone SIP/2.0
Max-Forwards: 67
Session-Expires: 3600;refresher=uac
Supported: timer
To: 649950xxxx <sip:649950xxxx@203.184.16.35;user=phone>
From: 64212882xxx <sip:64212882xxx@203.184.16.35>;tag=3487294900-685557
Contact: <sip:64212882xxx@203.184.16.35:5060;user=phone>
P-Asserted-Identity:64212882xxx<sip:64212882xxx@203.184.16.35;user=phone>
Call-ID: 856716-3487294900-685393@mscak1.commverge.co.nz
CSeq: 1 INVITE
Via: SIP/2.0/UDP 203.184.16.35:5060;branch=z9hG4bK448c0eb310c43d713630ba6e59f3948c
Content-Type: application/sdp
Content-Length: 266

v=0
o=mscak1 662 1278306099 IN IP4 203.184.16.35
s=sip call
c=IN IP4 203.184.16.38
t=0 0
m=audio 39196 RTP/AVP 18 8 0 100 101
a=fmtp:18 annexb=no
a=ptime:20
a=rtpmap:100 X-NSE/8000/1
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000/1
a=fmtp:101 0-15

Unity Express only supports g711u so the call is setup in g711u


Jul  5 05:01:40.887: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.184.16.35:5060;branch=z9hG4bK448c0eb310c43d713630ba6e59f3948c
From: 64212882xxx <sip:64212882xxx@203.184.16.35>;tag=3487294900-685557
To: 6499502xxx <sip:6499502xxx@203.184.16.35;user=phone>;tag=58A47A80-FD1
Date: Mon, 05 Jul 2010 05:01:40 GMT
Call-ID: 856716-3487294900-685393@mscak1.commverge.co.nz
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:6499502xxx@202.180.67.xxx:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 252

v=0
o=CiscoSystemsSIP-GW-UserAgent 8698 812 IN IP4 202.180.67.xxx
s=SIP Call
c=IN IP4 202.180.67.xxx
t=0 0
m=audio 19580 RTP/AVP 0 101
c=IN IP4 202.180.67.xxx
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Caller presses Auto Attendant menu option that goes to a support hunt  group which rings internal extensions then mobile numbers

Internal  phones ring and can be answered with no problem as the call remains in  g711u.

Now the problem is when the call goes out to mobile, Call  Manager Express initiates the following:


Jul  5 05:01:44.107: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:6421677xxx@203.184.16.35:5060 SIP/2.0
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67EA06
From: "64212882xxx" <sip:64212882xxx@202.180.67.xxx>;tag=58A48778-221A
To: <sip:6421677xxx@203.184.16.35>
Date: Mon, 05 Jul 2010 05:01:44 GMT
Call-ID: 3D95AD3C-872911DF-94239B35-8FD000ED@202.180.67.xxx
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0999137509-2267615711-2484837173-2412773613
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1278306104
Contact: <sip:64212882xxx@202.180.67.xxx:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 66
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 312

v=0
o=CiscoSystemsSIP-GW-UserAgent 5079 5251 IN IP4 202.180.67.xxx
s=SIP Call
c=IN IP4 202.180.67.xxx
t=0 0
m=audio 17132 RTP/AVP 18 8 0 101
c=IN IP4 202.180.67.xxx
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

As it is a mobile call, our SIP trunk carrier prefers G729, and our Call Manager Express normally is okay with this, so the call gets setup in G729.

Jul  5 05:01:48.399: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
To: <sip:6421677xxx@203.184.16.35>;tag=3487294908-391518
From: "64212882xxx" <sip:64212882xxx@202.180.67.xxx>;tag=58A48778-221A
Contact: <sip:6421677xxx@203.184.16.35:5060>
Call-ID: 3D95AD3C-872911DF-94239B35-8FD000ED@202.180.67.xxx
CSeq: 101 INVITE
Allow-Events: telephone-event
Content-Type: application/sdp
Via: SIP/2.0/UDP 202.180.67.226:5060;branch=z9hG4bK67EA06
Content-Length: 215

v=0
o=mscak1 9293 3550 IN IP4 203.184.16.35
s=sip call
c=IN IP4 203.184.16.38
t=0 0
m=audio 39208 RTP/AVP 18 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=rtpmap:18 G729/8000

Now that the call is going out to our emergency mobile contact, the original caller gets bridged audio through to this person so they can speak to our engineer.  Remember this call is still in g711u as it was on Unity Express.  Call manager Express now tries to invite the original call to talk to the new call, but using G729 now.

Jul  5 05:01:48.407: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:64212882xxx@203.184.16.35:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67F1B4E
From: 6499502xxx <sip:6499502xxx@203.184.16.35;user=phone>;tag=58A47A80-FD1
To: 64212882xxx <sip:64212882xxx@203.184.16.35>;tag=3487294900-685557
Date: Mon, 05 Jul 2010 05:01:48 GMT
Call-ID: 856716-3487294900-685393@mscak1.commverge.co.nz
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0999137509-2267615711-2484837173-2412773613
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1278306108
Contact: <sip:6499502xxx@202.180.67.xxx:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 275

v=0
o=CiscoSystemsSIP-GW-UserAgent 8698 813 IN IP4 202.180.67.xxx
s=SIP Call
c=IN IP4 202.180.67.xxx
t=0 0
m=audio 19580 RTP/AVP 18 101
c=IN IP4 202.180.67.xxx
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Jul  5 05:01:48.423: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67F1B4E
From: 6499502xxx <sip:6499502xxx@203.184.16.35;user=phone>;tag=58A47A80-FD1
To: 64212882xxx <sip:64212882xxx@203.184.16.35>;tag=3487294900-685557
Call-ID: 856716-3487294900-685393@mscak1.commverge.co.nz
CSeq: 101 INVITE
Content-Length: 0

And so because the codec has changed the entire call falls over.


Jul  5 05:01:48.499: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 500 Server Internal Error
To: 64212882xxx <sip:64212882xxx@203.184.16.35>;tag=3487294900-685557
From: 6499502xxx <sip:6499502xxx@203.184.16.35;user=phone>;tag=58A47A80-FD1
Contact: <sip:64212882xxx@203.184.16.35:5060;user=phone>
Call-ID: 856716-3487294900-685393@mscak1.commverge.co.nz
CSeq: 101 INVITE
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67F1B4E
Content-Length: 0

Labels:
0 Helpful
5 Replies 5

Thomas Dillingham
Level 1
Level 1

‎08-04-2010 02:30 PM

Does the dial-peer that matches the AA trigger have the proper codec defined:

i.e.

! Dial peer

dial-peer voice 6400 voip

! this will correspond to your trigger

destination-pattern 6400

! sets the protocol to sipv2

session protocol sipv2

! target (CUE IP Address)

session target ipv4:10.1.1.1

! force the codec on this dial-peer to g711ulaw

codec g711ulaw

You may need to run a debug

debug voip dialpeer inout

to ensure that you are leaving CME on the correct dialpeer with the correct codec and protocol.

This would be a good place to start... there are several other things that can cause this behavior:

Thomas Dillingham

Cisco TAC - MS Voice

TwD

0 Helpful

Scott Pettit
Level 9
Level 9
In response to Thomas Dillingham

‎08-04-2010 04:05 PM

Hi Thomas,

Yes I have codec g711ulaw specified on the dial-peer that goes to my CUE AA pilot.  I managed a pretty nasty work around by creating a new dial-peer for each of the SNR mobile numbers that locked the codec for those calls to g711ulaw too.

I'll try that debug when I have some spare time to test again.  Suspect this might be related to another bug I had previously logged: CSCtb42748

-Scott

0 Helpful

Steven Holl
Cisco Employee
Cisco Employee

‎08-05-2010 07:45 AM

Scott,

Similar to your workaround, you can accomplish the same with a single dial-peer.  If you can configure your dial-peers so that you can get the calls from CUE to match their own inbound dial-peer ('answer-address 6499502xxx' would be the way to do this, but you can't use 'incoming-called number' with a wildcard if you do this since incoming-called number is matched before answer-address), then you can configure just codec 711ulaw on the inbound dial-peer leg.

Another option is to configure CUE's transfer method as blind bye-also (I think the syntax on CUE is ccn cubsystem sip/transfer blind bye).  It looks like it is doing an attended or semi-attended transfer right now.  The Bye-also will pull CUE out of the call flow before the INVITE for the outbound call, so at that point the codecs to CUE won't matter.  You may see ringback issues with this, though.

-Steve

0 Helpful

Scott Pettit
Level 9
Level 9
In response to Steven Holl

‎01-30-2011 01:17 AM

Hi Steven,

Late response but I'd still like to figure this one out.  It seems blind bye-also is the default, and is what is set on my CUE installation:

unity# show ccn subsystem sip

SIP Gateway:                            10.3.8.2

SIP Port Number:                        5060

DTMF Relay:                             sip-notify

MWI Notification:                       outcall

MWI Envelope Info:                      disabled

Transfer Mode:                          bye-also

SIP RFC Compliance:                     Pre-RFC3261

The thing I'm not sure on is why CME isn't transcoding the call, should it not pick up the codec mismatch and kick in DSP resources to help it go through?
-Scott

0 Helpful

Steven Holl
Cisco Employee
Cisco Employee
In response to Scott Pettit

‎01-30-2011 07:13 PM 

scott-pettit wrote:

 
The thing I'm not sure on is why CME isn't transcoding the call, should it not pick up the codec mismatch and kick in DSP resources to help it go through?
 
-Scott

Its hard to tell without full debugs during the call.  Can you get the following debugs during the entire call where the issue occurs?

debug ccsip all

debug voip ccapi inout

Also post the config of CME.

0 Helpful
Customers Also Viewed These Support Documents