[Freeswitch-users] Inviting both normal and webrtc users

[Jurijs Ivolga]

Hi Allan,

Not sure if it might work, but I had an idea:

When you need to send invite from freeswitch then you trigger a regular
call with Bridge and then if it fails send other Bridge with
"media_webrtc=true"(continue_on_fail). On WebRTC client you should reject
call if it sees invite without DTLS and do not show anything to customer.
Because first calls fails second bridge will be triggered from Freeswitch
and that must have  "media_webrtc=true". Again if first bridge succeed then
you do not trigger second bridge with "media_webrtc=true". So for WebRTC
you will always send call without DTLS and it will fails and after you send
right one.

I did'n check but for me it sounds like solution what might work for some
cases. It is definitely not very elegant, but it might work... Off cause it
adds more problems with call-logs, but again it is solvable.

Jurijs


On Thu, Nov 29, 2018 at 1:27 PM Allan Kristensen <ak at hejdu.dk> wrote:

> Hello Jurijs,
>
> Thank you for your answer. So you are at the same place as us, that you
> require to know what client you are calling.
> We are trying to make a super user friendly system adding additional
> config items for clients is not the way we want to go.
>
> So we are considering connecting our Kamailio to our Rabbitmq (AMQP),
> relaying the register requests and storing this information in the
> database, so we can look at the User Agent string before doing the call and
> perform the correct invite. But maaaan, just so much complexity to overcome
> this (little) problem.
>
> We tried rtp_secure_media=optional, but AFAIK that's only for SDES
> (a=crypto) and will not work.
>
> If we find a way I will let you know :-)
>
> Have a nice day..
>  Allan
>
> On Wed, Nov 28, 2018 at 5:14 PM Jurijs Ivolga <jurijs.ivolga at gmail.com>
> wrote:
>
>> Hi,
>>
>> Sorry I bit misunderstood your question, so you can ignore my first
>> reply. :)
>>
>> In my implementation I have similar problem when some clients are
>> connecting via WebRTC and some via SIP.
>>
>> I solved it in a way that when calls needs to go to WebRTC, then call are
>> routed to dialplan what is dedicated to WebRTC and plain SIP are routed to
>> regular dialplan.
>>
>> This do not answer your question, but I hope it will help. :)
>>
>> Jurijs
>>
>> On Wed, Nov 28, 2018 at 2:21 PM Allan Kristensen <ak at hejdu.dk> wrote:
>>
>>> Hello,
>>>
>>> I'm trying to implement calling Webrtc clients (through kamailio proxy),
>>> which needs ICE, DTLS, etc. in SDP and so we are adding "media_webrtc=true"
>>> when calling and it works fine.
>>> But once we do this, many of our other sip clients complain because they
>>> only support/accept insecure RTP (RTP/AVP).
>>>
>>> So question is, shouldn't it be possible to offer both secure and
>>> insecure RTP in the INVITE from FS?
>>>
>>> If not then, would it advisable/possible to not send SDP in the initial
>>> invite from FS (we don't need early media for inbound anyway) and then wait
>>> for the client to offer the SDP instead ?
>>> (I'm afraid the ice process might cause a little silence interval at the
>>> start of the call because of the late media setup and user would always
>>> expect media to be up when answering the call)
>>>
>>> We really want to have generic way of handling of clients if possible,
>>> to avoid client detection (as currently only kamailio has this info, doing
>>> the location services) or any special config items on sip accounts.
>>>
>>> Best regards,
>>>   Allan
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Services
>>> sales at freeswitch.com
>>> https://freeswitch.com
>>>
>>> Official FreeSWITCH Sites
>>> https://freeswitch.com/oss
>>> https://freeswitch.org/confluence
>>> https://cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> https://freeswitch.com
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Services
>> sales at freeswitch.com
>> https://freeswitch.com
>>
>> Official FreeSWITCH Sites
>> https://freeswitch.com/oss
>> https://freeswitch.org/confluence
>> https://cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> https://freeswitch.com
>
> _________________________________________________________________________
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> https://freeswitch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20181129/200484b3/attachment.html>