what is the differnece between 7960 SIP and 7941 SIP

[Richard Bradfield]

I am trying to find an answer to this question, We have just started looking after a remote site, that has 7960 and 7941 SIP phones that are registered to an external SIP (asterisk) server.

The phones IP addresses are Natted on a Cisco 897 thru to the Internet. Now the 7960s work ok. But the 7941s cannot receive calls just make calls. I have searched for a definitive answer to why it is not working  but have not found one.

looking at the ip nat translations below there are many more for the 7941 compared to the 7960

the .2,3 and 4 are 7960 and .5 is a 7941, all 7941s have a lot of entries

Any help appreciated

udp 49.xx.xx.xx:1032   10.xx.xx.2:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:1024   10.xx.xx.3:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:1139   10.xx.xx.4:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:19224  10.xx.xx.4:19224      110.xx.xx.xx:15204 110.xx.xx.xx:15204
udp 49.xx.xx.xx:19226  10.xx.xx.4:19226      110.xx.xx.xx:19228 110.xx.xx.xx:19228
udp 49.xx.xx.xx:19228  10.xx.xx.4:19228      110.xx.xx.xx:14256 110.xx.xx.xx:14256
udp 49.xx.xx.xx:1037   10.xx.xx.5:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:1036   10.xx.xx.5:49158      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51673  10.xx.xx.5:51673      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51674  10.xx.xx.5:51674      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51675  10.xx.xx.5:51675      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51676  10.xx.xx.5:51676      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51677  10.xx.xx.5:51677      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51678  10.xx.xx.5:51678      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51679  10.xx.xx.5:51679      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51680  10.xx.xx.5:51680      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51681  10.xx.xx.5:51681      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51682  10.xx.xx.5:51682      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51683  10.xx.xx.5:51683      110.xx.xx.xx:5060  110.xx.xx.xx:5060
udp 49.xx.xx.xx:51684  10.xx.xx.5:51684      110.xx.xx.xx:5060  110.xx.xx.xx:5060

[Richard Bradfield]

I have been going thru a capture done on the 897

the difference I see in the SIP registration is that the 7960 has "user=phone" whereas the 7941 has nothing

Is this the reason the 7941s can't receive calls. everything else in the capture looks much the same

[Paul Kazzi]

Is the 897 acting as a pure router/FW only? A Wireshark trace (LAN and Internet), more info on setup and SIP messages from Asterix side would be handy to help troubleshoot. Are you expecting both phones to ring at the same time ?

How does Asterix know to send inbound  call to correct phone eg 7941? Do you have a one-to-one NAT for both phones or some differentiator?

What happens if you only register the 7941 and keep 7960 unplugged and cleared from NAT table/ SIP registration etc  ? Will the 7941 work in these circumstances?

[Richard Bradfield]

Hi this site has 3 x 7960 and 7 x 7941s, the 7960s work ok. the 7941s can
only call outbound.
the 7941s do not receive calls directly,all calls go to an
administrator(on a 7960) who then tries to call the 7941 extension
the site only has a single Internet address so PAT is used, this does not
seem to be the problem as all the devices register.
The difference I see in the registration from the captures, is that the
7960 has the "user=phone" parameter set, whereas the 7941s do not.
apparently this has worked in the past

see examples below from capture, public address removed

7960 registration second phase
**************************************
E`KC0?(1jn7REGISTER sip:xx.xx.xx.251 SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.106:1034;branch=z9hG4bK7cc8a885
From: <49862>
To: <49862>
Call-ID: 00152b17-754b0002-23a6a24f-203519ea@10.46.40.2
Date: Sat, 06 Jan 2018 03:54:12 GMT
CSeq: 4354 REGISTER
User-Agent: CSCO/7
Contact: <49862>
Authorization: Digest
username="49862",realm="asterisk",uri="sip:xx.xx.xx.251",response="b61b734974437809e45a534e24d240dd",nonce="2d692a27",algorithm=MD5
Content-Length: 0
Expires: 120

7941 registration second phase
*********************************
E`k?1jnREGISTER sip:xx.xx.xx.251 SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.106:1044;branch=z9hG4bKb290a9e0
From: <49864>;tag=0024c4bf41b34a1774449a08-7517334e
To: <49864>
Call-ID: 0024c4bf-41b30002-560e27e2-747bcf8b@10.46.40.6
Max-Forwards: 70
Date: Sat, 06 Jan 2018 03:54:11 GMT
CSeq: 217995 REGISTER
User-Agent: Cisco-CP7941G/8.3.0
Contact: <49864>:1044;transport=udp>;+sip.instance="<00000000-0000-0000-0000-0024c4bf41b3>";+u.sip!
model.ccm.cisco.com="115"
Authorization: Digest
username="49864",realm="asterisk",uri="sip:xx.xx.xx.251",response="7ddf2db5a1b070ca1bf61777d5e74552",nonce="2c40196b",algorithm=MD5
Supported: (null),X-cisco-xsi-6.0.2
Content-Length: 0
Expires: 120

The 7941s are then very chatty, I see the options request from the server
every second an example below,

OPTIONS sip:49870@10.46.40.10:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.251:5060;branch=z9hG4bK5ba2cdfa;rport
From: "asterisk" ;tag=as25c065da
To: <49870>
Contact:
Call-ID: 00eb43ee4d3d90165e04d4f715d66aa0@xx.xx.xx.251
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sat, 06 Jan 2018 03:55:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

[Paul Kazzi]

So you cannot even call from 7960 to 7941 models? 

OPTIONS are capabilities type query but in the limited messages provided, hard to put into context.

There are differences in these old models where 7960 is Type-A and does not support SIP-KPML or "+" dialing whereas 7941 do and some other differences eg with/without SIP dial rules configured on these phones.

[Richard Bradfield]

that is correct the 7960 cannot call the 7941s, I think gets busy tone.

The sequence below is repeated for each 7941 every secondor so this does
not happen on the 7960

Option request from server,
***************************
0OPTIONS sip:49870@xx.xx.xx.10:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.251:5060;branch=z9hG4bK190795f2;rport
From: "asterisk" ;tag=as126ead99
To: <49870>
Contact:
Call-ID: 03e8ce3e2483f5bd2c3ee66500efda77@xx.xx.xx.251
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sat, 06 Jan 2018 03:54:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Response from 7941
*****************
nSIP/2.0 200 OK
Via: SIP/2.0/UDP xx.xx.xx.251:5060;branch=z9hG4bK190795f2;rport
From: "asterisk"
<5060>;tag=001e4aa91815078061e620e0-54cd7ae3
Call-ID: 03e8ce3e2483f5bd2c3ee66500efda77@xx.xx.xx.251
Date: Sat, 06 Jan 2018 03:54:04 GMT
CSeq: 102 OPTIONS
Server: Cisco-CP7941G/8.3.0
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Allow-Events: kpml,dialog,refer
Accept: application/sdp,multipart/mixed,multipart/alternative
Accept-Encoding: identity
Accept-Language: en
Supported: replaces,join,norefersub
Content-Length: 235
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 3718 0 IN IP4 10.46.40.10
s=SIP Call
t=0 0
m=audio 0 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

[Paul Kazzi]

What does SIP trace from attempted call look like ?

[Richard Bradfield]

I haven't got one yet, as only started looking at this today, will get a
capture on Monday, when people are in