Quote from: azrobert on October 20, 2019, 08:39:03 AM
The following was my original design, but I didn't post it because of the reliability problem. All calls are routed to Yate. Good calls are routed back to the OBi200. Bad calls are rejected with an auth error. If Yate is down, all calls are dropped.
regexroute.conf
[default]
;
; Lines beginning with ";" are comments
;
; Repeat the following as needed
${caller}^8005551212$= goto RejCall
${callername}^unknown$= goto RejCall
.*$=sip/sip:0@yy.yy.yy.tt:5063
; Routes good calls back to the OBi200
; Change yy.yy.yy.yy to the IP address of the OBi200
; 5063 is the X_UserAgentPort of SP4
[RejCall]
.*$=-;error=noauth
; This produces an authorization error and rejects the call.
OBi200:
Voice Services -> SP1 Service -> X_InboundCallRoute:
sp4(100@xx.xx.xx.xx)
Routes all calls to Yate
Change xx.xx.xx.xx to the IP address of the computer running Yate.
Service Providers -> ITSP Profile D -> SIP -> ProxyServer: 127.0.0.1
Service Providers -> ITSP Profile D -> SIP -> X_SpoofCallerID: Checked
Voice Services -> SP4 Service -> AuthUserName: anything
Voice Services -> SP4 Service -> X_RegisterEnable: unchecked
Voice Services -> SP4 Service -> X_ServProvProfile: D
Voice Services -> SP4 Service -> X_UserAgentPort: 5063
I have been trying the above setup so Yate doesn't have to answer the phone. It works, but I notice that Yate proxies the call's audio channel. It is acting as a middle-man rather than just handing the call back off to the Obi after it accepts or rejects calls. If Yate goes down during a call (after it has accepted it), the call will die.
So, I have been trying the small "redirect=yes" modification to the above regexroute.conf file:
.*$=sip/sip:0@yy.yy.yy.tt:5063;redirect=yes
Yate will send a 302 reply instead, and the phone successfully rings on SP4. However, as soon as I answer the call, the call dies. I am trying to figure out why it dies.
Is it because my "ITSP A>SIP" with
voip.ms is using "TLS" encryption (and "Voice>SP1"="use SRTP only") ? When Obi redirects the call to Yate it is using plain UDP (not tls).
Or is it because the SP1 -> Yate -> SP4 is using the same port on the obi OBI.IP:5063 ? I notice the INVITE request from SP1 -> Yate has
INVITE sip:101@YATEIP:5080 SIP/2.0
Via: SIP/2.0/UDP OBI-IP:5063;branch=z9aG4bK-bf4a8a9a;rport
Contact: <sip:100@OBI-IP:5063>
and then the Yate 302 Redirect back to SP1 will redirect it to the same port (SP4's port):
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP OBI-IP:5063;branch=z9hG4bK-f757a93c;rport=5063;received=OBI-IP
Contact: <sip:104@OBI-IP:5063>
Is the Obi able to handle the resulting proxying/forwarding of the audio channel from SP1 to SP4?
Or is there some other way to achieve the 302 redirect in the middle without the call dying? (SP1 -> Yate, 302 Redirect to SP4 if call is accepted, 603 if not -> SP4 -> {ph})