Call-limit hangup cause 17

Asterisk Asterisk SIP
1

I set a call-limit for one peer, by using call-limit in sip.conf. The problem is that when I can sent more calls than the limit, I get 503 SIP, and 17 as a busy. It’s like this:

Session Initiation Protocol (503)
Status-Line: SIP/2.0 503 Service Unavailable
Message Header
Via: SIP/2.0/UDP 192.168.0.26:5066;branch=z9hG4bK-d8754z-87283e4449a77328-1—d8754z-;received=192.168.0.26;rport=5066
From: "user1"sip:user1@185.140.25.103;transport=UDP;tag=cf55032f
To: sip:1111@185.140.25.103;transport=UDP;tag=as6b30aa10
Call-ID: YTRkZmVjZWE0OTBkOTIyY2I3ZDcwNThkNDFkMzViOTM.
CSeq: 1 INVITE
Server: VoIP server
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-Asterisk-HangupCause: User busy
[Expert Info (Note/Undecoded): Unrecognised SIP header (X-Asterisk-HangupCause)]
X-Asterisk-HangupCauseCode: 17
[Expert Info (Note/Undecoded): Unrecognised SIP header (X-Asterisk-HangupCauseCode)]
Content-Length: 0

It’s a bug I think because 503 never maps to 17. How to change it? In cdr’s I have lots of 17 codes which is not real code.

2

Can you provide the console log for this?

3

Here You are:

<— SIP read from UDP:xxx.xxx.xxx.xxx:5066 —>
INVITE sip:212131231@xxx.xxx.xxx.xxx;transport=UDP SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5066;branch=z9hG4bK-d8754z-d22716862f44766c-1—d8754z-
Max-Forwards: 70
Contact: sip:user1@xxx.xxx.xxx.xxx:5066;transport=UDP
To: sip:212131231@xxx.xxx.xxx.xxx;transport=UDP
From: "user1"sip:user1@xxx.xxx.xxx.xxx;transport=UDP;tag=1fb21e5b
Call-ID: NDMyODhkNjI1NjA2MjJiNzFkNDk2MTJhNjNmMTg5NGI.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, X-cisco-serviceuri
User-Agent: Zoiper rev.14736
Allow-Events: presence, kpml
Content-Length: 185

v=0
o=Z 0 0 IN IP4 xxx.xxx.xxx.xxx
s=Z
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 8002 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->
— (14 headers 10 lines) —
Sending to xxx.xxx.xxx.xxx:5066 (NAT)
Sending to xxx.xxx.xxx.xxx:5066 (NAT)
Using INVITE request as basis request - NDMyODhkNjI1NjA2MjJiNzFkNDk2MTJhNjNmMTg5NGI.
Found peer ‘user1’ for ‘user1’ from xxx.xxx.xxx.xxx:5066
== Using SIP RTP CoS mark 5
Found RTP audio format 8
Found RTP audio format 101
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - (alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port xxx.xxx.xxx.xxx:8002
Looking for 212131231 in fax (domain xxx.xxx.xxx.xxx)
sip_route_dump: route/path hop: sip:user1@xxx.xxx.xxx.xxx:5066;transport=UDP

<— Transmitting (NAT) to xxx.xxx.xxx.xxx:5066 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5066;branch=z9hG4bK-d8754z-d22716862f44766c-1—d8754z-;received=xxx.xxx.xxx.xxx;rport=5066
From: "user1"sip:user1@xxx.xxx.xxx.xxx;transport=UDP;tag=1fb21e5b
To: sip:212131231@xxx.xxx.xxx.xxx;transport=UDP
Call-ID: NDMyODhkNjI1NjA2MjJiNzFkNDk2MTJhNjNmMTg5NGI.
CSeq: 1 INVITE
Server: VoIP server 51
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:212131231@xxx.xxx.xxx.xxx:5060
Content-Length: 0

<------------>
– Executing [212131231@fax:1] Dial(“SIP/user1-0000000a”, “SIP/212131231@developer”) in new stack
== Using SIP RTP CoS mark 5
– Couldn’t call SIP/212131231@developer
== Everyone is busy/congested at this time (0:0/0/0)
– Auto fallthrough, channel ‘SIP/user1-0000000a’ status is ‘CHANUNAVAIL’

<— Reliably Transmitting (NAT) to xxx.xxx.xxx.xxx:5066 —>
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5066;branch=z9hG4bK-d8754z-d22716862f44766c-1—d8754z-;received=xxx.xxx.xxx.xxx;rport=5066
From: "user1"sip:user1@xxx.xxx.xxx.xxx;transport=UDP;tag=1fb21e5b
To: sip:212131231@xxx.xxx.xxx.xxx;transport=UDP;tag=as53d590a6
Call-ID: NDMyODhkNjI1NjA2MjJiNzFkNDk2MTJhNjNmMTg5NGI.
CSeq: 1 INVITE
Server: VoIP server 51
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-Asterisk-HangupCause: User busy
X-Asterisk-HangupCauseCode: 17
Content-Length: 0

<------------>

<— SIP read from UDP:xxx.xxx.xxx.xxx:5066 —>
ACK sip:212131231@xxx.xxx.xxx.xxx;transport=UDP SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5066;branch=z9hG4bK-d8754z-d22716862f44766c-1—d8754z-
Max-Forwards: 70
To: sip:212131231@xxx.xxx.xxx.xxx;transport=UDP;tag=as53d590a6
From: "user1"sip:user1@xxx.xxx.xxx.xxx;transport=UDP;tag=1fb21e5b
Call-ID: NDMyODhkNjI1NjA2MjJiNzFkNDk2MTJhNjNmMTg5NGI.
CSeq: 1 ACK
Content-Length: 0

<------------->
— (8 headers 0 lines) —
Really destroying SIP dialog ‘NDMyODhkNjI1NjA2MjJiNzFkNDk2MTJhNjNmMTg5NGI.’ Method: ACK

After this call I get this in log:

[Dec 14 10:37:21] NOTICE[8356][C-0000000c] chan_sip.c: CALL to peer ‘developer’ rejected due to usage limit of 1
I want to add it’s an Asterisk 11.22.0. Have You got any idea?

4

Do You have any idea?

5

Not really - you can explicitly control the cause code by passing it to the Hangup command. You would need to examine things after the Dial() to determine what you would want to pass back. That might alter the result.

6

So It seems to be a bug. It shouldn’t be like that. If I use dial, how I can make a hangup if I limit calls in sip.conf not in dialplan? What do You mean by: “examine things after the Dial() to determine what you would want to pass back”?

7

You can examine the HANGUPCAUSE and DIALSTATUS variables after your dial.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_HANGUPCAUSE

https://wiki.asterisk.org/wiki/display/AST/Dial+Channel+Variables

https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_Dial

8

I get 17 in HANGUPCAUSE,

9

That looks correct to me based on this table:

https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings

10

Correct? If a Call-limit is triggered, there will be cause code 17 as a busy? The same busy code which means, that the end user is busy. Guys, do You really think it’s a proper behaviour?

11

Hello, is anybody out there who can help? I don’t think this cause is correct, 17 is a code where real user is busy. In my cause, the call didn’t come to end user. I think cause 34 would be better.

12

I think some people would expect 17. A call-limit sets a maximum, if that maximum is set then they are busy and can’t accept the call. 34 would also be reasonable. It’s not a clear mapping for the scenario.

13

I don’t think they’d expect it, trust me;-) If You’re in telco, busy tone on peer, that is full of calls, it’s a big bug. Imagine this scenario. Lots of Carriers can route calls. They route it to other carriers using cause code. If they get 17 code on one peer, they wouldn’t route it to other peer/carrier, so calls can’t be routed. Only 34 is a code They can route again, cause it means, that channel is not available.

14

That’s dependent on the specific network layout and how you are using connections between Asterisk and other things. The call-limit option is, for the vast majority of people, for limiting the number of calls an endpoint can do. In that case the endpoint itself should be considered busy and you shouldn’t try something else. That is: You shouldn’t fail over to another route.

If you are using call-limit for the purposes of limiting trunks, then yes, it makes sense.

15

Most people use call limits on phones, not trunks, and do so because IP phones can accept multiple calls.

Historically, backbone networks have been circuit switched and the equipment engaged condition is determined by not finding another free circuit on the route.

Now there is a move to IP based networks, for the backbone, I don’t know how congestion control is handled, but I doubt it is by the equivalent of call limits.

Your requirement for equipment engaged, rather than subscriber busy, is a relatively unusual one, so you will need to adjust the cause code yourself.

16

Now I see, You’re both definitely right. Thanks anyway! Have a good weekend;-)