Summary:	ASTERISK-08405: Problem receiving calls from BroadWorks
Reporter:	Michael Durian (durian)	Labels:
Date Opened:	2006-12-20 21:31:43.000-0600	Date Closed:	2006-12-21 10:35:01.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip_debug ( 1) sip.conf
Description:	I suspect this is just a configuration error on my part and not a true bug, but I just can't figure out what is going on.  I posted this to the forum, but didn't get any traction. 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. I will upload a few files showing my sip.conf and sip debugging output. Thanks, mike
Comments:	By: Joshua C. Colp (jcolp) 2006-12-20 22:13:04.000-0600 This is indeed a configuration issue as you said and please note for future bugs - the bug tracker is not a place to escalate issues like this BUT here's what is happening: 1. You have no peer setup to match an inbound call from commpartners. 2. You are not allowing guests to connect, so because of the above... the call is not accepted. ie: Found no matching peer or user for '204.14.39.36:5060' What you need to do is this: [commpartners-in] type=peer host=204.14.39.36 context=where to make it go insecure=port,invite disallow=all allow=what codecs you want That will cause the incoming INVITE to be matched against that peer entry and directed to the appropriate context. That is all. By: Michael Durian (durian) 2006-12-21 09:52:34.000-0600 Thank you for responding even though this was not just a configuration error.  I do have on follow up question though that could potentially be a bug.  Most likely it just another misunderstanding on my part, but I'd rather err on the side of caution. Your example does work correctly.  But it doesn't work if I change the host= lines to the host name instead of the host IP address: host=204.14.39.36   works host=las-obproxy.commpartners.us   does not work Does the host line only match on text strings, or is supposed to do DNS comparisons? I also see lines like:    -- parse_srv: SRV mapped to host ga-obproxy.commpartners.us, port 5060    -- parse_srv: SRV mapped to host nv-obproxy.commpartners.us, port 5060    -- parse_srv: SRV mapped to host ny-obproxy.commpartners.us, port 5060    -- parse_srv: SRV mapped to host ga-obproxy.commpartners.us, port 5060    -- parse_srv: SRV mapped to host il-obproxy.commpartners.us, port 5060    -- parse_srv: SRV mapped to host nv-obproxy.commpartners.us, port 5060 I thought, perhaps naively, that those might be back-up proxies and that I'd need to be prepared to accept calls from them in las-obproxy went down.  That's why I thought some mixture of host=dynamic, trustrpid and various auth lines in a friend or peer setup might be more appropriate than hard-coding one particular host. Thank you again. mike By: Joshua C. Colp (jcolp) 2006-12-21 10:35:00.000-0600 They are using SRV records and you have SRV lookups enabled. That is all, hopefully.