[sr-dev] NOTIFY being sent through UDP instead of TCP
Daniel-Constantin Mierla
miconda at gmail.com
Thu Aug 19 18:07:00 CEST 2010
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.
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,
>>>
>>
>
--
Daniel-Constantin Mierla
http://www.asipto.com/
More information about the sr-dev
mailing list