Handset not ringing when invited to (PJSIP, SNOM 320)

Asterisk Asterisk Support
#1

Hi,

I have a rule that looks like this:

and it gives calling a go when the call comes in:

but for some reason, the SNOM 320 handset doesn’t actually ring.

Showing the endpoint during the ringing attempt, it seems to know that it isn’t ringing:

[i] Endpoint: 6005/6005 Not in use 1 of inf InAuth: auth6005/6005 Aor: 6005 1 Contact: 6005/sip:6005@<HANDSET-IP>:44001;line=m5g7ju7r Unknown nan Channel: PJSIP/6005-00000026/AppDial Down 20 Exten: <EXTERNALNO> CLCID: "<EXTERNALNO>" <<EXTERNALNO>>[/i]

Tracing the PJSIP there are INVITE events going out, though I see nothing in response:

[code][i]<— Transmitting SIP request (920 bytes) to UDP::25825 —>
INVITE sip:6005@:25825;line=zoxehpx5 SIP/2.0
Via: SIP/2.0/UDP :5006;rport;branch=z9hG4bKPjc46e9d72-4e18-43db-af7f-a07d0b384abc
From: “” <sip:@>;tag=f63f6639-c200-4625-854c-b3ce2a89e7f2
To: <sip:6005@;line=zoxehpx5>
Contact: <sip:fadd65a5-ecab-4dab-a1c3-4fd455c4c925@:5006>
Call-ID: 91cff3f8-dbb1-42ae-a930-10921ee17712
CSeq: 19385 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, REGISTER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 241

v=0
o=- 1630659639 1630659639 IN IP4
s=Asterisk
c=IN IP4
t=0 0
m=audio 10402 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv[/i][/code]

Any ideas very much appreciated. I’m new at this game, although admittedly learning fast :smile:

Thanks

#2

The port doesn’t match the contact - was the call attempt done at a different time? Is the handset behind NAT?

#3

The handsets are behind NAT (the same NAT for both of the handsets in the test), whereas the Asterisk server is not.

Sorry, yes, different times as I experimented - apologies for confusion. I just tried again and the port used is indeed the one the handset is supposedly listening on.

The handset is registered and can make calls.
If I go into the handset’s settings and ask it to re-register, it starts accepting calls once again, for a time (half an hour or an hour, something like that).

The handset has a SIP Trace function, which suggests that no traffic is coming its way when it is supposedly being called.

Here are the PJSIP.conf settings:

[code][6005]
type=endpoint
context=from-internal
disallow=all
allow=ulaw
auth=auth6005
aors=6005
force_rport=yes
direct_media=no
rtp_symmetric=yes
trust_id_outbound=yes
callerid=“TestA” <6005>
rewrite_contact=yes

[auth6005]
type=auth
auth_type=userpass
password=MYPASSWORD
username=6005

[6005]
type=aor
max_contacts=1
remove_existing=yes[/code]

#4

You need to set the qualify_frequency option. Without it the NAT mapping may be closed and any traffic to the phone will be dropped.

#5

Thanks, that seems to have made the difference - the handsets seem to be able to last the day now :smile:

I noticed overnight that one handset doesn’t respond to calls in the morning. It lists as available but doesn’t respond to an INVITE. The only discernible difference is that the Contact URL looks different… it has ;line=jgj358b3 appended to the end whereas the other registrations do not when viewed using “pjsip show endpoints”. Any idea what that means?

Thanks so much

#6

It’s an opaque parameter probably used to match an INVITE request with a virtual ‘line’ so the device knows what registration the INVITE is a result of. Nothing abnormal.

#7

I have a problen with asterisk, when I make a call from asterisk’s extension to mobile number, if hangup mobile without answer asterisk still calling and I dont why. Please can you help me

#8

Please start a new topic when asking unrelated questions. Also, please provide relevant details like:

  1. OS flavor and version
  2. Asterisk version
  3. The relevant dialplan section using ‘dialplan show x’
  4. A text capture of the console log (with ‘verbose’ and ‘debug’ set greater than 2) showing a call that demonstrates the issue.

Please wrap all the above in ’preformatted text' tags so the forum software doesn’t eat important characters like line endings and dollar signs.

#9

I’d add to that, the channel technology used, and in the case of DAHDI, whether analogue, and if DAHDI and digital, the signalling protocol, although we should be able to deduce the technology from the Dial arguments, in the dialplan.