Unity Express Auto Attendant Codec Problems

Unanswered Question
Jul 4th, 2010

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:[email protected];user=phone SIP/2.0
Max-Forwards: 67
Session-Expires: 3600;refresher=uac
Supported: timer
To: 649950xxxx <sip:[email protected];user=phone>
From: 64212882xxx <sip:[email protected]>;tag=3487294900-685557
Contact: <sip:[email protected]:5060;user=phone>
P-Asserted-Identity:64212882xxx<sip:[email protected];user=phone>
Call-ID: [email protected]
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:[email protected]>;tag=3487294900-685557
To: 6499502xxx <sip:[email protected];user=phone>;tag=58A47A80-FD1
Date: Mon, 05 Jul 2010 05:01:40 GMT
Call-ID: [email protected]
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]: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:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67EA06
From: "64212882xxx" <sip:[email protected]>;tag=58A48778-221A
To: <sip:[email protected]>
Date: Mon, 05 Jul 2010 05:01:44 GMT
Call-ID: [email protected]
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:[email protected]: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:[email protected]>;tag=3487294908-391518
From: "64212882xxx" <sip:[email protected]>;tag=58A48778-221A
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
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:[email protected]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67F1B4E
From: 6499502xxx <sip:[email protected];user=phone>;tag=58A47A80-FD1
To: 64212882xxx <sip:[email protected]>;tag=3487294900-685557
Date: Mon, 05 Jul 2010 05:01:48 GMT
Call-ID: [email protected]
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:[email protected]: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:[email protected];user=phone>;tag=58A47A80-FD1
To: 64212882xxx <sip:[email protected]>;tag=3487294900-685557
Call-ID: [email protected]
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:[email protected]>;tag=3487294900-685557
From: 6499502xxx <sip:[email protected];user=phone>;tag=58A47A80-FD1
Contact: <sip:[email protected]:5060;user=phone>
Call-ID: [email protected]
CSeq: 101 INVITE
Via: SIP/2.0/UDP 202.180.67.xxx:5060;branch=z9hG4bK67F1B4E
Content-Length: 0

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Thomas Dillingham Wed, 08/04/2010 - 14:30

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

Scott Pettit Wed, 08/04/2010 - 16:05

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

Steven Holl Thu, 08/05/2010 - 07:45

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

Scott Pettit Sun, 01/30/2011 - 01:17

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
Steven Holl Sun, 01/30/2011 - 19:13

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.

Actions

This Discussion

Related Content