19 Aug
2010
19 Aug
'10
6:30 p.m.
Hello list,
I have some trouble with the presence module, I'm registering and
subscribing to a presentity through TCP, and kamailio is sending me
NOTIFY to the correct ip/port, but through UDP.
I have checked in modules_k/presence/notify.c::1578, the value of the
dialog's proto field is PROTO_TCP. but It's looke like that the function
modules/tm/uac.c:t_uac_prepare() is trying to guess the transport (in
ut.h at line 319 the function sip_hostport2su choose UDP as transport)
instead of using the one present in the dialog.
And as result I'm getting this warning and the NOTIFY through the wrong
transport: 1(28921) WARNING: <core> [forward.c:248]: WARNING:
get_send_socket: protocol/port mismatch
It's maybe a foolishness from my part but why can't we just use the
dialog's transport for the notify request, so it will be the same
transport as subscribe ?
In forward.c:242, when we find that force_send_socket->proto !=
guessed_proto, why we don't use the force_send_socket proto ?
What do you think about it ? If someone want to take a closer look, I
can post a sipp scenario which reproduce this issue.
Thanks by advance,
--
Nikita
19 Aug
19 Aug
6:44 p.m.
Hello,
can you send a sample SUBSCRIBE request? Is the contact address
advertising TCP?
Cheers,
Daniel
On 8/19/10 5:30 PM, nikita wrote:
Hello list,
I have some trouble with the presence module, I'm registering and
subscribing to a presentity through TCP, and kamailio is sending me
NOTIFY to the correct ip/port, but through UDP.
I have checked in modules_k/presence/notify.c::1578, the value of the
dialog's proto field is PROTO_TCP. but It's looke like that the
function modules/tm/uac.c:t_uac_prepare() is trying to guess the
transport (in ut.h at line 319 the function sip_hostport2su choose UDP
as transport) instead of using the one present in the dialog.
And as result I'm getting this warning and the NOTIFY through the
wrong transport: 1(28921) WARNING: <core> [forward.c:248]: WARNING:
get_send_socket: protocol/port mismatch
It's maybe a foolishness from my part but why can't we just use the
dialog's transport for the notify request, so it will be the same
transport as subscribe ?
In forward.c:242, when we find that force_send_socket->proto !=
guessed_proto, why we don't use the force_send_socket proto ?
What do you think about it ? If someone want to take a closer look, I
can post a sipp scenario which reproduce this issue.
Thanks by advance,
--
Daniel-Constantin Mierla
http://www.asipto.com/
6:57 p.m.
On 19/08/2010 17:44, Daniel-Constantin Mierla wrote:
Hello,
can you send a sample SUBSCRIBE request? Is the contact address
advertising TCP?
Sure, my subscribe was looking like :
SUBSCRIBE sip:2001@91.121.31.80:6060 SIP/2.0
Via: SIP/2.0/TCP 127.0.1.1:6060;branch=z9hG4bK-4179-1-0
From: test <sip:2001@127.0.1.1:6060>;tag=4179SIPpTag001
To: test <sip:2001@91.121.31.80:6060>
Contact: <sip:2001@127.0.1.1:6060>
Call-ID: 1-4179(a)127.0.1.1
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 600
Event: presence
X-Addressbook: 2001
Content-Length: 0
Looking at it, I just tried with : Contact:
<sip:2001@127.0.1.1:6060;transport=TCP> and it worked I got the notify
through TCP.
Cheers,
Daniel
On 8/19/10 5:30 PM, nikita wrote:
Hello list,
I have some trouble with the presence module, I'm registering and
subscribing to a presentity through TCP, and kamailio is sending me
NOTIFY to the correct ip/port, but through UDP.
I have checked in modules_k/presence/notify.c::1578, the value of the
dialog's proto field is PROTO_TCP. but It's looke like that the
function modules/tm/uac.c:t_uac_prepare() is trying to guess the
transport (in ut.h at line 319 the function sip_hostport2su choose
UDP as transport) instead of using the one present in the dialog.
And as result I'm getting this warning and the NOTIFY through the
wrong transport: 1(28921) WARNING: <core> [forward.c:248]: WARNING:
get_send_socket: protocol/port mismatch
It's maybe a foolishness from my part but why can't we just use the
dialog's transport for the notify request, so it will be the same
transport as subscribe ?
In forward.c:242, when we find that force_send_socket->proto !=
guessed_proto, why we don't use the force_send_socket proto ?
What do you think about it ? If someone want to take a closer look, I
can post a sipp scenario which reproduce this issue.
Thanks by advance,
7:07 p.m.
On 8/19/10 5:57 PM, nikita wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
On 19/08/2010 17:44, Daniel-Constantin Mierla wrote:
SIP allows to register/subscribe via a transport protocol and specify to
be contacted over a different transport. So you have to put TCP in the
contact if you want to be contacted via TCP, otherwise is UDP - default
transport protocol if none is specified.
Cheers,
Daniel
Hello,
can you send a sample SUBSCRIBE request? Is the contact address
advertising TCP?
Sure, my subscribe was looking like :
SUBSCRIBE sip:2001@91.121.31.80:6060 SIP/2.0
Via: SIP/2.0/TCP 127.0.1.1:6060;branch=z9hG4bK-4179-1-0
From: test <sip:2001@127.0.1.1:6060>;tag=4179SIPpTag001
To: test <sip:2001@91.121.31.80:6060>
Contact: <sip:2001@127.0.1.1:6060>
Call-ID: 1-4179(a)127.0.1.1
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 600
Event: presence
X-Addressbook: 2001
Content-Length: 0
Looking at it, I just tried with : Contact:
<sip:2001@127.0.1.1:6060;transport=TCP> and it worked I got the notify
through TCP.
Cheers,
Daniel
On 8/19/10 5:30 PM, nikita wrote:
Hello list,
I have some trouble with the presence module, I'm registering and
subscribing to a presentity through TCP, and kamailio is sending me
NOTIFY to the correct ip/port, but through UDP.
I have checked in modules_k/presence/notify.c::1578, the value of
the dialog's proto field is PROTO_TCP. but It's looke like that the
function modules/tm/uac.c:t_uac_prepare() is trying to guess the
transport (in ut.h at line 319 the function sip_hostport2su choose
UDP as transport) instead of using the one present in the dialog.
And as result I'm getting this warning and the NOTIFY through the
wrong transport: 1(28921) WARNING: <core> [forward.c:248]: WARNING:
get_send_socket: protocol/port mismatch
It's maybe a foolishness from my part but why can't we just use the
dialog's transport for the notify request, so it will be the same
transport as subscribe ?
In forward.c:242, when we find that force_send_socket->proto !=
guessed_proto, why we don't use the force_send_socket proto ?
What do you think about it ? If someone want to take a closer look,
I can post a sipp scenario which reproduce this issue.
Thanks by advance,
8:56 p.m.
On 19/08/2010 18:07, Daniel-Constantin Mierla wrote:
On 8/19/10 5:57 PM, nikita wrote:
Ok, thank you for the clarification, it solved my issue. :)
Nikita
On 19/08/2010 17:44, Daniel-Constantin Mierla
wrote:
SIP allows to register/subscribe via a transport protocol and specify
to be contacted over a different transport. So you have to put TCP in
the contact if you want to be contacted via TCP, otherwise is UDP -
default transport protocol if none is specified. Hello,
can you send a sample SUBSCRIBE request? Is the contact address
advertising TCP?
Sure, my subscribe was looking like :
SUBSCRIBE sip:2001@91.121.31.80:6060 SIP/2.0
Via: SIP/2.0/TCP 127.0.1.1:6060;branch=z9hG4bK-4179-1-0
From: test <sip:2001@127.0.1.1:6060>;tag=4179SIPpTag001
To: test <sip:2001@91.121.31.80:6060>
Contact: <sip:2001@127.0.1.1:6060>
Call-ID: 1-4179(a)127.0.1.1
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 600
Event: presence
X-Addressbook: 2001
Content-Length: 0
Looking at it, I just tried with : Contact:
<sip:2001@127.0.1.1:6060;transport=TCP> and it worked I got the
notify through TCP. Cheers,
Daniel
Cheers,
Daniel
On 8/19/10 5:30 PM, nikita wrote:
Hello list,
I have some trouble with the presence module, I'm registering and
subscribing to a presentity through TCP, and kamailio is sending me
NOTIFY to the correct ip/port, but through UDP.
I have checked in modules_k/presence/notify.c::1578, the value of
the dialog's proto field is PROTO_TCP. but It's looke like that the
function modules/tm/uac.c:t_uac_prepare() is trying to guess the
transport (in ut.h at line 319 the function sip_hostport2su choose
UDP as transport) instead of using the one present in the dialog.
And as result I'm getting this warning and the NOTIFY through the
wrong transport: 1(28921) WARNING: <core> [forward.c:248]:
WARNING: get_send_socket: protocol/port mismatch
It's maybe a foolishness from my part but why can't we just use the
dialog's transport for the notify request, so it will be the same
transport as subscribe ?
In forward.c:242, when we find that force_send_socket->proto !=
guessed_proto, why we don't use the force_send_socket proto ?
What do you think about it ? If someone want to take a closer look,
I can post a sipp scenario which reproduce this issue.
Thanks by advance,
9:05 p.m.
On 08/19/2010 06:07 PM, Daniel-Constantin Mierla wrote:
SIP allows to register/subscribe via a transport protocol and specify
to be contacted over a different transport. So you have to put TCP in
the contact if you want to be contacted via TCP, otherwise is UDP -
default transport protocol if none is specified.
Cheers,
Daniel
Diniel i think you'll aggree that in NATed environment this behaviour
is not really locgical.
The most logical thing to dis in such case is to use the
'force_send_socket' IMO.
Thanks
Vadim
Cheers,
Daniel
On 8/19/10 5:30 PM, nikita wrote:
Hello list,
I have some trouble with the presence module, I'm registering and
subscribing to a presentity through TCP, and kamailio is sending me
NOTIFY to the correct ip/port, but through UDP.
I have checked in modules_k/presence/notify.c::1578, the value of
the dialog's proto field is PROTO_TCP. but It's looke like that the
function modules/tm/uac.c:t_uac_prepare() is trying to guess the
transport (in ut.h at line 319 the function sip_hostport2su choose
UDP as transport) instead of using the one present in the dialog.
And as result I'm getting this warning and the NOTIFY through the
wrong transport: 1(28921) WARNING: <core> [forward.c:248]:
WARNING: get_send_socket: protocol/port mismatch
It's maybe a foolishness from my part but why can't we just use the
dialog's transport for the notify request, so it will be the same
transport as subscribe ?
In forward.c:242, when we find that force_send_socket->proto !=
guessed_proto, why we don't use the force_send_socket proto ?
What do you think about it ? If someone want to take a closer look,
I can post a sipp scenario which reproduce this issue.
Thanks by advance,
20 Aug
20 Aug
8:55 p.m.
2010/8/19 Vadim Lebedev <vadim(a)mbdsys.com>om>:
Diniel i think you'll aggree that in NATed
environment this behaviour is
not really locgical.
The most logical thing to dis in such case is to use the
'force_send_socket' IMO.
Hi, I don't agree. A client sending a SUBSCRIBE/INVITE/REGISTER using
TCP and containing a "Contact" without ";transport=tcp" is *not*
logical at all (even if it's valid according to the exotic RFC 3261).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5208
days inactive
5209
days old
6 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
nikita -
Vadim Lebedev