[sr-dev] NOTIFY being sent through UDP instead of TCP

nikita nikita at mbdsys.com
Thu Aug 19 17:57:18 CEST 2010


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 at 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 at 127.0.1.1:6060>;tag=4179SIPpTag001
To: test <sip:2001 at 91.121.31.80:6060>
Contact: <sip:2001 at 127.0.1.1:6060>
Call-ID: 1-4179 at 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 at 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,
>>
>




More information about the sr-dev mailing list