Problem receiving calls from BroadWorks [multiple proxies]

I’m having a difficult time configuring SIP to work with a BroadWorks server. I think I’ve got the registration part working, but my next step, receiving calls, is not working. Sometimes I can receive a call, but most of the time, I just hear ringing on the far end.

I have done experimenting in sip.conf, including trustrpid. This is just its current state.

If anyone could offer any advice, I would appreciate it.
Thanks,
mike

Here’s my sip.conf (trimmed to remove phones):
[general]
context=default
realm=shadetreesoftware.com
allowguest=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
checkmwi=10
vmexten=voicemail
recordhistory=yes
disallow=all
allow=ulaw
musicclass=default
language=en
dtmfmode=rfc2833
tos=184
nat=yes
fromdomain=shadetreesoftware.com
insecure=very

register => 007190000100007@netrack.net:password:007190000100007@las-obproxy.com
mpartners.us

[test]
context=default
type=friend
username=007190000100007@netrack.net
user=007190000100007
secret=password
outboundproxy=las-obproxy.commpartners.us
;host=las-obproxy.commpartners.us
host=dynamic
auth = 007190000100007:password@netrack.net
insecure=very
canreinvite=no
disallow=all
allow=ulaw
qualify=yes

And here’s sip debugging output:
cedar*CLI>
<-- SIP read from 204.16.49.4:5060:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 70.91.170.25:5060;branch=z9hG4bK6cdf8461;rport=5060
From: “Unknown” sip:Unknown@shadetreesoftware.com;tag=as6e51a62f
To: sip:204.16.49.4;tag=aprqngfrt-91r5r900000c6
Call-ID: 69073691588f9f753d2de7bf10c9cbfa@shadetreesoftware.com
CSeq: 102 OPTIONS

— (6 headers 0 lines) —
Destroying call '69073691588f9f753d2de7bf10c9cbfa@shadetreesoftware.com
Dec 18 13:49:02 NOTICE[61006]: chan_sip.c:5462 sip_reregister: – Re-registra
tion for 007190000100007@netrack.net@las-obproxy.commpartners.us
– parse_srv: SRV mapped to host nv-obproxy.commpartners.us, port 5060
REGISTER 12 headers, 0 lines
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
Reliably Transmitting (NAT) to 204.14.39.36:5060:
REGISTER sip:las-obproxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 70.91.170.25:5060;branch=z9hG4bK26888178;rport
From: sip:007190000100007@netrack.net;tag=as7214f71d
To: sip:007190000100007@netrack.net
Call-ID: 2b60fcf56c7f4f121a205e64431504a2@shadetreesoftware.com
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Expires: 120
Contact: sip:s@70.91.170.25
Event: registration
Content-Length: 0


cedar*CLI>
<-- SIP read from 204.14.39.36:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 70.91.170.25:5060;branch=z9hG4bK26888178;rport=5060
From: sip:007190000100007@netrack.net;tag=as7214f71d
To: sip:007190000100007@netrack.net;tag=SDmrdff99-
Call-ID: 2b60fcf56c7f4f121a205e64431504a2@shadetreesoftware.com
CSeq: 102 REGISTER
WWW-Authenticate: DIGEST realm=“BroadWorks”,qop=“auth”,algorithm=MD5,nonce="Broa
dWorksXevvd2a0gT7cdp3fBW"
Content-Length: 0

— (8 headers 0 lines) —
Responding to challenge, registration to domain/host name las-obproxy.commpartne
rs.us
REGISTER 13 headers, 0 lines
REGISTER attempt 2 to 007190000100007@netrack.net@las-obproxy.commpartners.us
Reliably Transmitting (NAT) to 204.14.39.36:5060:
REGISTER sip:las-obproxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 70.91.170.25:5060;branch=z9hG4bK16514240;rport
From: sip:007190000100007@netrack.net;tag=as25bb60f2
To: sip:007190000100007@netrack.net
Call-ID: 2b60fcf56c7f4f121a205e64431504a2@shadetreesoftware.com
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Authorization: Digest username=“007190000100007”, realm=“BroadWorks”, algorithm=
MD5, uri=“sip:las-obproxy.commpartners.us”, nonce=“BroadWorksXevvd2a0gT7cdp3fBW”
, response=“e15d53f62fedd0b740374a917117e2f9”, opaque="", qop=auth, cnonce=“16f8
c2c6”, nc=00000001
Expires: 120
Contact: sip:s@70.91.170.25
Event: registration
Content-Length: 0


cedar*CLI>
<-- SIP read from 204.14.39.36:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 70.91.170.25:5060;branch=z9hG4bK16514240;rport=5060
From: sip:007190000100007@netrack.net;tag=as25bb60f2
To: sip:007190000100007@netrack.net;tag=SDmrdff99-
Call-ID: 2b60fcf56c7f4f121a205e64431504a2@shadetreesoftware.com
CSeq: 103 REGISTER
Contact: sip:s@70.91.170.25;expires=60;q=0.5
Content-Length: 0

— (8 headers 0 lines) —
Scheduling destruction of call ‘2b60fcf56c7f4f121a205e64431504a2@shadetreesoftwa
re.com’ in 32000 ms
Dec 18 13:49:02 NOTICE[61006]: chan_sip.c:9955 handle_response_register: Outboun
d Registration: Expiry for las-obproxy.commpartners.us is 60 sec (Scheduling rer
egistration in 45 s)
Destroying call '37fa501912a0b605750e0bd06d29c0b9@shadetreesoftware.com
cedar*CLI>
<-- SIP read from 204.14.39.36:5060:
INVITE sip:s@70.91.170.25;useradd=70.91.170.25;userport=5060 SIP/2.0
Via: SIP/2.0/UDP 204.14.39.36:5060;branch=z9hG4bKkv7u1r20c0l04ccug5g1.1
From: "DURIAN MICHAEL "sip:3034436669@204.14.39.36;user=phone;tag=SDp20lb01-80
5868553-1166474951533-
To: "Netrack"sip:007190000100007@netrack.net
Call-ID: SDp20lb01-d7b38252f71928ad08bd87137875ba19-v3000i1
CSeq: 195665335 INVITE
Contact: sip:204.14.39.36:5060;transport=udp
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY
Supported: 100rel
Accept: multipart/mixed,application/sdp
Max-Forwards: 9
Content-Type: application/sdp
Content-Length: 311

v=0
o=BroadWorks 90114197 1 IN IP4 204.14.39.36
s=-
c=IN IP4 204.14.39.36
t=0 0
m=audio 11348 RTP/AVP 18 0 8 101
a=sendrecv
a=ptime:20
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=fmtp:18 annexb=no
a=bsoft: 1 image udptl t38

— (13 headers 15 lines) —
Using INVITE request as basis request - SDp20lb01-d7b38252f71928ad08bd87137875ba
19-v3000i1
Sending to 204.14.39.36 : 5060 (NAT)
Found no matching peer or user for '204.14.39.36:5060’
Dec 18 13:49:11 NOTICE[61006]: chan_sip.c:10601 handle_request_invite: Failed to
authenticate user "DURIAN MICHAEL "sip:3034436669@204.14.39.36;user=phone;tag
=SDp20lb01-805868553-1166474951533-
Reliably Transmitting (NAT) to 204.14.39.36:5060:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 204.14.39.36:5060;branch=z9hG4bKkv7u1r20c0l04ccug5g1.1;received
=204.14.39.36
From: "DURIAN MICHAEL "sip:3034436669@204.14.39.36;user=phone;tag=SDp20lb01-80
5868553-1166474951533-
To: "Netrack"sip:007190000100007@netrack.net;tag=as0a7872b0
Call-ID: SDp20lb01-d7b38252f71928ad08bd87137875ba19-v3000i1
CSeq: 195665335 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0


cedar*CLI>
<-- SIP read from 204.14.39.36:5060:
ACK sip:s@70.91.170.25;useradd=70.91.170.25;userport=5060 SIP/2.0
Via: SIP/2.0/UDP 204.14.39.36:5060;branch=z9hG4bKkv7u1r20c0l04ccug5g1.1
CSeq: 195665335 ACK
From: "DURIAN MICHAEL "sip:3034436669@204.14.39.36;user=phone;tag=SDp20lb01-80
5868553-1166474951533-
To: "Netrack"sip:007190000100007@netrack.net;tag=as0a7872b0
Call-ID: SDp20lb01-d7b38252f71928ad08bd87137875ba19-v3000i1
Max-Forwards: 9
Content-Length: 0

— (8 headers 0 lines) —
Destroying call 'SDp20lb01-d7b38252f71928ad08bd87137875ba19-v3000i1’
cedarCLI> sip no debug
SIP Debugging Disabled
– parse_srv: SRV mapped to host nv-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
cedar
CLI>

I also get a lot of these on the console:
– parse_srv: SRV mapped to host nv-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
– parse_srv: SRV mapped to host ny-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
– parse_srv: SRV mapped to host ga-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
– parse_srv: SRV mapped to host il-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
– parse_srv: SRV mapped to host nv-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us
– parse_srv: SRV mapped to host ny-obproxy.commpartners.us, port 5060
REGISTER attempt 1 to 007190000100007@netrack.net@las-obproxy.commpartners.us

I’ve got a bit more information on this problem. I posted a bug report and was told this sort of configuration problem isn’t a bug and shouldn’t be addressed there.

I can get incoming calls to work in a very limited set of conditions:

  1. I set a host= line in my peer setup and use an IP address for the peer. It does not work if I use a hostname. I.e. 204.14.39.36 works, but las-obproxy.commpartners.us does not, even though they are the same thing.

  2. This only works when the proxy sends from that IP address. It turns out, this service has redundancy and will initiate calls from a variety of different proxies. I do not know the full list of these proxy (and they might change), so I can’t add separate peer entries for each one.

I do receive SRV update notices from these proxies.

How do I set things up such that I can receive calls from any of the SRV hosts (I assume that is the set of hosts that will be sending me calls)?
Can I move my registration line to the peer context and configure things such that incoming calls from any IP will be accepted if they are tied to that registration?

Am I forced to use autocreatepeer? If so, what are the security implications of this?

mike

I went ahead an experimented with autocreatepeer thinking it would accept any INVITEs, but it apparently does not do what I thought it would.

I still cannot receive incoming calls. It only works when I set an explicit host IP and the INVITE just happens to come from the IP address I registered with. In the more common case, where the INVITE comes from another, sibling, IP address, the INVITE is declined.

Is there a way to wildcard a peer’s host= hostname so I can accept *.commpartners.us?

If I set up SER in front of asterisk, would that solve my problem?

Has no one run into this problem?

mike

I think I’m making some progress on this. If I turn off srvlookup, the IP addresses stabilize. If have srvlookup on, I see registrations like:

Reliably Transmitting (no NAT) to 204.16.49.4:5060:
REGISTER sip:las-obproxy.commpartners.us SIP/2.0

Reliably Transmitting (no NAT) to 204.14.39.36:5060:
REGISTER sip:las-obproxy.commpartners.us SIP/2.0

Each time, the IP address is different. Then when calls come in, they are coming from whatever IP address was last used in the REGISTER exchange. To make this work, I’d need a separate peer entry for each SRV possibility, which isn’t really feasible.

Is there a way to create a peer entry that is tied to a host and that host’s current SRV entry? Or current REGISTER address? Is it a bug that this doesn’t happen automatically when srvlookup is enabled?

I can work around the problem by turning off SRV, in which case the registrations always go to the same IP address and more importantly, the calls always arrive from the same IP, but it seem to me that the SRV records might provide a useful redundancy.

mike