Topic: DID Incoming calls from PortaOne system

[compsos]

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

We have never got this after the v= o= s= etc lines.

Code: [Select]

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

[compsos]

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.

[gippsweb]

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..

[gippsweb]

So have you had these problems since changing from 202.168.56.133 to 202.168.56.133 ??

[compsos]

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.

[gippsweb]

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

[compsos]

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.

[compsos]

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

[gippsweb]

Glad to here we have a solution, Frank will be happy to here I've solved both problems today.....

[compsos]

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.

[gippsweb]

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.

[SARK devs]

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

[gippsweb]

homer simpson moment, oh doh <slaps head>

thats right I've been using insecure=port,invite with WDP since I upgraded to 1.4

[compsos]

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.