Koozali.org: home of the SME Server

Obsolete Releases => SME VoIP (Asterisk, SAIL etc) => Topic started by: compsos on May 11, 2010, 10:47:51 AM

Title: DID User-Agent
Post by: compsos on May 11, 2010, 10:47:51 AM
Hi
We had an old thread on this in the past and it has worked since then but has again gone westward with the blame being put on the "User-Agent" string. Nothing we have tried so far changes the values in the attached code. Is it possible to change "this" User-Agent or is the one in the sip.conf or the trunks stanza something different?
Code: [Select]
Reliably Transmitting (no NAT) to Provider IP Address:5060:
OPTIONS sip:sip.bbvoice.com.au SIP/2.0
Via: SIP/2.0/UDP 220.245.107.242:5060;branch=z9hG4bK4a2119a1;rport
From: "asterisk" <sip:asterisk@our IP address>;tag=as409c6ec3
To: <sip:sip.bbvoice.com.au>
Contact: <sip:asterisk@our IP address>
Call-ID: 2a0be766209c62fe7f2414e659207277@our IP address
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX  <---Error line according to Provider
Max-Forwards: 70
Date: Tue, 11 May 2010 02:57:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

I think we are just looking in the wrong spot but searches have not shown an entry "Asterisk PBX". Apparently it upsets Portabilling systems so any other string is fine.

Thanks
Title: Re: DID User-Agent
Post by: compsos on May 11, 2010, 11:09:27 AM
OK if I enter a new setting in the sip.conf header useragent=xxxx that has changed the useragent string but my connection issue looks like it may be something else. Will report back results of other tests.
Title: Re: DID User-Agent
Post by: bbialy on May 11, 2010, 12:40:17 PM
to be quite precise with porta and asterisk
first:
useragent is global parameter so it can be only setup for whole asterisk.
i do not know possibility to setup it for each trunk separetly

second:
connect to porta:
useragent=portasipfirendly
insecure=port,invite

best
Bialy

Title: Re: DID User-Agent
Post by: compsos on May 11, 2010, 01:24:35 PM
Thanks Bialy
It would seem the real problem is SIP/2.0 407 Proxy Authentication Required. The provider thought it was the useragent string Asterisk PBX causing the issue, but changing it has not cleared the problem. From what I have found i would indicate a username/password combination but the trunk connects just fine. It does not accept the incoming DID.

If the useragent field is global it should be only in the sip.conf header file and not the trunks themselves?
Title: Re: DID User-Agent
Post by: compsos on May 12, 2010, 01:23:21 AM
No still does not answer the incoming call. I think the useragent was just a red herring!

I think the issue is at the line "Ignoring this INVITE request" but have not understood way as yet.

Code: [Select]
<--- SIP read from [provider IP]:5060 --->
INVITE sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:[provider IP];ftag=692574317acdf2e9d33e402ef6d9e82b;lr>
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.a49dee9fc3900b7112a88429c47cd181.0
Via: SIP/2.0/UDP [provider IP]:5061;branch=z9hG4bKc68afe21eb579c49601111a7cd9d5f55;rport=5061
Max-Forwards: 16
From: <sip:0429338896@[provider IP]>;tag=692574317acdf2e9d33e402ef6d9e82b
To: <sip:61740840650@[provider IP]>
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:[provider IP]:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 878863713-912417846-828597301-5758872
h323-conf-id: 878863713-912417846-828597301-5758872
Content-disposition: session
Content-Length: 307
Content-Type: application/sdp

v=0
o=Sippy 154021516 0 IN IP4 [provider IP]
s=VoipCall
t=0 0
m=audio 55788 RTP/AVP 18 4 8 0 101
c=IN IP4 [provider IP]
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
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

<------------->
--- (17 headers 14 lines) ---
Sending to [provider IP] : 5060 (no NAT)
Using INVITE request as basis request - call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
Found peer 'peerwdp_out'

<--- Reliably Transmitting (no NAT) to [provider IP]:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.a49dee9fc3900b7112a88429c47cd181.0;received=[provider IP]
Via: SIP/2.0/UDP [provider IP]:5061;branch=z9hG4bKc68afe21eb579c49601111a7cd9d5f55;rport=5061
From: <sip:0429338896@[provider IP]>;tag=692574317acdf2e9d33e402ef6d9e82b
To: <sip:61740840650@[provider IP]>;tag=as644ff0b5
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
CSeq: 200 INVITE
User-Agent: portasipfriendly
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="632e3f13"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o' in 6784 ms (Method: INVITE)
server*CLI>
<--- SIP read from [provider IP]:5060 --->
ACK sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.a49dee9fc3900b7112a88429c47cd181.0
From: <sip:0429338896@[provider IP]>;tag=692574317acdf2e9d33e402ef6d9e82b
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
To: <sip:61740840650@[provider IP]>;tag=as644ff0b5
CSeq: 200 ACK
User-Agent: Sip EXpress router (0.9.6 (i386/freebsd))
Content-Length: 0


<------------->
--- (8 headers 0 lines) ---
server*CLI>
<--- SIP read from [provider IP]:5060 --->
INVITE sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:[provider IP];ftag=b54ea91b1073846f3ec5eb926a8861b1;lr>
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.b8cebee32676b684eef6d61625f8a62b.0
Via: SIP/2.0/UDP [provider IP]:5061;branch=z9hG4bK2d6edaee51ed3766bd13b4ba3be671b7;rport=5061
Max-Forwards: 16
From: <sip:0429338896@[provider IP]>;tag=b54ea91b1073846f3ec5eb926a8861b1
To: <sip:61740840650@[provider IP]>
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:[provider IP]:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 878863713-912417846-828597301-5758872
h323-conf-id: 878863713-912417846-828597301-5758872
Content-disposition: session
Content-Length: 307
Content-Type: application/sdp

v=0
o=Sippy 147926188 0 IN IP4 [provider IP]
s=VoipCall
t=0 0
m=audio 55790 RTP/AVP 18 4 8 0 101
c=IN IP4 [provider IP]
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
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

<------------->
--- (17 headers 14 lines) ---
Ignoring this INVITE request
server*CLI>
<--- SIP read from [provider IP]:5060 --->
INVITE sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:[provider IP];ftag=b54ea91b1073846f3ec5eb926a8861b1;lr>
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.b8cebee32676b684eef6d61625f8a62b.0
Via: SIP/2.0/UDP [provider IP]:5061;branch=z9hG4bK2d6edaee51ed3766bd13b4ba3be671b7;rport=5061
Max-Forwards: 16
From: <sip:0429338896@[provider IP]>;tag=b54ea91b1073846f3ec5eb926a8861b1
To: <sip:61740840650@[provider IP]>
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:[provider IP]:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 878863713-912417846-828597301-5758872
h323-conf-id: 878863713-912417846-828597301-5758872
Content-disposition: session
Content-Length: 307
Content-Type: application/sdp

v=0
o=Sippy 147926188 0 IN IP4 [provider IP]
s=VoipCall
t=0 0
m=audio 55790 RTP/AVP 18 4 8 0 101
c=IN IP4 [provider IP]
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
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

<------------->
--- (17 headers 14 lines) ---
Ignoring this INVITE request
server*CLI>
<--- SIP read from [provider IP]:5060 --->
INVITE sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:[provider IP];ftag=b54ea91b1073846f3ec5eb926a8861b1;lr>
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.b8cebee32676b684eef6d61625f8a62b.0
Via: SIP/2.0/UDP [provider IP]:5061;branch=z9hG4bK2d6edaee51ed3766bd13b4ba3be671b7;rport=5061
Max-Forwards: 16
From: <sip:0429338896@[provider IP]>;tag=b54ea91b1073846f3ec5eb926a8861b1
To: <sip:61740840650@[provider IP]>
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:[provider IP]:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 878863713-912417846-828597301-5758872
h323-conf-id: 878863713-912417846-828597301-5758872
Content-disposition: session
Content-Length: 307
Content-Type: application/sdp

v=0
o=Sippy 147926188 0 IN IP4 [provider IP]
s=VoipCall
t=0 0
m=audio 55790 RTP/AVP 18 4 8 0 101
c=IN IP4 [provider IP]
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
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

<------------->
--- (17 headers 14 lines) ---
Ignoring this INVITE request
Really destroying SIP dialog '1c5f5a466ad7ae98749d4c0e76bafafd@192.168.36.1' Method: REGISTER
server*CLI>
<--- SIP read from [provider IP]:5060 --->
INVITE sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:[provider IP];ftag=b54ea91b1073846f3ec5eb926a8861b1;lr>
Via: SIP/2.0/UDP [provider IP];branch=z9hG4bK17de.b8cebee32676b684eef6d61625f8a62b.0
Via: SIP/2.0/UDP [provider IP]:5061;branch=z9hG4bK2d6edaee51ed3766bd13b4ba3be671b7;rport=5061
Max-Forwards: 16
From: <sip:0429338896@[provider IP]>;tag=b54ea91b1073846f3ec5eb926a8861b1
To: <sip:61740840650@[provider IP]>
Call-ID: call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:[provider IP]:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 878863713-912417846-828597301-5758872
h323-conf-id: 878863713-912417846-828597301-5758872
Content-disposition: session
Content-Length: 307
Content-Type: application/sdp

v=0
o=Sippy 147926188 0 IN IP4 [provider IP]
s=VoipCall
t=0 0
m=audio 55790 RTP/AVP 18 4 8 0 101
c=IN IP4 [provider IP]
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
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

<------------->We have 2 connections to this provider one is the DID that is not working. Could this be causing confusion on the return as the IP is the same?

Code: [Select]
Name/username              Host            Dyn Nat ACL Port     Status
peerwdp_out/61990180256    [provider IP]              5060     OK (100 ms)
WDPDiD/61740840650         [provider IP]              5060     OK (100 ms)

TIA
Title: Re: DID User-Agent
Post by: PWDasterisk on May 12, 2010, 04:40:14 AM
SIP response is from the wrong trunk instance:

<--- SIP read from [provider IP]:5060 --->
INVITE sip:61740840650@xxx.xxx.xxx.xxx SIP/2.0

Sending to [provider IP] : 5060 (no NAT)
Using INVITE request as basis request - call-71FB34DF-D03F-2D10-110A-61CD9@203.176.186.10~1o
Found peer 'peerwdp_out'

If you have multiple trunk registrations to/from the same IP address redefine your trunk stanzas...
=> type=user is when you want to match on username regardless of IP the calls originate from.
=> type=peer is never matched on username for incoming calls, only matched on IP address/port number
     unless you use insecure=xxxx where:
if both are defined as peers with insecure=port then inbound SIP requests will be responded to by the first instance of the IP address registration. SAIL has a PTT_DID_Group that is used for DID numbers - the DID will show up in extensions.conf but not as a registration or user stanza in sip.conf
Title: Re: DID User-Agent
Post by: compsos on May 13, 2010, 02:01:51 AM
If I am reading this correctly then the differences in type have been diminished?
Quote
Asterisk SIP user vs peer
Asterisk SIP 'users' and 'peers' are have been the source of much confusion for Asterisk users.

With newer versions of Asterisk the concept of SIP 'users' will be phased out.

Quotes from Kevin Fleming of Digium on Asterisk Mailing list Dec 23, 2005:

As of Asterisk 1.2, there is no reason to actually use 'user' entries
any more at all; you can use 'type=peer' for everything and the behavior
will be much more consistent.

All configuration options supported under 'type=user' are also
supported under 'type=peer'.

The difference between friend and peer is the same as defining _both_ a
user and peer, since that is what 'type=friend' does internally.

The only benefit of type=user is when you _want_ to match on username
regardless of IP the calls originate from. If the peer is registering to
you, you don't need it. If they are on a fixed IP, you don't need it.
'type=peer' is _never_ matched on username for incoming calls, only
matched on IP address/port number (unless you use insecure=port or higher).


If I understand correctly "useragent" is just a free flowing string unless the system you are connecting to blocks certain strings like "Asterisk PBX".

I have adjusted to a single connection but still can not get a call in.

Would the change in the IP address in this line cause an issue?
"Call-ID: call-719A617F-2840-2D10-061B-2C1A5E@203.176.186.11~1o"
It is different by the last octet Provider IP 203.176.185.10.

Code: [Select]
<--- SIP read from [Provider IP]:5060 --->
INVITE sip:[Our DID]@[Our Ext IP] SIP/2.0
Record-Route: <sip:[Provider IP];ftag=1ab4cc7a054615f2432c058fe35393c6;lr>
Via: SIP/2.0/UDP [Provider IP];branch=z9hG4bKdc47.4d9765281e8ba6eec620cf10ccdb1e6a.0
Via: SIP/2.0/UDP [Provider IP]:5061;branch=z9hG4bK30244f360c68dbd36fa93786731342c9;rport=5061
Max-Forwards: 16
From: <sip:0429338896@[Provider IP]>;tag=1ab4cc7a054615f2432c058fe35393c6
To: <sip:[Our DID]@[Provider IP]>
Call-ID: call-719A617F-2840-2D10-061B-2C1A5E@203.176.186.11~1o
CSeq: 200 INVITE
Contact: Anonymous <sip:[Provider IP]:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 878863714-808740148-828454243-0
h323-conf-id: 878863714-808740148-828454243-0
Content-disposition: session
Content-Length: 286
Content-Type: application/sdp

v=0
o=Sippy 151138732 0 IN IP4 [Provider IP]
s=VoipCall
t=0 0
m=audio 50586 RTP/AVP 18 4 8 0 101
c=IN IP4 [Provider IP]
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

<------------->
--- (17 headers 13 lines) ---
Sending to [Provider IP] : 5060 (no NAT)
Using INVITE request as basis request - call-719A617F-2840-2D10-061B-2C1A5E@203.176.186.11~1o
Found peer 'wdp1'

<--- Reliably Transmitting (no NAT) to [Provider IP]:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP [Provider IP];branch=z9hG4bKdc47.4d9765281e8ba6eec620cf10ccdb1e6a.0;received=[Provider IP]
ia: SIP/2.0/UDP [Provider IP]:5061;branch=z9hG4bK30244f360c68dbd36fa93786731342c9;rport=5061
From: <sip:0429338896@[Provider IP]>;tag=1ab4cc7a054615f2432c058fe35393c6
To: <sip:[Our DID]@[Provider IP]>;tag=as0eb973ab
Call-ID: call-719A617F-2840-2D10-061B-2C1A5E@203.176.186.11~1o
CSeq: 200 INVITE
User-Agent: CompSOS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="346f0853"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'call-719A617F-2840-2D10-061B-2C1A5E@203.176.186.11~1o' in 6400 ms (Method: INVITE)

<--- SIP read from [Provider IP]:5060 --->
ACK sip:[Our DID]@[Our Ext IP] SIP/2.0
Via: SIP/2.0/UDP [Provider IP];branch=z9hG4bKdc47.4d9765281e8ba6eec620cf10ccdb1e6a.0
From: <sip:0429338896@[Provider IP]>;tag=1ab4cc7a054615f2432c058fe35393c6
Call-ID: call-719A617F-2840-2D10-061B-2C1A5E@203.176.186.11~1o
To: <sip:[Our DID]@[Provider IP]>;tag=as0eb973ab
CSeq: 200 ACK
User-Agent: Sip EXpress router (0.9.6 (i386/freebsd))
Content-Length: 0
TIA
Title: Re: DID User-Agent
Post by: PWDasterisk on May 13, 2010, 04:12:22 PM
The "useragent" has nothing to do with "type=user"
The "Call-ID:" assigned by the provider is just a string

This call is hitting the SARK Trunk Definition whose trunkname is "wdp1"... you are sending a "SIP/2.0 407 Proxy Authentication Required" request to the provider as a response, if your trunk definitions, registration string, and stanza's matched what WDP transmitted you would be sending a "SIP/2.0 100 Trying" while Asterisk is determining whether or not to accecpt that call or a "SIP/2.0 200 OK" if it has routed it.
 
Did WDP give you separate credentials (username:password) for the DID number that are different from your account number/password ???
If you only received a single account number (username) & password combination try creating a trunk instance using the account number (username) NOT the DiD number in the "DID Number/SIP Name field. The WDP registration string should be: "username:password@[Provider_IP]/username and the peer stanza should contain "insecure=port,invite"

Then create a PTT_DID_Group for the DID number(s) as specified in the SARK Documentation - Asterisk will not require separate authentication for a PTT_DID_Group number and will authenticate against the IP Address based on the trunk registration above.


Title: Re: DID User-Agent
Post by: compsos on May 14, 2010, 01:05:36 AM
So the error is in the sip.conf file? Or am I just not reading something the right way.

Code: [Select]
;External Sip lines
;
;==========================================================================
;      This is where we deal with Sipura 3000 and SIP trunks (if any).
;      We generate 2 entries (peer and user) for Spa3K but only a peer
;      entry for SIP devices.
;==========================================================================
;

[0740840650]
type=peer
host=sip.bbvoice.com.au
qualify=3000
canreinvite=no
username=username2
fromuser=username2
secret=secret
useragent=PAP2T
disallow=all
allow=g729
[0740840650]
insecure=port,invite

[peerwdp_out]
type=peer
host=sip.bbvoice.com.au
qualify=3000
canreinvite=no
username=username1
fromuser=username1
secret=secret
useragent=PAP2T
disallow=all
allow=g729
[61990180256]
insecure=port,invite

and from the extensions.conf
Code: [Select]
[mainmenu]

        include => enter_extension

        exten => 0740840650,1,agi(selintra,Inbound,${EXTEN},0740840650)
        exten => 61740840650,1,agi(selintra,Inbound,${EXTEN},61740840650)
        exten => 61990180256,1,agi(selintra,Inbound,${EXTEN},61990180256)
        exten => DAHDI1-1,1,agi(selintra,Inbound,${EXTEN},DAHDI1-1)
        exten => DAHDI2-1,1,agi(selintra,Inbound,${EXTEN},DAHDI2-1)
        exten => atp,1,agi(selintra,Inbound,${EXTEN},atp)
TIA
Title: Re: DID User-Agent
Post by: PWDasterisk on May 14, 2010, 04:25:24 AM
you're missing data in the User stanza...

in the SARK trunk interface you need to have the following data under the "User Stanza (if required)" header to route incoming calls to a context :
type=user
context=mainmenu

the "insecure=port,invite" belongs in the Peer stanza

after a commit the sip.conf should something like this:

[0740840650] <= this should be the "Trunkname"
type=peer
host=sip.bbvoice.com.au
fromdomain=bbvoice.com.au <= optional - may work without it
qualify=3000
insecure=port,invite  <= this belongs here
canreinvite=no
username=username2
fromuser=username2
secret=secret
useragent=PAP2T
disallow=all
allow=g729

[0740840650]  <= this should be the "DID Number"
type=user
context=mainmenu

>you didn't answer the question did WDP give you separate credentials (username:password) for the DID number that are different from your account number/password for outbound calls ???

> what is the DID number you are trying to route ???
Title: Re: DID User-Agent
Post by: compsos on May 14, 2010, 05:43:45 AM
Thanks PWDasterisk

Yes the username and password are different for each connection.
Title: Re: DID User-Agent
Post by: compsos on May 14, 2010, 06:37:22 AM
Thank you PWDAsterisk

The new sip.conf reads
Code: [Select]
[61740840650]
type=peer
host=sip.bbvoice.com.au
qualify=3000
canreinvite=no
username=username
fromuser=username
fromdomain=sip.bbvoice.com.au
insecure=port,invite
secret=password
useragent=PAP2T
disallow=all
allow=g729
[61740840650]
type=user
context=mainmenu
#include sark_customer_sip_devices.conf
With a PTT_DiD_Group set to just the normal number 0740840650. Also removed the original trunk 61990180256 which dates back to before we could get a local DID so not at this stage really needed. The provider users it for accounting purposes. I suspect in the end it may have been the fromdomain that helped. The useragent had no effect and has been removed. The provider originally pointed at it as the cause.

Thanks again.