[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serdev
Subject:    Re: [Services] Not disable ICE through iptel.org?
From:       Eeri Kask <Eeri.Kask () mailbox ! tu-dresden ! de>
Date:       2014-06-19 16:36:59
Message-ID: 53A311AB.1020206 () mailbox ! tu-dresden ! de
[Download RAW message or body]

On 19.06.14 08:00, Jiri Kuthan wrote:
> On 6/18/14 4:56 PM, Eeri Kask wrote:
>> Hello,
>>
>> it looks like iptel (212.79.111.155) manipulates SDP content of INVITE
>> requests and removes ICE-related entries.  How to disable this editing?
> 
> 
> I don't think there is an easy way to change this behaviour and even more
> importantly I'm not sure that's desirable.  [...]


I mean, you mean I express my intention to *not* make use of ICE by adding


   a=ice-ufrag:251b6dfe
   a=ice-pwd:2bd251ba
   a=candidate:Sc0a80264 1 UDP 1862270975 1.2.3.4 4038 typ srflx raddr
192.168.2.100 rport 4038
   a=candidate:Hc0a80264 1 UDP 1694498815 192.168.2.100 4038 typ host


into the SDP body?   :-)



> The point is that the SIP service has no clue if the called
> party can handle NAT traversal and supports SIP.   ^H^H^HICE
> 
> /* clearly we do assume SIP support ;) ... I meant to say ICE */
> 
> Therefore it puts itself in the middle and always relays UDP.


Actually here is no technical argument here.  The situation is simple:
UAC/UAS-software either do not support ICE, in that case they ignore
ICE-related parts in SDP offer of remote endpoint and don't specify any
by themselves ... or the SIP-clients falsely advertise supporting ICE
and in reality they don't.  Should iptel really care?

(Today it looks like iptel forcefully reroutes all media communication
through 212.79.111.155 regardless if it makes technical or economical or
otherwise sense to its customers; and even more importantly without them
having any reasonable means to do something about it.)

    Eeri Kask


_______________________________________________
Services mailing list
Services@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/services
[prev in list] [next in list] [prev in thread] [next in thread]