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@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,