[OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri

Thu Jul 23 14:03:10 EST 2020

Hi Mark,

Glad it helped. I actually did not know about chan_sip option
supportpath because I was using additional opensips for wws to webrtc.
Thanks for the details.

Good luck

On Thu, Jul 23, 2020 at 9:19 AM Mark Allen <mark at allenclan.co.uk> wrote:
>
> [SOLVED]
>
> Thanks Stas. Your workaround did solve the problem and I see that with 3.1 path support is baked into mid-registrar module as options to mid_registrar_save().
>
> Once we added in the path module functionality, at first it didn't work. Looking at sngrep traces we could see that the path information was appended on the inbound route from OpenSIPS to Asterisk, but when Asterisk made the call to the outbound destination it failed to include it as route info. This was resolved by setting supportpath="yes" in sip.conf and worked with CHAN_SIP. We tried to get it working with PJSIP without any joy but it's not a priority for us at the moment so we'll have to investigate the cause later.
>
> Thanks for your help Stas, and thanks also to the others who took the time to reply.
>
> cheers,
>
> Mark
>
>
> On Tue, 14 Jul 2020 at 16:23, Stas Kobzar <staskobzar at gmail.com> wrote:
>>
>> Hello Mark,
>>
>> I had a similar challenge. Using "path" module on both opensips helps
>> to overcome this problem.
>> https://opensips.org/docs/modules/3.2.x/path.html
>>
>> In your mid-registerer you need to enable path support. See "save"
>> function params p0 and v.
>> in your webrtc opensips use path module and function add_path_received
>>
>> On Tue, Jul 14, 2020 at 11:14 AM Mark Allen <mark at allenclan.co.uk> wrote:
>> >
>> > I'm new to OpenSIPS and I've hit a problem I can't find a way past
>> >
>> > We have a test setup with an OpenSIPS mid-registrar in front of an Asterisk PBX. Mid-registrar is currently in mode 1 (registration throttling). We have SIP and WebRTC endpoints that we want to use.
>> >
>> > Current state is:
>> >
>> > REGISTER:  WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> Asterisk      = success
>> > REGISTER:  SIP softphone (LinPhone)   -> OpenSIPS Mid-registrar -> Asterisk      = success
>> >
>> > INVITE:    SIP softphone    -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone   = success, call connects with audio both ways
>> > INVITE:    WebRTC webphone  -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone   = success, call connects with audio both ways
>> > INVITE:    SIP softphone    -> OpenSIPS -> Asterisk -> OpenSIPS -> WebRTC webphone = fails with "476 Unresolvable destination"
>> >
>> > syslog messages:
>> > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
>> > CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid"
>> > ERROR:tm:uri2proxy: bad host name in URI <sips:11001 at 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss>
>> > ERROR:tm:t_forward_nonack: failure to add branches
>> >
>> >
>> > Following past reports that I've found with a similar error, fix_nated_contact() is run on INVITE messages just before rtpengine flags are set and the t_relay() command, but it doesn't appear to make any difference. If I change the t_relay() to t_relay(0x04,) to disable DNS Failover, I still see the same errors in the log file. I've also checked the record in the OpenSIPS DB "location" table and it seems to me that it has the correct contact_id and contact info for the destination...
>> >
>> > contact_id: 2004383309156582802
>> > contact:    sips:11001 at 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss
>> >
>> > I'm stuck on where I can go from here  - any help very much appreciated!
>> >
>> > thx
>> >
>> > Mark
>> >
>> >
>> > Setup:
>> > OpenSIPS 3.0.2 on Debian Buster
>> > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0
>> >
>> > INVITE:
>> > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060
>> > INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0
>> > Via: SIP/2.0/UDP 192.168.50.185:5060;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0
>> > From: "11002" <sip:11002 at 192.168.50.185>;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8
>> > To: <sip:11001 at 192.168.50.69;ctid=2004383309156582802>
>> > Contact: <sip:asterisk at 192.168.50.185:5060>
>> > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688
>> > CSeq: 24456 INVITE
>> > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
>> > Supported: 100rel, timer, replaces, norefersub
>> > Session-Expires: 1800
>> > Min-SE: 90
>> > P-Asserted-Identity: "11002" <sip:11002 at 192.168.50.185>
>> > Max-Forwards: 70
>> > User-Agent: FPBX-15.0.16.63(16.9.0)
>> > Content-Type: application/sdp
>> > Content-Length:   411
>> >
>> > v=0
>> > o=- 263255642 263255642 IN IP4 192.168.50.185
>> > s=Asterisk
>> > c=IN IP4 192.168.50.185
>> > t=0 0
>> > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101
>> > a=rtpmap:9 G722/8000
>> > a=rtpmap:107 opus/48000/2
>> > a=fmtp:107 useinbandfec=1
>> > a=rtpmap:8 PCMA/8000
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:3 GSM/8000
>> > a=rtpmap:111 G726-32/8000
>> > a=rtpmap:101 telephone-event/8000
>> > a=fmtp:101 0-16
>> > a=ptime:20
>> > a=maxptime:20
>> > a=sendrecv
>> > a=rtcp-mux
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users