Koozali.org: home of the SME Server
Obsolete Releases => SME VoIP (Asterisk, SAIL etc) => Topic started by: compsos on April 20, 2009, 01:48:44 AM
-
Hi
We have an account with World Dial Point who use a PortaOne system. We can place calls and have done for quite a while. We have now taken out a DID service but it is always answered (very quickly) by a message at their system that "The person at...is unavailable". I do not think we are seeing anything of the call
Their support has suggested that it is the useragent string of "Asterisk PBX" needs to be changed to something like PAP2. The trunk stanza shows useragent of PAP2T. But the 'sip show peer 0740840650' returns a blank useragent field. Changing the stanza does not change this test and the support still says we are passing the "Asterisk PBX" through to them.
Googling shows that problems between Asterisk and PortaOne is not uncommon. PortaOne have released a Radius client for Asterisk. Is that what we need to receive incoming calls from the DID?
This I think is the only evidence of the incoming call from my mobile.
<--- SIP read from 203.176.185.10:5060 --->
INVITE sip:61740840650@220.245.107.242 SIP/2.0
Record-Route: <sip:203.176.185.10;ftag=fa503ca7f97694c630eb69dab4b58782;lr>
Via: SIP/2.0/UDP 203.176.185.10;branch=z9hG4bK4bde.503177c818797d1f1278a8ae92d06f43.0
Via: SIP/2.0/UDP 203.176.185.10:5061;branch=z9hG4bK8d66d0bae6730ce3459072f64b76585e;rport=5061
Max-Forwards: 16
From: <sip:0429338896@203.176.185.10>;tag=fa503ca7f97694c630eb69dab4b58782
To: <sip:61740840650@203.176.185.10>
Call-ID: call-71605C32-370F-2C10-0308-DEDA@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:203.176.185.10:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 876176738-909730608-1717986918-1684366392
h323-conf-id: 876176738-909730608-1717986918-1684366392
H323-credit-time: 7200
Content-disposition: session
Content-Length: 286
Content-Type: application/sdp
v=0
o=Sippy 151550124 0 IN IP4 203.176.185.10
s=VoipCall
t=0 0
m=audio 56392 RTP/AVP 18 4 8 0 101
c=IN IP4 203.176.185.10
a=rtpmap:18 g729/8000/1
a=abcde:20
a=rtpmap:4 g723/8000/1
a=rtpmap:8 pcma/8000/1
a=rtpmap:0 pcmu/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
<--- Reliably Transmitting (no NAT) to 203.176.185.10:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 203.176.185.10;branch=z9hG4bK4bde.503177c818797d1f1278a8ae92d06f43.0;received=203.176.185.10
Via: SIP/2.0/UDP 203.176.185.10:5061;branch=z9hG4bK8d66d0bae6730ce3459072f64b76585e;rport=5061
From: <sip:0429338896@203.176.185.10>;tag=fa503ca7f97694c630eb69dab4b58782
To: <sip:61740840650@203.176.185.10>;tag=as178f3fd7
Call-ID: call-71605C32-370F-2C10-0308-DEDA@203.176.186.10~1o
CSeq: 200 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="48ad6d39"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog 'call-71605C32-370F-2C10-0308-DEDA@203.176.186.10~1o' in 6400 ms (Method: INVITE)
*CLI>
<--- SIP read from 203.176.185.10:5060 --->
ACK sip:61740840650@220.245.107.242 SIP/2.0
Via: SIP/2.0/UDP 203.176.185.10;branch=z9hG4bK4bde.503177c818797d1f1278a8ae92d06f43.0
From: <sip:0429338896@203.176.185.10>;tag=fa503ca7f97694c630eb69dab4b58782
Call-ID: call-71605C32-370F-2C10-0308-DEDA@203.176.186.10~1o
To: <sip:61740840650@203.176.185.10>;tag=as178f3fd7
CSeq: 200 ACK
User-Agent: Sip EXpress router (0.9.6 (i386/freebsd))
Content-Length: 0
--- (14 headers 0 lines) ---
Really destroying SIP dialog '06f12004537182670d67405e7e984fb9@192.168.36.1' Method: OPTIONS
Really destroying SIP dialog 'call-71605C32-370F-2C10-0308-DEDA@203.176.186.10~1o' Method: ACK
We have reset the type from peer to friend but 'sip reload' returns
[Apr 20 09:41:00] WARNING[12209]: chan_sip.c:17983 reload_config: Section '0740840650' lacks type
[Apr 20 09:41:00] WARNING[12209]: chan_sip.c:17983 reload_config: Section 'wdp_out' lacks type
'sip show peer 0740840650' returns
* Name : 0740840650
Secret : <Set>
MD5Secret : <Not set>
Context : mainmenu
Subscr.Cont. : <Not set>
Language :
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
FromUser : 61740840650
Callgroup :
Pickupgroup :
Mailbox :
VM Extension : asterisk
LastMsgsSent : 32767/65535
Call limit : 0
Dynamic : No
Callerid : "" <>
MaxCallBR : 384 kbps
Expire : -1
Insecure : no
Nat : RFC3581
ACL : No
T38 pt UDPTL : No
CanReinvite : No
PromiscRedir : No
User=Phone : No
Video Support: No
Trust RPID : No
Send RPID : No
Subscriptions: Yes
Overlap dial : Yes
DTMFmode : rfc2833
LastMsg : 0
ToHost : sip.bbvoice.com.au
Addr->IP : 203.176.185.10 Port 5060
Defaddr->IP : 0.0.0.0 Port 0
Def. Username: 61740840650
SIP Options : (none)
Codecs : 0x10c (ulaw|alaw|g729)
Codec Order : (g729:20,alaw:20,ulaw:20)
Auto-Framing: No
Status : OK (88 ms)
Useragent :
Reg. Contact :
Has anyone else got a working DID with World Dial Point?
TIA
-
OK...
two things;
you need to set insecure=very (or insecure=port,invite) in your sip definition (you don't need user=friend by the way).
Next you need to create a PTT_DiD_Group trunk entry of 61740840650 to receive and route your inbound call.
Best
S
-
Hi S
Thank you for the reply.
Our User Stanza for the trunk definition already had insecure=port,invite. I have now changed the type back to type=peer. But still the providers recorded message. It is so quick I am suspicious.
The current sip set debug
<--- SIP read from 203.176.185.10:5060 --->
INVITE sip:61740840650@220.245.107.242 SIP/2.0
Record-Route: <sip:203.176.185.10;ftag=92441ef3e2d601aba09469b66b513d7e;lr>
Via: SIP/2.0/UDP 203.176.185.10;branch=z9hG4bKb661.cb2160f0a5b038ab66eefb5f53580251.0
Via: SIP/2.0/UDP 203.176.185.10:5061;branch=z9hG4bK5bb892668911967d45e0349badbb9df8;rport=5061
Max-Forwards: 16
From: <sip:0429338896@203.176.185.10>;tag=92441ef3e2d601aba09469b66b513d7e
To: <sip:61740840650@203.176.185.10>
Call-ID: call-7182373C-710F-2C10-1402-F08F@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:203.176.185.10:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 876176738-1664563555-1717986918-1714436196
h323-conf-id: 876176738-1664563555-1717986918-1714436196
H323-credit-time: 7200
Content-disposition: session
Content-Length: 286
Content-Type: application/sdp
v=0
o=Sippy 140536396 0 IN IP4 203.176.185.10
s=VoipCall
t=0 0
m=audio 35676 RTP/AVP 18 4 8 0 101
c=IN IP4 203.176.185.10
a=rtpmap:18 g729/8000/1
a=abcde:20
a=rtpmap:4 g723/8000/1
a=rtpmap:8 pcma/8000/1
a=rtpmap:0 pcmu/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
<------------->
--- (18 headers 13 lines) ---
Sending to 203.176.185.10 : 5060 (no NAT)
Using INVITE request as basis request - call-7182373C-710F-2C10-1402-F08F@203.176.186.10~1o
Found peer 'peerwdp_out'
server-sos*CLI>
<--- Reliably Transmitting (no NAT) to 203.176.185.10:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 203.176.185.10;branch=z9hG4bKb661.cb2160f0a5b038ab66eefb5f53580251.0;received=203.176.185.10
Via: SIP/2.0/UDP 203.176.185.10:5061;branch=z9hG4bK5bb892668911967d45e0349badbb9df8;rport=5061
From: <sip:0429338896@203.176.185.10>;tag=92441ef3e2d601aba09469b66b513d7e
To: <sip:61740840650@203.176.185.10>;tag=as366733b4
Call-ID: call-7182373C-710F-2C10-1402-F08F@203.176.186.10~1o
CSeq: 200 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="09be00ce"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog 'call-7182373C-710F-2C10-1402-F08F@203.176.186.10~1o' in 6400 ms (Method: INVITE)
server-sos*CLI>
<--- SIP read from 203.176.185.10:5060 --->
ACK sip:61740840650@220.245.107.242 SIP/2.0
Via: SIP/2.0/UDP 203.176.185.10;branch=z9hG4bKb661.cb2160f0a5b038ab66eefb5f53580251.0
From: <sip:0429338896@203.176.185.10>;tag=92441ef3e2d601aba09469b66b513d7e
Call-ID: call-7182373C-710F-2C10-1402-F08F@203.176.186.10~1o
To: <sip:61740840650@203.176.185.10>;tag=as366733b4
CSeq: 200 ACK
User-Agent: Sip EXpress router (0.9.6 (i386/freebsd))
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
-
Did you create the DiD entry?
-
This is the definition.
Trunk DID or IP Name: 61740840650
Carrier Name: PTT_DiD_Group
Technology: DiD
Host:
db selintra show 61740840650
61740840650=lineIO
active=YES
alertinfo=
carrier=PTT_DiD_Group
closedisa=NO
closegreet=None
closeivr=NO
closequeue=None
closeroute=Operator
cluster=default
desc=WDPDID
disa=NO
faxdetect=NO
forceivr=NO
host=
inprefix=
lcl=NO
opengreet=None
openroute=Operator
peername=
queue=None
remotenum=61740840650
swoclip=YES
transform=
zzeor=EOR
Is this correct?
-
send your sip.conf to admin@aelintra.com
cheers
S
-
Gentelmen,
just set in sip headers
useragent=portasipfriendly
simple isn't it??
i was looking this setting for 3 weekes.
-
bbialy
just set in sip headers
useragent=portasipfriendly
That did not work for us. How is your system setup?
-
I use Franks normal system and have had my DID working until his pear shaped software upgrade 2 weeks back. DID hasn't worked since.
The way mine used to work was by changing the registration string to
username:password@ipaddress/DIDnumber
This worked for us until 2 weeks ago
-
Hi Gippsweb
Do you mean "Franks" as in WDP? It might be interesting to excahnge sip debug reports of incoming calls.
We are currently on Sail 2.3.1-3 with Dahdi. What is your setup? Is there a way we can contact you?
-
Hi Gordon,
yes as in WDP, but I'm not on the business service so my sip debug won't be of any help to you....
I'm only on his residential servive which has changed recently.
The business service uses Comvergences service from memory...
-
We log in the same way and it does sound like we have the same problem with the same provider. So doubt if the grade of service is the issue. Selintra & Frank suggested there was a problem with the proxy-authentication but so far have not found a way of correcting it.
We did a session with Frank and modified the user-agent in the general section of the sip.conf file. He said he dialled me on the DiD but we have never been able to dial from outside in. Has frank been able to dial you since the DiD stopped? Also when we do a sip show peer "WDP_DiD" it does not show any useragent string. Are you seeing the same issues?
-
Mine stopped working after they did the software upgrades a week or two back. I wasn't even getting anything off sip debug, which I found very strange.
My registration string changes worked perfectly until the changes at his end..
I've since had some help from his engineers, we've now at least got calls being rejected by my box. But they are USA based and only available late at night AUS time.
-
Software updates being on Sail or WDP?
-
The residential service was had the billing system upgraded and asterisk upgraded to 1.6
-
Ah Frank said they are using with 1.6. So we are connecting to similar if not the same servers. This is a new service for us as we have not needed DiD before or used it. Could it be their upgrade to 1.6 and the proxy-authentication system.
Found a web site with a good and failed sip debug and yes ours is the same as the failed system. never had the working one yet.
http://forum.voxilla.com/asterisk-support-forum/407-proxy-authentication-required-14050.html (http://forum.voxilla.com/asterisk-support-forum/407-proxy-authentication-required-14050.html)
We have never got this after the v= o= s= etc lines.
13 headers, 12 lines
Using latest request as basis request
Sending to 192.168.0.100 : 9169 (NAT)
Found user '420'
Found RTP audio format 3
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 98
Found RTP audio format 100
Found RTP audio format 6
Found RTP audio format 5
Found RTP audio format 101
Peer audio RTP is at port 192.168.0.100:10466
Found description format ilbc
Found description format speex
Found description format telephone-event
Capabilities: us - 0x106 (gsm|ulaw|g729), peer - audio=0x62e (gsm|ulaw|alaw|adpcm|speex|ilbc)/video=0x0 (nothing), combined - 0x6 (gsm|ulaw)
Non-codec capabilities: us - 0x1 (g723), peer - 0x1 (g723), combined - 0x1 (g723)
Looking for 300 in usa2out
list_route: hop: <sip:420@192.168.0.100:9169>
Transmitting (NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.100:9169;branch=z9hG4bK-d87543-457661332-1--d87543-; received=193.10.251.98;rport=9169
From: Andy<sip:420@213.32.123.121>;tag=4b034165
To: <sip:300@213.32.123.121>
Call-ID: 98571a0fed654821
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:300@213.32.123.121>
Content-Length: 0
-
Gippsweb
If you do a sip set debug and then call your DiD, do you get the failure in the same area?
After the v= o= s= etc Block.
-
Mine was very strange as with sip debug on, nothing was showing until after the call was hungup.
Franks software people made some changes last night and now my calls are getting rejected by my bow (as per my other thread).
I'd never been so happy to see a call get rejected as I was this morning. Frank also changed the incoming CID on my DID and this is what I think is causing my current issues.
I'm not 100% with the settings for his business network, but all the comvergence stuff I've dealt with has been first rate.
You use sip.bbvoice.com.au Mine uses sip.evoice.net.au
Funnily enough from here in Morwell your routes straight to Melb with 8ms pings
Mine routes via Sydney to what looks like an ip in Sth Aus with 38ms pings.
Mine appears to be a different failure to yours, even before last nights changes.
Frank has offered to have his software guys RDP into my box and sort it for me, but I'm not big on that idea as yet. I'd rather sort it myself with help from here if I can..
-
So have you had these problems since changing from 202.168.56.133 to 202.168.56.133 ??
-
We have had no problem placing calls before or after the change from an ip address to URL. We just had a problem 1 morning not being able to make calls because they had changed addresses.
But the incoming is new and as far as we are concerned never worked although Frank said he called us on the DiD. We have never been able to replicate it.
There must be a test routine we can apply to see where the fault is? Just tried a permit = line in the User Stanza but that also did not work. One thing I have noticed is the UserAgent coming from their end has been sippy but in the last few tests has been a "heinz" collection.
-
This is gonna sound stupid, but I just had a look at your debug from the OP and noticed your trunk name is 0740840650 but the incoming CID is 61740840650
-
Thanks Gippsweb
We have tried a lot of combinations just in case. We have registration on the sip trunk, no problems. We are currently using 61740840650 as the DID Number SIP/IAX Name for the trunk and 0740840650 for the PTT_DiD_Group as it both are keys and need to be unique.
-
Ok That was it. Thank you.
When setting up the trunk do not use the line number but use it in the PTT_DiD_Group. I just set the DID Number SIP/IAX Name to strings
-
Glad to here we have a solution, Frank will be happy to here I've solved both problems today..... :cool:
-
Lost the DiD with the upgrade to sail-2.3.1-4 and loading asterisk-1.4.24.1-75.el4 also did not solve the issue.
Adding
insecure=very
useragent=PAP2T
to the sip.conf general section (Headers) did work. Hopefully the "insecure=very" does not cause any security issues. From what I have read so far it is associated only to registered sip trunks.
Thank you all.
-
it will be the insecure=very that has solved your problem, the useragent string doesn't seem to be an issue with WDP anymore.
insecure=very doesn't mean what you think it does, it's actually quite the opposite.
-
Good work guys
Just to be pedantic; in 1.4 you should really use insecure=port,invite. insecure=very still works but it has been deprecated so it will disappear in 1.6 and.... just before you both (quite rightly) jump down my throat, we know we have to update the SARK/SAIL carrier libraries.
:)
Very Best
S
-
homer simpson moment, oh doh <slaps head>
thats right I've been using insecure=port,invite with WDP since I upgraded to 1.4
-
Hi S
No was not thinking any fault of Selintra but maybe a peculiar IST setting. The insecure=port,invite was in the user stanza but had no affect. Also tried putting them (both port,invite and very) on the left hand side. Only the header/General section worked. Just a few more grey hairs!! Nothing to worry about.