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

[nikita]

On 19/08/2010 18:07, Daniel-Constantin Mierla wrote:
>
>
> On 8/19/10 5:57 PM, nikita wrote:
>> 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.
>
> 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.

Ok, thank you for the clarification, it solved my issue. :)

Nikita

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