On 08/16/2013 12:29 PM, Roberto Fichera wrote:
> On 08/14/2013 09:58 PM, Vitaliy Aleksandrov wrote:
>> On 08/14/2013 07:32 PM, Roberto Fichera wrote:
>>> On 08/14/2013 04:36 PM, Vitaliy Aleksandrov wrote:
If you won't be able to disable SIP ALG on your router you can fill
$avp(received)
On 08/14/2013 09:58 PM, Vitaliy Aleksandrov wrote:
> On 08/14/2013 07:32 PM, Roberto Fichera wrote:
>> On 08/14/2013 04:36 PM, Vitaliy Aleksandrov wrote:
>>> If you won't be able to disable SIP ALG on your router you can fill
>>> $avp(received) manually before calling save():
>>> $avp(receive
On 08/14/2013 07:32 PM, Roberto Fichera wrote:
On 08/14/2013 04:36 PM, Vitaliy Aleksandrov wrote:
If you won't be able to disable SIP ALG on your router you can fill
$avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp + ";transport=" + $proto;
In this
On 08/14/2013 04:36 PM, Vitaliy Aleksandrov wrote:
> If you won't be able to disable SIP ALG on your router you can fill
> $avp(received) manually before calling save():
> $avp(received) = "sip:" + $si + ":" + $sp + ";transport=" + $proto;
>
> In this case all user location records will have
If you won't be able to disable SIP ALG on your router you can fill
$avp(received) manually before calling save():
$avp(received) = "sip:" + $si + ":" + $sp + ";transport=" + $proto;
In this case all user location records will have the "received" attribut
even if a UA isn't behind NAT, but
On 08/14/2013 11:51 AM, Roberto Fichera wrote:
> On 08/14/2013 11:31 AM, Daniel-Constantin Mierla wrote:
>
> Hi,
>
>> Hello,
>>
>> On 8/14/13 11:26 AM, Roberto Fichera wrote:
>>> On 08/14/2013 11:20 AM, Daniel-Constantin Mierla wrote:
>>>
>>> Hi,
>>>
Hello,
On 8/14/13 11:16 AM, Rober
On 08/14/2013 11:31 AM, Daniel-Constantin Mierla wrote:
Hi,
> Hello,
>
> On 8/14/13 11:26 AM, Roberto Fichera wrote:
>> On 08/14/2013 11:20 AM, Daniel-Constantin Mierla wrote:
>>
>> Hi,
>>
>>> Hello,
>>>
>>> On 8/14/13 11:16 AM, Roberto Fichera wrote:
On 08/14/2013 10:19 AM, Daniel-Constanti
Hello,
On 8/14/13 11:26 AM, Roberto Fichera wrote:
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla wrote:
Hi,
Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
Hi,
Hello,
as you can see in the REGISTER, the phone give a public IP
On 08/14/2013 11:20 AM, Daniel-Constantin Mierla wrote:
Hi,
> Hello,
>
> On 8/14/13 11:16 AM, Roberto Fichera wrote:
>> On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
>>
>> Hi,
>>
>>> Hello,
>>>
>>> as you can see in the REGISTER, the phone give a public IP where it can be
>>> contacted
Hello,
On 8/14/13 11:16 AM, Roberto Fichera wrote:
On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
Hi,
Hello,
as you can see in the REGISTER, the phone give a public IP where it can be
contacted and kamailio tries to deliver to
that address sip:528@94.94.X.X:1274;transport=TCP
REGI
On 08/14/2013 10:19 AM, Daniel-Constantin Mierla wrote:
Hi,
> Hello,
>
> as you can see in the REGISTER, the phone give a public IP where it can be
> contacted and kamailio tries to deliver to
> that address sip:528@94.94.X.X:1274;transport=TCP
>
> REGISTER comes from another port, but that is a
Hello,
as you can see in the REGISTER, the phone give a public IP where it can
be contacted and kamailio tries to deliver to that address
sip:528@94.94.X.X:1274;transport=TCP
REGISTER comes from another port, but that is allowed in SIP.
You should disable stun in the client and let the serve
On 08/13/2013 03:32 PM, Roberto Fichera wrote:
> On 08/13/2013 03:25 PM, Daniel-Constantin Mierla wrote:
>> Can you get a ngrep trace for a registration as well (for the phone using
>> tcp)?
> Ok! I'll use pjsua from my local machine connecting in the same way as the
> TCP client was doing. The TC
On 08/13/2013 03:25 PM, Daniel-Constantin Mierla wrote:
> Can you get a ngrep trace for a registration as well (for the phone using
> tcp)?
Ok! I'll use pjsua from my local machine connecting in the same way as the
TCP client was doing. The TCP client it's an iPhone using the same pjlib
library.
On 08/13/2013 03:22 PM, Daniel-Constantin Mierla wrote:
> The sip trace is incomplete, I don't see invite with credentials and then I
> see an ACK sent via tcp on the right
> connection. That means a negative response was received over tcp from the
> callee.
I think I'll restart from the default
Can you get a ngrep trace for a registration as well (for the phone
using tcp)?
Daniel
On 8/13/13 3:23 PM, Roberto Fichera wrote:
On 08/13/2013 03:15 PM, Roberto Fichera wrote:
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
On 08/1
On 08/13/2013 03:15 PM, Roberto Fichera wrote:
> On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
Hello,
you should grab the ngrep for such call to understand
The sip trace is incomplete, I don't see invite with credentials and
then I see an ACK sent via tcp on the right connection. That means a
negative response was received over tcp from the callee.
Daniel
On 8/13/13 3:15 PM, Roberto Fichera wrote:
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla
On 08/13/2013 02:33 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 8/13/13 1:10 PM, Roberto Fichera wrote:
>> On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> you should grab the ngrep for such call to understand better what happens.
>>> Also, dumping the location re
Hello,
On 8/13/13 1:10 PM, Roberto Fichera wrote:
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
Hello,
you should grab the ngrep for such call to understand better what happens.
Also, dumping the location records will be
useful (kamctl ul show).
Also, be sure that tcp connection li
On 08/13/2013 12:03 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> you should grab the ngrep for such call to understand better what happens.
> Also, dumping the location records will be
> useful (kamctl ul show).
>
> Also, be sure that tcp connection lifetime is long enough to survive
> re-reg
Hello,
you should grab the ngrep for such call to understand better what
happens. Also, dumping the location records will be useful (kamctl ul show).
Also, be sure that tcp connection lifetime is long enough to survive
re-registration. To avoid trying to open connections behind nat, use
set_
Hi All,
Sorry for cross-posting this email to PJLIB, but maybe there are some things
related.
Anyhow! I'm having problems on kamailio v4.0.2 under Fedora 18 64bit and TCP
client like iPhone using PJSIP as SIP library.
Basically once the iPhone side in close the call (TCP->UDP) I'm getting the
e
23 matches
Mail list logo
