cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
852
Views
0
Helpful
3
Replies

Cisco Phones (SPA525G2 & SPA502) dropping incoming calls

ahmedwaqas992
Level 1
Level 1

I am not sure if I am posting this at the correct forum but here goes.

 

We are a small business that are running a Yeastar S100 PBX which is behind a Fortigate firewall. There are multiple trunks configured on the Yeastar S100 which are then routed to different ring groups, extensions etc. The trunks, ring groups & all the routing is working flawlessly however whenever the pbx tries to route an incoming call towards a Cisco phone (be it SPA525G2 or SPA502) the call drops at the time of pickup.

 

I have changed codecs from ulaw/alaw/g729 in the PBX and in the preferred codecs in Cisco phones as well. I have downgraded and upgraded the Cisco phones multiple time yet whatever I try to directly pick an incoming call it just can't seem to go through.

 

The strange thing is when I route the call through a virtual extension and then forward it to the Cisco phone the call DOES NOT drop and it works as how it supposed to. Even using the same trunk and configuration if I try to route it to some other brand phone like Fanvil/Yeastar the call goes through without any issue.

 

Can someone suggest me what is it that might be causing this? I have tried almost everything in the realm of my skill set to troubleshoot this but I just can't seem to figure it out.

3 Replies 3

Dan Lukes
VIP Alumni
VIP Alumni

Turn on the logging on the phone then capture:

1. the logs

2. the SIP packets related to the call setup

It will help you (or us) to analyze the cause

 

Debug and syslog Messages from the SPA3xx, SPA5xxG, SPA9xx, & WIP310 IP Phones


@Dan Lukes wrote:

Turn on the logging on the phone then capture:

1. the logs

2. the SIP packets related to the call setup

It will help you (or us) to analyze the cause

 

Debug and syslog Messages from the SPA3xx, SPA5xxG, SPA9xx, & WIP310 IP Phones


@Dan Lukes 

 

I recreated the fault and captured the Pcap as well as the log files from the PBX directly.

 

Would appreciate if you can pinpoint on where is the issue and how can I resolve this? The target extension is 6097 and the calling number is 01162114231

So late reply. Sorry. Although I have this thread subscribed, I received no notification about your comment, thus I has missed it.

Well, I assume you already solved the issue, but I will respond despite of it. This is the call setup INVITE send by SPA502G to your local PBX:

<--- Received SIP request (1208 bytes) from UDP:192.168.80.154:15060 --->
INVITE sip:0167023150@192.168.80.99:15060 SIP/2.0
Via: SIP/2.0/UDP 192.168.80.154:15060;branch=z9hG4bK-4fca9bd8
From: "6002" <sip:6002@192.168.80.99>;tag=d19e75954e3f5ca4o0
To: <sip:0167023150@192.168.80.99>
Call-ID: 86cd4929-f85a7e20@192.168.80.154
CSeq: 102 INVITE
Max-Forwards: 70
Authorization: Digest username="6002",realm="YSAsterisk",nonce="1594200003/453b691c256f2b7bd0cfb73adb6a5470",uri="sip:0167023150@192.168.80.99:15060",algorithm=MD5,response="73a8b535a0cb1e77b4390454e093bd39",opaque="57fe391e00358687",qop=auth,nc=00000001,cnonce="1cb1681b"
Contact: "6002" <sip:6002@192.168.80.154:15060>
Expires: 240
User-Agent: Cisco/SPA502G-7.5.2
Content-Length: 401
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Supported: replaces
Content-Type: application/sdp

v=0
o=- 7252662 7252662 IN IP4 192.168.80.154
s=-
c=IN IP4 192.168.80.154
t=0 0
m=audio 16468 RTP/AVP 0 2 8 9 18 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv


There's nothing important on it. It asks for classic RTP/AVP audio.

Well, ptime should be 20 instead of 30 and in Malaysia you should use PCMA only, but it have nothing to do with the issue we are speaking of.

Such incoming call setup request is processed by your local PBX (Yeastar, an Asterisk clone) and it transformed request to outgoing call setup (sent  to your upstream provider). Here the related outgoing INVITE:

<--- Transmitting SIP request (1095 bytes) to UDP:103.251.203.148:5061 --->
INVITE sip:0167023150@103.251.203.148:5061;transport=udp SIP/2.0
Via: SIP/2.0/UDP 115.134.129.73:15060;rport;branch=z9hG4bKPj7c4469e9-762c-42ac-8a9f-b5763f2cd1c5
From: "HUI MIN" <sip:072132500@103.251.203.148>;tag=aac96a60-6068-4606-9821-385054c24ab8
To: <sip:0167023150@103.251.203.148>
Contact: <sip:072132500@115.134.129.73:15060>
Call-ID: 2d60ff34-710d-4d9d-95c1-02d17f8670d7
CSeq: 5752 INVITE
Allow: OPTIONS, NOTIFY, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER, REGISTER
Supported: timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Yeastar S100-30.14.0.16
Content-Type: application/sdp
Content-Length:   392

v=0
o=- 1365985335 1365985335 IN IP4 192.168.80.99
s=Asterisk
c=IN IP4 115.134.129.73
t=0 0
m=audio 10244 RTP/SAVP 18 97 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:VZOmSAUzrY8Q/G2olaqpDrCZWzdbyKy5Xr6yV1o0
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv

It needs to be noted that it asks SECURED audio (RTP/SAVP) and upstream provider responds:

<--- Received SIP response (461 bytes) from UDP:103.251.203.148:5061 --->
SIP/2.0 415 Unsupported Media Type
Call-ID: 2d60ff34-710d-4d9d-95c1-02d17f8670d7
CSeq: 5752 INVITE
From: "HUI MIN" <sip:072132500@103.251.203.148>;tag=aac96a60-6068-4606-9821-385054c24ab8
To: <sip:0167023150@103.251.203.148>;tag=sip+1+d4f6000b+9657c7a9
Via: SIP/2.0/UDP 115.134.129.73:15060;received=115.134.129.73;rport=15060;branch=z9hG4bKPj7c4469e9-762c-42ac-8a9f-b5763f2cd1c5
Server: SIP/2.0
Content-Length: 0
Contact: <sip:103.251.203.148:5061>

It mean your upstream provider (REDTONE) doesn't support request transport protocol.  I assume it doesn't support encryption. Either at all, or AES_CM_128_HMAC_SHA1_80 cipher.

All at all, it's no SPA5xx issue. The interconnect Yealing <-> REDTONE is not configured properly. You need to follow REDTONEs requirements.