[jitsi-dev] SIP not working in Ubuntu 12.04.1 64b


#1

Jitsi 1.0/1.1 SIP not working on Ubuntu 12.04.1 64b

- working accounts (in sflphone) tested: registration ok, but INVITE gets no replay.
In Wireshark are fragmented packets. Is not the problem there ? Registrar do not get full packets => sends no response? In Sflphone is no fragmentation of IP packets.

···

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#2

Hey there,

Yes, fragmentation is the most likely cause. The reason for the
fragmentation is that Jitsi's INVITEs are relatively long because of the
encryption keys, all the codecs, audio levels, image resolutions and all
the other features we support.

The issue and a workaround are described here:

https://jitsi.org/index.php/Documentation/FAQ#fragmentation

--sent from my mobile

···

On Dec 16, 2012 3:15 PM, "kapetr" <kapetr@mizera.cz> wrote:

Jitsi 1.0/1.1 SIP not working on Ubuntu 12.04.1 64b

- working accounts (in sflphone) tested: registration ok, but INVITE gets
no replay.
In Wireshark are fragmented packets. Is not the problem there ? Registrar
do not get full packets => sends no response? In Sflphone is no
fragmentation of IP packets.

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet
vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#3

Thank you very much.
Using TCP solved the problem.

BTW:
1. I have search the FAQ - for "fragment" - maybe this word should appear there.
2. If JITSI has such problem (which will appear at 99% of users (ethernet packet=1500B) -> it should be solved by default (e.g. with setting praxy by default with TCP as preffered).
3. the sound was terrible over default==pulse. I had to set the dev manually, but it will probably make problem with concuren using with pulse server :frowning:

Best regards --kapetr

----- PŮVODNÍ ZPRÁVA -----
Od: "Emil Ivov" <emcho@jitsi.org>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: SIP not working in Ubuntu 12.04.1 64b

···

Datum: 16.12.2012 - 14:25:36

Hey there,

Yes, fragmentation is the most likely cause. The reason for the
fragmentation is that Jitsi's INVITEs are relatively long because of the
encryption keys, all the codecs, audio levels, image resolutions and all
the other features we support.

The issue and a workaround are described here:

https://jitsi.org/index.php/Documentation/FAQ#fragmentation

--sent from my mobile
On Dec 16, 2012 3:15 PM, "kapetr" <kapetr@mizera.cz> wrote:

> Jitsi 1.0/1.1 SIP not working on Ubuntu 12.04.1 64b
>
> - working accounts (in sflphone) tested: registration ok, but INVITE gets
> no replay.
> In Wireshark are fragmented packets. Is not the problem there ? Registrar
> do not get full packets => sends no response? In Sflphone is no
> fragmentation of IP packets.
>
> --
> - - Reklama - - - - - - - - - - - - - -
> Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet
> vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg
>
>

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#4

Thank you very much.
Using TCP solved the problem.

BTW:
1. I have search the FAQ - for "fragment" - maybe this word should appear there.

Fixed.

2. If JITSI has such problem (which will appear at 99% of users (ethernet packet=1500B) -> it should be solved by default (e.g. with setting praxy by default with TCP as preffered).

Note that fragments would often get properly transmitted and
defragmented at the receiving end so this is not always a problem.

Anyhow, we do have a preference for TCP and choose that whenever it is
allowed by the server and properly indicated in the DnS SRV records.

3. the sound was terrible over default==pulse. I had to set the dev manually, but it will probably make problem with concuren using with pulse server :frowning:

You are using PortAudio, right? Do you have the PulseAudio system
available as an option in Jitsi?

Emil

···

On 16.12.12, 17:09, kapetr wrote:

Best regards --kapetr

----- PŮVODNÍ ZPRÁVA -----
Od: "Emil Ivov" <emcho@jitsi.org>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: SIP not working in Ubuntu 12.04.1 64b
Datum: 16.12.2012 - 14:25:36

Hey there,

Yes, fragmentation is the most likely cause. The reason for the
fragmentation is that Jitsi's INVITEs are relatively long because of the
encryption keys, all the codecs, audio levels, image resolutions and all
the other features we support.

The issue and a workaround are described here:

https://jitsi.org/index.php/Documentation/FAQ#fragmentation

--sent from my mobile
On Dec 16, 2012 3:15 PM, "kapetr" <kapetr@mizera.cz> wrote:

Jitsi 1.0/1.1 SIP not working on Ubuntu 12.04.1 64b

- working accounts (in sflphone) tested: registration ok, but INVITE gets
no replay.
In Wireshark are fragmented packets. Is not the problem there ? Registrar
do not get full packets => sends no response? In Sflphone is no
fragmentation of IP packets.

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet
vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg

--
https://jitsi.org


#5

Hello Emil Ivov,
jitsi-dev] Re: SIP not working in Ubuntu 12.04.1 64b

> 2. If JITSI has such problem (which will appear at 99% of users (ethernet packet=1500B) -> it should be solved by default (e.g. with setting praxy by default with TCP as preffered).

Note that fragments would often get properly transmitted and
defragmented at the receiving end so this is not always a problem.

Aaaa - probably problem in my ADSL modem/router ? Or by my ISP ?
It should not happen :-/
Any Idea how to test it and find the source of problem ?

Anyhow, we do have a preference for TCP and choose that whenever it is
allowed by the server and properly indicated in the DnS SRV records.

Will try ask by my VoIP SIP provider.

> 3. the sound was terrible over default==pulse. I had to set the dev manually, but it will probably make problem with concuren using with pulse server :frowning:

You are using PortAudio, right? Do you have the PulseAudio system
available as an option in Jitsi?

my fault - this was problem in Jits 1.0
In version 1.1 there is no problem, sound is OK :slight_smile:

Thanks --kapetr

···

Datum: 18.12.2012 - 15:03:58

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#6

Hello,

after testing:

----- PŮVODNÍ ZPRÁVA -----
Od: "Emil Ivov" <emcho@jitsi.org>
Komu: dev@jitsi.java.net
Předmět: Re: [jitsi-dev] Re: SIP not working in Ubuntu 12.04.1 64b

> 2. If JITSI has such problem (which will appear at 99% of users (ethernet packet=1500B) -> it should be solved by default (e.g. with setting praxy by default with TCP as preffered).

Note that fragments would often get properly transmitted and
defragmented at the receiving end so this is not always a problem.

Anyhow, we do have a preference for TCP and choose that whenever it is
allowed by the server and properly indicated in the DnS SRV records.

I have pushed my SIP provider to add DNS NAPTR and SRV records.

xxxxxxxxxxxxxxxxxxxxxxxxxxx
$ host -t NAPTR odorik.cz
odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
odorik.cz has NAPTR record 200 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.

$ host -t srv _sip._udp.odorik.cz
_sip._udp.odorik.cz has SRV record 4 10 5060 sip.odorik.cz.

$ host -t srv _sip._tcp.odorik.cz
_sip._tcp.odorik.cz has SRV record 4 10 5060 sip.odorik.cz.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

But JITSI do not use/preferr TCP as you wrote (without manual set).
By Odorik is UDP preferred but TCP available and usable, but Jitsi do not utilize that.

And more - as I see in packet sniffer - Jitsi do not ask at all these DNS NAPTR and SRV records (not after add service, not by REGISTER, not before INVITE). So in which version Jitsi does use this ? In ver 1.1 not.

Best regards --kapetr

···

Datum: 18.12.2012 - 15:03:58

On 16.12.12, 17:09, kapetr wrote:

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#7

Hey kapetr,

Hello Emil Ivov,
jitsi-dev] Re: SIP not working in Ubuntu 12.04.1 64b
Datum: 18.12.2012 - 15:03:58

2. If JITSI has such problem (which will appear at 99% of users (ethernet packet=1500B) -> it should be solved by default (e.g. with setting praxy by default with TCP as preffered).

Note that fragments would often get properly transmitted and
defragmented at the receiving end so this is not always a problem.

Aaaa - probably problem in my ADSL modem/router ? Or by my ISP ?

Either.

It should not happen :-/
Any Idea how to test it and find the source of problem ?

Can you ping any site with 8 KB packets? (e.g. Google)

Can you ping your VoIP provider with 8 KB packets?

This should give you some idea about who's messing it up.

Anyhow, we do have a preference for TCP and choose that whenever it is
allowed by the server and properly indicated in the DnS SRV records.

Will try ask by my VoIP SIP provider.

Or you can just do:

host -t NAPTR yourprovider.com

and

host -t SRV _sip._tcp.yourprovider.com

and

host -t SRV _sip._udp.yourprovider.com

3. the sound was terrible over default==pulse. I had to set the dev manually, but it will probably make problem with concuren using with pulse server :frowning:

You are using PortAudio, right? Do you have the PulseAudio system
available as an option in Jitsi?

my fault - this was problem in Jits 1.0
In version 1.1 there is no problem, sound is OK :slight_smile:

Glad to know you sorted it out.

Cheers,
Emil

···

On 18.12.12, 21:21, kapetr wrote:

Thanks --kapetr

--
https://jitsi.org


#8

From: kapetr [mailto:kapetr@mizera.cz]

2. If JITSI has such problem (which will appear at 99% of users

(ethernet

packet=1500B) -> it should be solved by default (e.g. with setting praxy

by

default with TCP as preffered).

Note that fragments would often get properly transmitted and
defragmented at the receiving end so this is not always a problem.

Anyhow, we do have a preference for TCP and choose that whenever it is
allowed by the server and properly indicated in the DnS SRV records.

I have pushed my SIP provider to add DNS NAPTR and SRV records.

xxxxxxxxxxxxxxxxxxxxxxxxxxx
$ host -t NAPTR odorik.cz
odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
odorik.cz has NAPTR record 200 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.

$ host -t srv _sip._udp.odorik.cz
_sip._udp.odorik.cz has SRV record 4 10 5060 sip.odorik.cz.

$ host -t srv _sip._tcp.odorik.cz _sip._tcp.odorik.cz has SRV record 4
10 5060 sip.odorik.cz. xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

But JITSI do not use/preferr TCP as you wrote (without manual set).
By Odorik is UDP preferred but TCP available and usable, but Jitsi do not
utilize that.

There's no way to force Jitsi in _automatic mode_ to use TCP if your
provider prefers UDP in the NAPTRs. Could be a useful change though...

And more - as I see in packet sniffer - Jitsi do not ask at all these DNS
NAPTR and SRV records (not after add service, not by REGISTER, not before
INVITE). So in which version Jitsi does use this ? In ver 1.1 not.

Do you have a manually configured proxy?

Best regards --kapetr

Regards,
Ingo

···

On 16.12.12, 17:09, kapetr wrote:


#9

- there should by "record by default" option (like in sflphone) - I

every

time forget to press record on important calls :slight_smile:

There is one. In the options windows:
Advanced->Call Recording, Check "Save calls to" and pick a location.

I have it set - but it does not record automatically. I have to press
on every call the record button. Jitsi 1.1

Oh sorry, I misunderstood. The thing you can set by default is store
location. You can't currently record all calls by default. Feel free to
open a feature request.

If may add a comment here: Recording calls without informing the other part
is against the law in a lot of countries. I don't feel comfortable
adding/having an option to record calls by default.

Regards,
Ingo


#10

Hello,

----- PŮVODNÍ ZPRÁVA -----
Od: "Emil Ivov" <emcho@jitsi.org>

>> Note that fragments would often get properly transmitted and
>> defragmented at the receiving end so this is not always a problem.
>
> Aaaa - probably problem in my ADSL modem/router ? Or by my ISP ?

Either.

$ sleep 5;ping -c1 -vW10 -s8192 www.google.com
PING www.google.com (173.194.39.81) 8192(8220) bytes of data.
8200 bytes from bud02s01-in-f17.1e100.net (173.194.39.81): icmp_req=1 ttl=50 time=5080 ms

--- www.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5080.173/5080.173/5080.173/0.000 ms

$ sleep 5;ping -c1 -vW10 -s8192 sip.odorik.cz
PING sip.odorik.cz (81.31.45.51) 8192(8220) bytes of data.
8200 bytes from 81-31-45-51.static.masterinter.net (81.31.45.51): icmp_req=1 ttl=51 time=237 ms

--- sip.odorik.cz ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 237.384/237.384/237.384/0.000 ms
$

It seems there is no fragmentation problem by me or by my ISP or by my SIP providers.

Any idea why big/fragmented INVITE do not get answer ? Could be the problem by application layer (SIP server)? As I know, they use Asterisk or SER.

Or you can just do:

host -t NAPTR yourprovider.com ....

No of my SIP providers use these DNS extensions :frowning:
I will try to push them. But would not be possible if JITSI would try TCP, and if it fails then (as fallback) UDP ?
It would solve the problem, not ?

Best regards --kapetr

···

Datum: 19.12.2012 - 1:08:49

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#11

>
> But JITSI do not use/preferr TCP as you wrote (without manual set).
> By Odorik is UDP preferred but TCP available and usable, but Jitsi do not
> utilize that.

There's no way to force Jitsi in _automatic mode_ to use TCP if your
provider prefers UDP in the NAPTRs. Could be a useful change though...

Emil Ivov has wrote to me, Jitsi uses TCP if available - e.g. to avoid problem with UDP packet fragmentation.

I have look ones again - I was wrong - Jitsi asks NAPTR and SRV at start up. But SRV ask only UDP == SRV _sip._udp.provider. It do not ask about TCP (maybe while by my provider is UDP preferred).

> And more - as I see in packet sniffer - Jitsi do not ask at all these DNS
> NAPTR and SRV records (not after add service, not by REGISTER, not before
> INVITE). So in which version Jitsi does use this ? In ver 1.1 not.

Do you have a manually configured proxy?

No, but Jitsi asks - see above - my fault.

Best regards --kapetr

···

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#12

Related to that important point:
will jitsi notify the other partner if I am going to record the call?

···

On 12/19/12 11:17 AM, Ingo Bauersachs wrote:

- there should by "record by default" option (like in sflphone) - I

every

time forget to press record on important calls :slight_smile:

There is one. In the options windows:
Advanced->Call Recording, Check "Save calls to" and pick a location.

I have it set - but it does not record automatically. I have to press
on every call the record button. Jitsi 1.1

Oh sorry, I misunderstood. The thing you can set by default is store
location. You can't currently record all calls by default. Feel free to
open a feature request.

If may add a comment here: Recording calls without informing the other part
is against the law in a lot of countries. I don't feel comfortable
adding/having an option to record calls by default.

Regards,
Ingo


#13

Good point!

--sent from my mobile

···

On Dec 19, 2012 12:17 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

>>>> - there should by "record by default" option (like in sflphone) - I
every
>>>> time forget to press record on important calls :slight_smile:
>>>
>>> There is one. In the options windows:
>>> Advanced->Call Recording, Check "Save calls to" and pick a location.
>>
>> I have it set - but it does not record automatically. I have to press
>> on every call the record button. Jitsi 1.1
>
> Oh sorry, I misunderstood. The thing you can set by default is store
> location. You can't currently record all calls by default. Feel free to
> open a feature request.

If may add a comment here: Recording calls without informing the other part
is against the law in a lot of countries. I don't feel comfortable
adding/having an option to record calls by default.

Regards,
Ingo


#14

Hey there,

But JITSI do not use/preferr TCP as you wrote (without manual
set). By Odorik is UDP preferred but TCP available and usable,
but Jitsi do not utilize that.

There's no way to force Jitsi in _automatic mode_ to use TCP if
your provider prefers UDP in the NAPTRs. Could be a useful change
though...

Emil Ivov has wrote to me, Jitsi uses TCP if available - e.g. to
avoid problem with UDP packet fragmentation.

If available _and_ properly configured. If the NAPTR record is telling
us your provider has a preference for TCP, we use it. Otherwise we just
do what they ask us to.

The case where TCP will be picked up automatically is when there

1. When the NAPTR record announces it as the preferred transport
2. When there is no NAPTR record and an SRV record for TCP exists.

I have look ones again - I was wrong - Jitsi asks NAPTR and SRV at
start up. But SRV ask only UDP == SRV _sip._udp.provider. It do not
ask about TCP (maybe while by my provider is UDP preferred).

Yes, this is the reason, when UDP is indicated as the preferred
protocol, we would not ask for a TCP SRV.

Cheers,
Emil

···

On 22.12.12, 18:11, kapetr wrote:

And more - as I see in packet sniffer - Jitsi do not ask at all
these DNS NAPTR and SRV records (not after add service, not by
REGISTER, not before INVITE). So in which version Jitsi does use
this ? In ver 1.1 not.

Do you have a manually configured proxy?

No, but Jitsi asks - see above - my fault.

Best regards --kapetr

--
https://jitsi.org


#15

No, it doesn't. That's up to you!

Emil

···

On 19.12.12, 12:45, Mr.Smith wrote:

Related to that important point:
will jitsi notify the other partner if I am going to record the call?

On 12/19/12 11:17 AM, Ingo Bauersachs wrote:

- there should by "record by default" option (like in sflphone) - I

every

time forget to press record on important calls :slight_smile:

There is one. In the options windows:
Advanced->Call Recording, Check "Save calls to" and pick a location.

I have it set - but it does not record automatically. I have to press
on every call the record button. Jitsi 1.1

Oh sorry, I misunderstood. The thing you can set by default is store
location. You can't currently record all calls by default. Feel free to
open a feature request.

If may add a comment here: Recording calls without informing the other part
is against the law in a lot of countries. I don't feel comfortable
adding/having an option to record calls by default.

Regards,
Ingo

--
https://jitsi.org


#16

Hello,

Od: "Emil Ivov" <emcho@jitsi.org>

Hey there,

>>>
>>> But JITSI do not use/preferr TCP as you wrote (without manual
>>> set). By Odorik is UDP preferred but TCP available and usable,
>>> but Jitsi do not utilize that.
>>
>> There's no way to force Jitsi in _automatic mode_ to use TCP if
>> your provider prefers UDP in the NAPTRs. Could be a useful change
>> though...
>
> Emil Ivov has wrote to me, Jitsi uses TCP if available - e.g. to
> avoid problem with UDP packet fragmentation.

If available _and_ properly configured. If the NAPTR record is telling
us your provider has a preference for TCP, we use it. Otherwise we just
do what they ask us to.

The case where TCP will be picked up automatically is when there

1. When the NAPTR record announces it as the preferred transport
2. When there is no NAPTR record and an SRV record for TCP exists.

Emil

Thanks for explanation.

But the question is - would be not better in case of JITSI (and his/common problem with UDP packet fragmentation) to use TCP if available (even if not preferred by SIP provider)
?

After all I have read, tried, understood I thing: YES

And by SIP servers with no NAPTR/SRV records (which was my case on begin) to try TCP first.

Best regards --kapetr

···

Datum: 22.12.2012 - 20:22:34

On 22.12.12, 18:11, kapetr wrote:

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#17

----- PŮVODNÍ ZPRÁVA -----
Od: "Emil Ivov" <emcho@jitsi.org>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: SIP not working in Ubuntu 12.04.1 64b

No, it doesn't. That's up to you!

Emil

Exactly - the other side must count with possibility of recording - it can't see what are you doing. The recording in SIP client only about comfort.
But if you will use the recording as evidence, then the other side must be informed before.

BTW Ingo: if is possible to record, then the default options does not more matter :slight_smile:

--kapetr

···

Datum: 19.12.2012 - 13:08:26

On 19.12.12, 12:45, Mr.Smith wrote:
> Related to that important point:
> will jitsi notify the other partner if I am going to record the call?
>
>
> On 12/19/12 11:17 AM, Ingo Bauersachs wrote:
>>>>>> - there should by "record by default" option (like in sflphone) - I
>> every
>>>>>> time forget to press record on important calls :slight_smile:
>>>>> There is one. In the options windows:
>>>>> Advanced->Call Recording, Check "Save calls to" and pick a location.
>>>> I have it set - but it does not record automatically. I have to press
>>>> on every call the record button. Jitsi 1.1
>>> Oh sorry, I misunderstood. The thing you can set by default is store
>>> location. You can't currently record all calls by default. Feel free to
>>> open a feature request.
>> If may add a comment here: Recording calls without informing the other part
>> is against the law in a lot of countries. I don't feel comfortable
>> adding/having an option to record calls by default.
>>
>> Regards,
>> Ingo
>>
>
>

--
https://jitsi.org

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg


#18

BTW Ingo: if is possible to record, then the default options does not more
matter :slight_smile:

Yes it does. If the option to record by default is there, the recording
starts even before you've told the other party. So you'd basically be
obliged to begin every call of yours with something along the line "This
call is being recorded, hang up if you don't like that".

Ingo


#19

Not in my country (Sweden). We have laws similar to those in Denmark regarding telephone recording:

"Calls and conversations may be recorded by any active participant. There is no requirement to make other parties aware of the recording, but the use of recordings, depending on their content, may be subject to various laws"

https://en.wikipedia.org/wiki/Telephone_recording_laws

/Mikael

···

On 12/19/2012 08:30 PM, Ingo Bauersachs wrote:

BTW Ingo: if is possible to record, then the default options does not more
matter :slight_smile:

Yes it does. If the option to record by default is there, the recording
starts even before you've told the other party. So you'd basically be
obliged to begin every call of yours with something along the line "This
call is being recorded, hang up if you don't like that".

Ingo


#20

Od: "Ingo Bauersachs" <ingo@jitsi.org>

> BTW Ingo: if is possible to record, then the default options does not more
> matter :slight_smile:

Yes it does. If the option to record by default is there, the recording
starts even before you've told the other party. So you'd basically be
obliged to begin every call of yours with something along the line "This
call is being recorded, hang up if you don't like that".

Ingo

It does not :slight_smile:
You can push the button direct at the beginning of call. The other side can't change it.
There is no difference between push rec on begin and default recording option=> it's your choice and responsibility.
If you want ask before -> do not use default rec. If you want record any call you can use default or press rec on begin. There is no difference, only comfort. Think :slight_smile:

--kapetr

···

Datum: 19.12.2012 - 20:30:37

--
- - Reklama - - - - - - - - - - - - - -
Získejte Apple iPad 2 a 2GB Flash disk úplně zdarma! Každý 500 účet vyhrává. Stačí si zaregistrovat mojeID na http://bit.ly/125gOqg