Hi
Using opensips 1.6 we need to have the presence module to send NOTIFY over
TCP rather than UDP when the size of the message is greater than a given
MTU.
We tried to force it sending a SUBSCRIBE with transport=tcp in Contact
header:
SUBSCRIBE sip:echo...@presence.net SIP/2.0
[...]
Contact:
E
Hi Pascal,
We found the problem - the socket on which the Subscribe was received
was always used when sending the Notify.
Find attached a patch for tm module that should fix this problem. Please
test and report the results.
Regards,
--
Anca Vamanu
www.voice-system.ro
Pascal Maugeri wrote:
2010/3/9 Pascal Maugeri :
> Hi
> Using opensips 1.6 we need to have the presence module to send NOTIFY over
> TCP rather than UDP when the size of the message is greater than a given
> MTU.
> We tried to force it sending a SUBSCRIBE with transport=tcp in Contact
> header:
>
> SUBSCRIBE sip:echo...@
2010/3/9 Anca Vamanu :
> Hi Pascal,
>
> We found the problem - the socket on which the Subscribe was received was
> always used when sending the Notify.
> Find attached a patch for tm module that should fix this problem. Please
> test and report the results.
Hi Anca, could you please explain the p
Iñaki Baz Castillo wrote:
> 2010/3/9 Anca Vamanu :
>
>> Hi Pascal,
>>
>> We found the problem - the socket on which the Subscribe was received was
>> always used when sending the Notify.
>> Find attached a patch for tm module that should fix this problem. Please
>> test and report the results.
>
2010/3/9 Anca Vamanu :
>> Hi Anca, could you please explain the problem?
>>
>>
>>
> Hi Inaki,
>
> The core of the problem was in tm module. When sending out a request it
> is possible to specify a preferred socket to use. What the tm module did
> was to use this socket if defined without any other
Hi Anca
We just tested the patch you sent us but we don't see any difference.
Just in case, we recompiled the whole server (first we updated to rev 6700)
and applied the patch you kindly sent us:
svn update
...
patch -p0 < tm_proto_fix.patch
make all
make install
service opensips restart
The N
Hi Pascal,
Please try this revised patch. It is also against svn, take a new copy
of the tm module and apply it.
Thanks and regards,
--
Anca Vamanu
www.voice-system.ro
Pascal Maugeri wrote:
Hi Anca
We just tested the patch you sent us but we don't see any difference.
Just in case, we re
2010/3/10 Pascal Maugeri :
> Hi Anca
> We just tested the patch you sent us but we don't see any difference.
Could you paste a SIP flow for the SUBSCRIBE and NOTIFY?
--
Iñaki Baz Castillo
___
Users mailing list
Users@lists.opensips.org
http://lists.o
to: OpenSIPS users mailling list
cc: Albert Petit
Hello Anca
Sorry but this patch does not help neither :-(
FYI we applied it against rev 6706.
I will test this afternoon with a subscriber that is not behind NAT, maybe
we can isolate a bit more the problem.
I'm going to answer to Iñaki's ema
Hola Iñaki
Here is the SIP flow you asked me.
Hope it helps to spot the problem. Observe the watcher is behind NAT.
SUBSCRIBE sip:present...@presence.net SIP/2.0
Record-Route:
Call-ID: d041f6cae786fea76503d43658570...@10.1.1.235
CSeq: 1 SUBSCRIBE
From: "watcher"
>;tag=94671740
To: >
Via: SIP/2.
Hi Pascal,
I have just tested myself - with a Subscribe sent on udp and contact
with trasport=tcp and the Notify is sent over tcp.
I would suggest to run opensips in debug mode and paste the log messages
when starting the processing for sending the Notify ( starting with
"DBG:presence:build_dlg
OK I'm going to do that, thank you Anca.
On Thu, Mar 11, 2010 at 2:07 PM, Anca Vamanu wrote:
> Hi Pascal,
>
> I have just tested myself - with a Subscribe sent on udp and contact
> with trasport=tcp and the Notify is sent over tcp.
> I would suggest to run opensips in debug mode and paste the lo
Anca
I got the following logs when subscribing:
Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
DBG:presence:build_dlg_t: CONTACT = sip:watc...@79.149.10.246:5060
;transport=tcp
Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]: DBG:tm:t_uac:
next_hop=
Mar 11 15:28:40 test /usr/local/sbin/
Hi Pascal,
Only now I observed that there is a Route header in the Notify - so the
first hop is in fact the address in the route and not the RURI. So it is
correct to send the Notify on udp, and the proxy at the next hop should
switch to tcp.
Regards,
--
Anca Vamanu
www.voice-system.ro
Pa
Ok, good comment. Yes indeed we have a SIP proxy between the subscriber and
opensips (which is only acting as presence server in this scenario).
I thought there were two problems (one at proxy and one at presence server
side). We will work on proxy side now to solve this issue.
Many thanks for you
2010/3/11 Pascal Maugeri :
> Hola Iñaki
> Here is the SIP flow you asked me.
> Hope it helps to spot the problem. Observe the watcher is behind NAT.
> SUBSCRIBE sip:present...@presence.net SIP/2.0
> Record-Route:
> Call-ID: d041f6cae786fea76503d43658570...@10.1.1.235
> CSeq: 1 SUBSCRIBE
> From: "
2010/3/11 Pascal Maugeri :
> Ok, good comment. Yes indeed we have a SIP proxy between the subscriber and
> opensips (which is only acting as presence server in this scenario).
> I thought there were two problems (one at proxy and one at presence server
> side). We will work on proxy side now to sol
18 matches
Mail list logo
