locked
Call trough Cisco 2801 fails RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

    we are trying to get our Lync Enterpise connected through a Cisco 2801 as PSTN gateway.

    We are stuck in the following situation:

    When we dial from a Lync client, the phone that was dialed rings.

    When the user on the other side takes the call, the call is canceld.

    The following error is logged all the time:

    SIP/2.0 488 Not Acceptable Here
FROM: "Althaus Benedikt"<sip:user.name@our-sip.de>;tag=d11711a668;epid=799ca4e759
TO: <sip:001765433234;phone-context=dg@our-sip.de;user=phone>;tag=e55a15f643;epid=CA4F909FA8
CSEQ: 1 INVITE
CALL-ID: 7a6ab38c31574c6db14c24856fe2b7a1
VIA: SIP/2.0/TLS 10.1.10.60:59838;branch=z9hG4bK00687E30.5BD0983A460E838A;branched=FALSE,SIP/2.0/TLS 192.168.22.104:51784;ms-received-port=51784;ms-received-cid=112E00
CONTENT-LENGTH: 0
P-ASSERTED-IDENTITY: <sip:001765433234;phone-context=dg@our-sip.de;user=phone>
SERVER: RTCC/4.0.0.0 MediationServer
ms-diagnostics: 10010;source="server1.our-sip.local";reason="Gateway side Media negotiation failed";component="MediationServer";ValidationError="SDP Exchange already failed before SetAnswer: Line 1: Missing equal sign (=). ";GatewayFqdn="10.1.20.6"
ms-diagnostics-public: 10010;reason="Gateway side Media negotiation failed";component="MediationServer";ValidationError="SDP Exchange already failed before SetAnswer: Line 1: Missing equal sign (=). "
ms-trunking-peer: 10.1.20.6
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet


     The trunk configuration in the cisco is the following:

    dial-peer voice 5 voip
 description **Incoming Call from LYNC dghams60**
 destination-pattern 43.
 no voice-class sip early-offer forced
 session protocol sipv2
 session target ipv4:10.1.10.60:5068
 incoming called-number 43.
 dtmf-relay cisco-rtp
 codec g711ulaw
 no vad

     

    Perhaps, can anyone give us a hint where to look next?

    Thanks,

    benedikt

    Have a look at: http://www.scapaot.de
    Tuesday, November 22, 2011 2:22 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

     

    Looks like Media Negotiation is failing on the call leg between Mediation and Gateway.

    SDP seems to be Malformed.

    Check the Trunck Configuration on the Gateway amke sure all SDP parameters and defined correctly.

     

    -Santosh

     

     

    • Marked as answer by Sean_Xiao Monday, December 5, 2011 1:36 AM
    Thursday, December 1, 2011 12:04 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Seems to me that there's something wrong when there's the media connection take place. can you enable G711 a-law also from cisco side and try again?

    Thamara. 

    Tuesday, November 22, 2011 2:48 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for your quick responce.

    We have tried using G711 a-law also, but without any effect.

    The error is still the same.

    Our actuel trunk config:

    voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729r8
codec preference 4 g729br8
codec preference 5 clear-channel

dial-peer voice 5 voip
description **Incoming Call from LYNC dghams60**
destination-pattern 43.
session protocol sipv2
session target ipv4:10.1.10.60:5068
voice-class codec 1
voice-class sip transport switch udp tcp
no voice-class sip early-offer forced
dtmf-relay sip-notify rtp-nte

    In wireshark, we can see the following:

    When the user picks up the phone, there are some (5 to 10) RTP packages (UDP) send from the gateway to the lync.
    After round about 4 packages, the mediation answers with: port unreachable

    But I can see the port is opened up (using tcpview) and listening.

    Have a look at: http://www.scapaot.de
    Tuesday, November 22, 2011 3:05 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    actually the SIP messages are passing through and getting the messages correctly. theth's the reason it rings. once you innitiate the call by picking up, it start flowing the RTP using RTP port range. can you check whether some security software in the client blocking the RTP ports in the client PC? may b a Virus scan or a Firewall?

    Thamara.

    Tuesday, November 22, 2011 3:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    On clientside, the following is locked in the eventlog:

     RequestUri:   sip:005415165630;phone-context=dg@our-sip.de;user=phone
From:         sip:benedikt.althaus@our-sip.de;tag=0434aede09
To:           sip:005415165630;phone-context=dg@our-sip.de;user=phone;tag=efb6e5be9
Call-ID:      c50c79c197d54a4bbb8f4d08d9708fd8
Content-type: multipart/alternative;boundary="----=_NextPart_000_1F29_01CCA92F.5DF0F010";call-type=audiovideo

------=_NextPart_000_1F29_01CCA92F.5DF0F010
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <d1e94cebb85b42ca9e295480d8f9f039@our-sip.de>
Content-Disposition: session; handling=optional; ms-proxy-2007fallback

v=0
o=- 0 0 IN IP4 192.168.22.104
s=session
c=IN IP4 192.168.22.104
b=CT:53980
t=0 0
m=audio 32266 RTP/SAVP 114 9 112 111 0 8 116 115 4 97 13 118 101
a=candidate:SVpfVyh7mgPtsKD9OY72X21H1hhp4WdLKE5vWRGXUX4 1 kEiH1JxH7TnY0CNOqI5s0A UDP 0.830 192.168.22.104 32266 
a=candidate:SVpfVyh7mgPtsKD9OY72X21H1hhp4WdLKE5vWRGXUX4 2 kEiH1JxH7TnY0CNOqI5s0A UDP 0.830 192.168.22.104 32267 
a=candidate:em0Ws2zJkvDC1LCeLlfqEFh9con2g79vDLONEH5LSSc 1 z5Bcmyp+iMmDuX0iGef/ww UDP 0.840 192.168.0.100 26092 
a=candidate:em0Ws2zJkvDC1LCeLlfqEFh9con2g79vDLONEH5LSSc 2 z5Bcmyp+iMmDuX0iGef/ww UDP 0.840 192.168.0.100 26093 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:2nxWB89+7mls90qoiMlUkSyxf1ydw5tjlDgr7SNp|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:MvqnuwFA+Yz1Rkp5Z28PIB4GQ3MPoRkSQztxAouy|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:fChdwrKX6MtX2MQpnw7keZ8iqvBFYWEtxxj8u+9u|2^31
a=maxptime:200
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 AAL2-G726-32/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:4 G723/8000
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=encryption:required

------=_NextPart_000_1F29_01CCA92F.5DF0F010
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <500da7f7762f4e1e9ae91f98dd04ad3c@our-sip.de>
Content-Disposition: session; handling=optional

v=0
o=- 0 0 IN IP4 192.168.22.104
s=session
c=IN IP4 192.168.22.104
b=CT:53980
t=0 0
m=audio 12626 RTP/SAVP 114 9 112 111 0 8 116 115 4 97 13 118 101
a=ice-ufrag:eQq6
a=ice-pwd:oSxbuRqzcZ6MEB5weEsKh1mJ
a=candidate:1 1 UDP 2130706431 192.168.0.100 27232 typ host 
a=candidate:1 2 UDP 2130705918 192.168.0.100 27233 typ host 
a=candidate:2 1 UDP 2130705919 192.168.22.104 12626 typ host 
a=candidate:2 2 UDP 2130705406 192.168.22.104 12627 typ host 
a=candidate:3 1 TCP-ACT 1684798463 192.168.0.100 27232 typ srflx raddr 192.168.0.100 rport 27232 
a=candidate:3 2 TCP-ACT 1684797950 192.168.0.100 27232 typ srflx raddr 192.168.0.100 rport 27232 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:2nxWB89+7mls90qoiMlUkSyxf1ydw5tjlDgr7SNp|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:MvqnuwFA+Yz1Rkp5Z28PIB4GQ3MPoRkSQztxAouy|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:fChdwrKX6MtX2MQpnw7keZ8iqvBFYWEtxxj8u+9u|2^31
a=maxptime:200
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 AAL2-G726-32/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:4 G723/8000
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=encryption:required

------=_NextPart_000_1F29_01CCA92F.5DF0F010--


Response Data:

101  Progress Report
ms-diagnostics:  14011;reason="Called Number translated";source="dghams60.our-sip.local";RuleName="0";CalledNumber="005415165630";TranslatedNumber="005415165630";appName="TranslationService"


101  Progress Report
ms-diagnostics:  12006;reason="Trying next hop";source="dghams60.our-sip.local";PhoneUsage="External";PhoneRoute="External";Gateway="10.1.20.6";appName="OutboundRouting"


183  Session Progress


183  Session Progress


488  Not Acceptable Here
ms-diagnostics-public:  10010;reason="Gateway side Media negotiation failed";component="MediationServer";ValidationError="SDP Exchange already failed before SetAnswer: Line 1: Missing equal sign (=). ";OriginalPresenceState="0";CurrentPresenceState="0";MeInsideUser="Yes";ConversationInitiatedBy="0";SourceNetwork="0";RemotePartyCanDoIM="No"

    I'm going to build up a client without Active Directory GPO and at the same subnet as the lync is.
    Perhaps we can get more information that way.

    Regards,

    benedikt

    Have a look at: http://www.scapaot.de
    Tuesday, November 22, 2011 9:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Do you configrate encryption support level for mediation server?

    If you the encryption is supported in your mediation server but the cisco does not suppted it. That will cause this problem. Please check it in lync control panel.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Sean_Xiao Wednesday, November 30, 2011 1:46 AM
    Thursday, November 24, 2011 9:10 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

     

    Looks like Media Negotiation is failing on the call leg between Mediation and Gateway.

    SDP seems to be Malformed.

    Check the Trunck Configuration on the Gateway amke sure all SDP parameters and defined correctly.

     

    -Santosh

     

     

    • Marked as answer by Sean_Xiao Monday, December 5, 2011 1:36 AM
    Thursday, December 1, 2011 12:04 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Please post a full "debug ccsip messages" output from the 2801 for the failing call ?

    Also try to update your ISR to the last IOS version.

    Friday, January 27, 2017 6:23 PM