I’m running asterisk svn-branch 1.2-r45134
my conf files are bascially stock.
in extensions.conf I have
[trunktollfree]
exten => _91800NXXXXXX,1,Dial(SIP/9${EXTEN:1}@sip-proxy-out,r)
When I dial 918004MYXBOX (918004699269) it just rings and rings and rings and eventually just disconnects. When I remove the “r” from that line above then I hear the computer speaking (as I am connected) but asterisk doesn’t know i’m connected so eventually disconnects the call.
so on asterisk con I see the SIP/sip-proxy-out… is ringing
then the "… is making progress passing it to …"
and thats it. It seems because when you dial that 800 number the computer on the other end picks up so fast asterisk doesn’t know it.
Everything else on this system works great. This is the only issue where the other end picks up before the phone even technically rings asterisk doesn’t know it and never logs to console that anyone answered.
Any solution here? Once I can fix this and one other issue I can finally be rid of my CM4.1 setup.
first why the 9${EXTEN:1}? why strip the 9 if you’re just gonna add it back in again?
second this is happening correctly. Many high volume customers negotiate with their carriers to allow the customer moving through the IVR to be considered ‘progress’ data, aka ringing. So technically the number you called hasn’t actually picked up, and they aren’t getting billed for your call.
the ‘is making progress passing it to’ means that the remote end is providing call progress (ringing or other sound) and it is being passed, which is happening correctly. So its not that the other end picked up too fast- its that technically the other end hasn’t picked up at all.
theoretically if you are not using a ring timeout asterisk shouldn’t disconnect. this may be an issue with your voip provider or other parts of your setup.
I didn’t mess with the configs much and am “learning as I go”. Right now my asterisk is a sip trunk behind the cm4.1 i have. In the end I’m going to have asterisk direct to my voice router so I figure I’ll have to mess with the configs to get that accomplished.
unfortuneatley even though that link and what you said make sense, I have no clue how to get my calls to that 800 number working. I can dial the toll free number in that link and works fine. Even if ast didn’t disconnect it still wouldn’t be right as all I would hear is ringing. and if i remove the “r” then I’ll get dead air when calling normal 800 numbers and not know what is going on.
So where do i have to fix this or where can this be addressed? Asterisk? my cisco 1760 voice gateway? My bellsouth T1 provider?
My call manager 4.1 which goes to same 1760 and bell T1 can call that 800 number fine. This ast box setup as a sip trunk in the call manager is having the issue which is why I though I could resolve within ast somehow.
rtptimeout in sip.conf is set to 60. that seems to be when ast disconnects the call.
I’ve tried changing progressinband in sip.conf from never to yes or no but it didnt help.
progressinband might want to be yes although that won’t change anything
the bugs you linked also aren’t the problem, they involve situations that can cause one way audio. Asterisk currently uses the incoming RTP source as a trigger to send the next outgoing RTP packet, without using its own timing. The bugs you linked address this problem. However both sides (phone and provider) are both sending audio so this isn’t a problem.
You can try increasing the RTP timeout but I doubt that will help
The google group link you posted is exactly the problem- i was actually thinking about that post when I read yours
the ‘r’ flag is actually causing a problem, there are a select few situations where ‘r’ is a good idea, this isn’t one of them. You don’t ever really want ‘r’ on an outgoing trunk because it will override whatever progress the trunk sends and give you plain ringing, even if ringing is not appropriate. That was happening to you earlier.
As for what to do, what is different between the CM and *? are they both linked via SIP? Do they have different settings? Perhaps the IP phone you are using has a timeout of some kind?
The problem as I see it is that somewhere, something is giving up after xx seconds of ‘ringing’. I believe this is either the IP phone you are using, Asterisk (seems less likely), or the 1760.
A good way to pin this down would be debugs.
First try sip debug peer sip-proxy-out. This will print debug info for the ‘sip-proxy-out’ thing, which is presumably the 1760. When the call drops, watch to see which side hangs up first.
You can do the same thing to your IP phones.
The problem is probably not with your T1 because it works fine the other way.
So is there anything I shoud use instead of the r flag? or just leave it off?
The difference between cm and asterisk is asterisk is a sip trunk on the cm. CM is the only one talking to my voice gateway. The sip_proxy-out for asterisk is CM box. So i have my cisco 7960’s and 7970’s behind the CM that don’t have this problem.
I also have phones running sip behind the asterisk. They are 7960’s and 7970’s and a polycom 601. All on a sip image. Only the polycom has a DID line that is configured in cm by a route pattern to route to the sip trunk. but even the phones without a did can call out through the CM.
in the code section below is the debug of the call from the polycom. Again, all IP phones behind the ast have this issue and none that are directly attached and sccp on the CM.
*CLI> sip debug peer sip_proxy-out
SIP Debugging Enabled for IP: 10.2.19.10:5060
-- Executing Dial("SIP/3579-095a2080", "SIP/918004699269@sip_proxy-out||r") in new stack
We're at 10.1.19.50 port 11046
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
13 headers, 10 lines
Reliably Transmitting (no NAT) to 10.2.19.10:5060:
INVITE sip:918004699269@10.2.19.10 SIP/2.0
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>
Contact: <sip:3579@10.1.19.50>
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Mon, 16 Oct 2006 20:17:48 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 212
v=0
o=root 26250 26250 IN IP4 10.1.19.50
s=session
c=IN IP4 10.1.19.50
t=0 0
m=audio 11046 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
---
-- Called 918004699269@sip_proxy-out
<-- SIP read from 10.2.19.10:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>;tag=16787310
Date: Mon, 16 Oct 2006 20:17:48 GMT
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 INVITE
Allow-Events: telephone-event
Content-Length: 0
--- (9 headers 0 lines) ---
<-- SIP read from 10.2.19.10:5060:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>;tag=16787310
Date: Mon, 16 Oct 2006 20:17:48 GMT
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK
Allow-Events: telephone-event
Remote-Party-ID: <sip:918004699269@10.2.19.10>;party=called;screen=no;privacy=off
Contact: <sip:918004699269@10.2.19.10:5060>
Content-Length: 0
--- (12 headers 0 lines) ---
-- SIP/sip_proxy-out-095a75c0 is ringing
<-- SIP read from 10.2.19.10:5060:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>;tag=16787310
Date: Mon, 16 Oct 2006 20:17:48 GMT
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK
Allow-Events: telephone-event
Remote-Party-ID: <sip:918004699269@10.2.19.10>;party=called;screen=no;privacy=off
Contact: <sip:918004699269@10.2.19.10:5060>
Content-Disposition: session;handling=required
Content-Type: application/sdp
Content-Length: 223
v=0
o=CiscoSystemsCCM-SIP 2000 1000 IN IP4 10.2.19.10
s=SIP Call
c=IN IP4 10.2.19.10
t=0 0
m=audio 25658 RTP/AVP 0 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--- (14 headers 11 lines) ---
Found RTP audio format 0
Found RTP audio format 101
Peer audio RTP is at port 10.2.19.10:25658
Found description format PCMU
Found description format telephone-event
Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
-- SIP/sip_proxy-out-095a75c0 is making progress passing it to SIP/3579-095a2080
Scheduling destruction of call '43b560b972154d4176742cdf1b2d5a27@10.1.19.50' in 32000 ms
Reliably Transmitting (no NAT) to 10.2.19.10:5060:
CANCEL sip:918004699269@10.2.19.10 SIP/2.0
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>
Contact: <sip:3579@10.1.19.50>
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
---
== Spawn extension (default, 918004699269, 1) exited non-zero on 'SIP/3579-095a2080'
<-- SIP read from 10.2.19.10:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>
Date: Mon, 16 Oct 2006 20:18:48 GMT
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
Content-Length: 0
CSeq: 102 CANCEL
--- (8 headers 0 lines) ---
<-- SIP read from 10.2.19.10:5060:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>;tag=16787310
Date: Mon, 16 Oct 2006 20:18:48 GMT
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 INVITE
Allow-Events: telephone-event
Remote-Party-ID: <sip:918004699269@10.2.19.10>;party=called;screen=no;privacy=off
Content-Length: 0
--- (10 headers 0 lines) ---
Transmitting (no NAT) to 10.2.19.10:5060:
ACK sip:918004699269@10.2.19.10 SIP/2.0
Via: SIP/2.0/UDP 10.1.19.50:5060;branch=z9hG4bK43f92dd7;rport
From: "Lee Polycom" <sip:3579@10.1.19.50>;tag=as53ec2f3f
To: <sip:918004699269@10.2.19.10>;tag=16787310
Contact: <sip:3579@10.1.19.50>
Call-ID: 43b560b972154d4176742cdf1b2d5a27@10.1.19.50
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
---
Destroying call '43b560b972154d4176742cdf1b2d5a27@10.1.19.50'
thanks a lot for all your help.
oh and the reason ast is a sip trunk as this is the best migration path from a full blown CM install to an Asterisk install. Once everything is working I take CM out as the middle man but it doesn’t seem CM being the middle man has anything to do with this problem.
[quote=“IronHelix”]
The problem as I see it is that somewhere, something is giving up after xx seconds of ‘ringing’. I believe this is either the IP phone you are using, Asterisk (seems less likely), or the 1760.
That should help you find the problem.[/quote]
I’m not sure that is accurate. the rtptimeout is giving up after xx seconds of thinking no one is answering on the other end. The problem isn’t that asterisk is giving up but rather that it isn’t realizing the 800 number computer picked up so damn fast no ringing took place. It seems to me asterisk is waiting for that “answer” and never getting it. and the problem isn’t that * never got it as in this situation it seems it wasn’t supposed to because of this "Many high volume customers negotiate with their carriers to allow the customer moving through the IVR to be considered ‘progress’ data, aka ringing. So technically the number you called hasn’t actually picked up, and they aren’t getting billed for your call."
so then how does ast know not to do the rtptimeout if it doesn’t think anyone answered?
just leave off the ‘r’ flag. You don’t need it anyway, just do like
dial(SIP/1234) if you dont have a ring time.
rtptimeout does not apply here- it says to hang up the call if there is no RTP data coming in for XX seconds. RTP (audio) data is coming in from both sides so this will not be hit. It doesn’t matter if the call is answered or not, because both sides are sending a healthy RTP stream.
Remember that * never got the answer because there is no answer to get yet- as far as * is concerned, you are hearing ringing (progress). I don’t know if you’ve ever called internationally and gotten a european ringing tone but it works the same way. The USA phone switch doesn’t know how to make a euro ring sound, but the euro switch is sending it as progress so its passed to you, and is still considered ringing. The line isn’t active and you still aren’t charged for the call, because the call hasn’t started yet.
After however many seconds, Asterisk gets a cancel request and is told to hang up. I assume 10.0.19.50 is the CM server? If so then the CM server is giving up. Check its timeouts, it is where your problem lies.
If that IP is your phone then check it for timeouts…
-- SIP/sip_proxy-out-095a75c0 is making progress passing it to SIP/3579-095a2080
Scheduling destruction of call '43b560b972154d4176742cdf1b2d5a27@10.1.19.50' in 32000 ms
Reliably Transmitting (no NAT) to 10.2.19.10:5060:
CANCEL sip:918004699269@10.2.19.10 SIP/2.0
The thing is the sip trunk in call manager is pretty straight forward. There is no timeout’s for call manager and its sip trunk. Cm doesn’t care if a call is answered or not when concerned with a sip trunk. CM will let an unanswered line ring forever. The first line of the debug I pasted above is where my call sits most of the time.
Then after 32 seconds the asterisk console throws out the next. That scheduling destruction of call line I’ve found right in my ast source tree that I built from. It seem like asterisk has decided after 32seconds to schedule the destruction of the call and then transmits a cancel sip to the call manager.
Let’s pretend I don’t have call manager even, how is this handled just by asterisk and a gateway?
ok some progress…
at first I had a wireshark trace just with filter of the CM. running another one with phone, cm, and asterisk it turns out it is the polycom phone sending the cancel. The cisco phones (even the ones on sip behind the ast) do not do this. The reason those phones seemed to have the same issue yesterday was because I had the “r” in the dial line as I shouldn’t have had.
So its narrowed down to something in the polycom config…
thanks for all your help.
edit: on timing it, the polycom hangs up after 60 seconds… so hunting for a 60s timeout…
I’ve upgraded the polycom 601 phone to SIP 2.02 and bootrom 3.22 to see if that would help and it didn’t. If anyone knows the magical value within a polycom sip.cfg or .cfg to get this timeout off please let me know.
