Renamed: Problem with SIP calls in 1.4.23x not cancelling!

Asterisk Asterisk Support
1

Can someone please help me out on this one.

I am trying to dial a local SIP extension and an external number (mobile . cell phone) on one number.

exten => 202,1,Dial(SIP/extn202&Local/222@${CONTEXT})
exten => 202,n,HangUp()

exten => 222,1,Wait(5)
exten => 222,n,Dial(SIP/mysipprovider/0427555000)
exten => 222,n,HangUp()

What I would like it to do is to dial the first device / extension and then start ringing my mobile at the same time but around 5 seconds after my desk phone starts ringing.

If I pick up my mobile, my desk phone stops ringing, but if if I pick up my desk phone or the caller hangs up, my mobile phone keeps ringing. The channel stays open.

On the console I get the following message:

I have tried it with a local extension, and while it seems to work OK when the main number is ringing and then picked up, the problem is still there if the caller terminates the call.

Any clues or suggestions.

Thanks in advance
Chris

2

Been chasing around some more and trying various combinations of things. Looks like it works OK with a land line number but fails on a mobile…

If I dial 222 and hang up the extension, I get the same problem

Most confusing. Will be trying another VSP and see what happens. Any comments would be appreciated.

Thanks in advance
:smile:
Chris

3

OK managed to get some useful information (a little over 24 hours of grief, pain and angst later :frowning: )

It seems the problem is in 1.4.23-x

I have gone back to 1.4.22-1 and there is no problem…soooo. I think there is a bug in the chan_sip or something.

Issue:
When I place a call to a public switched network through either of my SIP providers, I get the following things happen with the call.

  • If I call from my SIP extension, to another SIP extension and hang up the call before the recipient has picked up the phone, the call terminates OK. life is sweet
  • If I place a call to an outside number that is on the public network and I hang up afte the recipient has picked up the phone, the call terminates OK. life is still beautiful
  • If I place a call to an outside number that is on the public network and I hang up before the recipient has picked up the phone, the recipients phone keeps on a ringin’ until the service times out or the call is rejected (on a mobile)This is where my life starts to fall apart

Now this only occurs with 1.4.23 and 1.4.23-1. I went back to 1.2.x and didn’t have the problem. After googling some of my SIP tracings, I found a single reference to this exact problem in 1.4.23 so I dusted off the source of 1.4.22 and voila, things are working again…I can stop cleaning the guns

I have managed to capture some SIP traces which are included below:
I will try to highlight the bits that may mean somthing to someone:
The numbers and my IP address has been changed

The above example was using the dial command with a 10 second time out so the call is terminated by asterisk.

My sip.conf is as follows

[general]
;context=default                 ; Default context for incoming calls
;allowoverlap=no                 ; Disable overlap dialing support. (Default is yes)
;realm=asterisk          ; Realm for digest authentication
bindport=5060                   ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=no                    ; Enable DNS SRV lookups on outbound calls

;useragent=asterisk
maxexpiry=3600                  ; Maximum allowed time of incoming registrations
                                ; and subscriptions (seconds)
minexpiry=60                    ; Minimum length of registrations/subscriptions (default 60)
;mohinterpret=default
;mohsuggest=default
;vmexten=Voicemail

language=en                     ; Default language setting for all users/peers
dtmfmode = rfc2833              ; Set default dtmfmode for sending DTMF. Default: rfc2833

;alwaysauthreject = yes          ; When an incoming INVITE or REGISTER is to be rejected,
                                ; for any reason, always reject with '401 Unauthorized'
                                ; instead of letting the requester know whether there was
                                ; a matching user or peer for their request

[extn201]
type=friend 
context=extn201
; Authentication records
username=extn201
secret=shhhh!!!!
; Network Setup
host=dynamic
defaultip=60.0.0.666
port=5060
nat=yes
; SIP Registration Stuff
callerid="Extn 201"					; Caller ID when dialling
canreinvite=no
qualify=yes
insecure=port,invite
; Codecs and DTMF
disallow=all
; allow=g729
allow=ulaw 
;allow=alaw
;allow=gsm 
dtmfmode=rfc2833

; For Outbound calls
[engin]
type=peer
; Authorisation 
realm=mobileinnovations.com.au
host=byo.engin.com.au
username=0290111666
secret=nottelling!
fromdomain=byo.engin.com.au
fromuser=0290111666
; Network Settings
nat=yes
port=5060
qualify=yes
canreinvite=no 
reinvite=no 
pedantic=no
insecure=port,invite
defaultexpirey=1800
maxexpirey=3600
; Codecs and DTMF
disallow=all
;allow=g729
allow=ulaw 
;allow=alaw
;allow=gsm 
;dtmfmode=rfc2833

My extensions.conf

[extn201]
exten => 200,1,Answer()
; Dial and bail out after 10 seconds if not answered
exten => 200,n,Dial(SIP/engin/0427999666,10)
exten => 200,n,HangUp()

Can someone please give me some heads up on whether or not they are experiencing the same issues, or, its just my immagination and I should go back to cleaning the guns, nice shiny clean guns :smiling_imp:

Any other pointers would be most gratefully received.

Have fun.

Cheers
Chris

ps. The voices in my head are telling me now that "so long as I act normal, everything will be OK :open_mouth: "

4

I got exactly the same problem using Asterisk 1.4.23-1. Same SIP debug information, same error messages. that means you’re not out of your mind - unless we both are :wink:

The phones one is using seems not to be of importance, that really is a very specific asterisk issue.

Is there any solution around other than downgrading?

Thanks for help in advance
Stefan

5

Crazy likes company :laughing:

I’m backwards and forwardsing between myself and one of the IP VSP services I use trying to find the cuase of the issue, but as it is two separate providers it does it with, there is definately a problem with the SIP channel somehwere. I’m going to try it with a couple of free signup providers and see if the same problem exisits.

I ended up using 1.4.22-2 and I am relatively happy there.

Needed to bog up a minor (major) call back issue with park and orbit functionality and the call back destination getting overwritten. Did that with a small hack to the res_features.c source code as per a bug discussion and catching the stray call in the dialplan.

So far everything is delicatly balanced and stable. We go into production on Monday so fingers XXXed

I’m keeping an eye on the newer releases, but I won’t be rolling anything into a production environment until it has been through the ringer and I a 100% sure its up for it.

Let me know how you go.

Cheers
Chris

6

as far as i can tell the problem doesn’t exist as long as you don’t play with outgoing number signaling. we do that in order to have several outgoing numbers within a trunk. the thing is, the problem was not existing until we used this feature, eg.

extensions.conf (10, 13 are internal numbers):
CID_10 = 41123123123
CID_13 = 41123123123
[macro-trunkdial-failover-0.3]
…
exten = s,3,Set(CALLERID(num)=${IF($[${LEN(${CID_${CALLERID(num)}})} > 2]?${CID_${CALLERID(num)}}:)})
…

but i’d have to verify that again. in fact i strongly consider a fallback to 1.4.22-2 as we need a stable version for deployment as well. good luck with the launch!

keep me posted if you hear more about this topic.
cheers
stefan

7

Will do. I’ll have a look into it and get back to you.

We load the caller’s name in the CALLERID(name) into the call as it seems to travel across our service provider’s network and show’s up on the CID on the other system, which is cool :smile:

While somewhat off topic:

WIth 1.4.22-x I have an issue with call parking:

  • If you do an attended transer the caller to a parking slot, the call is returned back to the caller, not the person who parked the call, when the parked call times out. It is either lost, or their own phone rings back with their own call.

  • If you do an unattended park & orbit, it will dial back the correct extension the first time, if you dont answer the call and just hit park & orbit, the call is returned to its self and dies when it times out a second time.

If you change res_features.c and replace the following if() line with something that will always return false and bypass the chunk of code which mangles the return destination channel (somewhere around Line 1770):

    .....
    if (tms > pu->parkingtime) {
        ast_indicate(chan, AST_CONTROL_UNHOLD);
        /* Get chan, exten from derived kludge */
        
        // Get rid of this original line
        //if (pu->peername[0]) {

        // And replace it with FALSE so it never executes
        if(0) {
            char *peername = ast_strdupa(pu->peername);
            char *cp = strrchr(peername, '-');
            .....etc

The timed out call will jump back to extension s in the context where the call was parked. So you can put the following in your dialplan:

[parkinglot]
;; Call Parking
include => parkedcalls
exten => 700,1,Answer()
exten => 700,n,Park()

exten => 701,hint,park:701@parkedcalls
exten => 701,1,Answer()
exten => 701,n,ParkedCall(701)
exten => 701,n,Hangup()

...etc

; Parking lot time out
; Thank them for being patient
exten => s,1,Playback(queue-thankyou)
; Send them back to the Operator
exten => s,n,Goto(operator,200,1)

or if you want to, include the parking context as part of the extensions context and recirect it back to the device that parked the call.

…If that makes sence… I haven’t been interacting with humans too much lately. :confused:

Also managed to get a solution for directing a call to a specific parking lot :smiley:

more on that if you want

Cheers
Chris

8

just as you said, no more problems with Asterisk 1.4.22.2. :wink:
Thus I can live with the downgrade as long as i don’t run into further problems.

did you ever check out the Asterisk-GUI 2.0? Still got a couple of issues there like Trunks showing unregistered even though they appear registered in “sip show registry” and work…

9

I must admit, I have not touched the GUI just yet. On the to do list, but need to get things working at the phones first.

Using Snom 320s and 360s. Have an M3 to play with for a week too :smile: So far all is good. Still some nagging minor issues, but nothing fatal.

I’ll keep you informed. Thanks for the heads up on things

Cheers
Chris

10

asterisk 1.4.22.2 proved to be stable, so we stick with that for now. next project will be a number reverse lookup with tel.search.ch. In the end, we’d like to see the name of the caller instead of the number only. other than that, the isdn-part is still not tested :smile:

We tested snom 300, 320 and 360 as well as the M3. apart from snom, we also have installations with siemens and astra phones but imho snom is the phone causing the least troubles at the moment :wink:

dont worry, the asterisk-gui is not quite the perfect solution one is looking for. we still have various problems with trunks and idsn-hardware… but in a whole the GUI works and fits most of our needs.

oh… we probably shouldn’t make this our pvt little forum :wink:

11

Does anyone know if the latest 1.4.24 has fixed this issue ???
Cheers
Chris

12

[quote=“MrFidget”]Does anyone know if the latest 1.4.24 has fixed this issue ???
Cheers
Chris[/quote]

I’ve got the problem on 1.4.24.1 using Aastra phones. Seems to work fine with Grandstream ones though shrug.

13

the CANCEL which asterisk is sending looks fine. I am not sure why the upstream carrier would send back a 481. I just took a quick look, but the things you should take note of in the CANCEL are

from tag
to tag
call-id
branch

In theory, if all those match, there is no reason the upstream carrier shouldn’t be able to match the transaction…

I would say your best bet is to send the provider that SIP trace and say… why did you return a 481? Might be the quickest path to tracking this down.

14

I would have to do a little reading of the RFC, but I think I may seee the problem here.

It looks like the branch parameter is different in the INVITE and the CANCEL.

INVITE sip:0427999666@byo.engin.com.au SIP/2.0
Via: SIP/2.0/UDP 203.0.0.666:5060;branch=z9hG4bK41c14245;rport
From: “Extn 201” sip:0290111666@byo.engin.com.au;tag=as5d20bf3a
To: sip:0427999666@byo.engin.com.au
Contact: sip:0290111666@203.0.0.666
Call-ID: 0b2dad53366879874855d33763f50e46@byo.engin.com.au
CSeq: 103 INVITE
User-Agent: asterisk
Max-Forwards: 70
Proxy-Authorization: Digest username=“0290111666”, realm=“mobileinnovations.com.au”, algorithm=MD5, uri="sip:0427999666@byo.engin.com.au", nonce=“EQeDUWj8kyQsKU05xw7tBw==_32f0a”, response=“f1578d4c021fdc211d036cbe94049e58”, qop=auth, cnonce=“05883571”, nc=00000001
Date: Wed, 11 Feb 2009 23:48:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 334

CANCEL sip:0427999666@byo.engin.com.au SIP/2.0
Via: SIP/2.0/UDP 203.0.0.666:5060;branch=z9hG4bK380c9286;rport
From: “Extn 201” sip:0290111666@byo.engin.com.au;tag=as5d20bf3a
To: sip:0427999666@byo.engin.com.au
Call-ID: 0b2dad53366879874855d33763f50e46@byo.engin.com.au
CSeq: 103 CANCEL
User-Agent: asterisk
Max-Forwards: 70
Content-Length: 0

15

It is a ‘branch’ problem. This is a known ‘bug’ - but, so far, I haven’t seen a patch for 1.4-current to solve it.

16

I couldn’t find a bug report on it. Do you know if any of the devs are even aware of the problem?

17

There is one - as well as a patch. The patch wouldn’t apply against my version though. I’m not sure what the ‘report code’ is - but it is there somewhere.

EDIT : Found this on the ‘user’ list - mail-archive.com/asterisk-us … 21883.html

I guess the ‘fix’ never made it in to ‘1.4-current’ :smile:.