[SR-Users] Transport protocol related question - how to bind a dialog to a negotiated transport protocol

[Klaus Feichtinger]

Hello,

I wonder if it is allowed using transport protocol UDP for SIP NOTIFY 
requests (which are generated by Kamailio/presence module), when the 
SUBSCRIBE dialog was established using TCP as transport protocol.
In other words: this is a principal question if it is allowed changing 
the transport protocol for in-dialog transactions e.g. from TCP to UDP. 
Initially I rather thought that in-dialog transactions shall use the 
same transport protocol as the dialog itself (e.g. SIP INFO requests 
within a standard media session), except the message would be too big 
for UDP, where a change to TCP is recommended.

Can anybody give me a hint, if the current behaviour of Kamailio is 
correct or not? Or - how can I bind Kamailio to a specific transport 
protocol (for messages that are created by modules themselves)? Kamailio 
is sending NOTIFY requests with UDP, even when the subscription was done 
with TCP (see excerpt below).

09:58:10.360749 IP (tos 0x0, ttl 64, id 35302, offset 0, flags [DF], 
proto TCP (6), length 444) 10.1.1.14.37883 > 10.1.1.44.5060: P, cksum 
0x1cb3 (correct), 1:393(392) ack 1 win 457 <nop,nop,timestamp 624699305 
795715664>
SUBSCRIBE sip:116006 at 10.1.1.44;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 10.1.1.14:5070;rport;branch=z9hG4bK1540213071
From: <sip:1 at 10.1.1.14:5070>;tag=620071678
To: <sip:116006 at 10.1.1.44;transport=TCP>
Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Contact: <sip:1 at 10.1.1.14:37883>
Max-Forwards: 70
Expires: 1200
Event: presence
Content-Length: 0


09:58:10.361324 IP (tos 0x10, ttl 64, id 65438, offset 0, flags [DF], 
proto TCP (6), length 431) 10.1.1.44.5060 > 10.1.1.14.37883: P, cksum 
0x29fb (correct), 1:380(379) ack 393 win 215 <nop,nop,timestamp 
795715792 624699305>
SIP/2.0 202 OK
Via: SIP/2.0/TCP 10.1.1.14:5070;rport=37883;branch=z9hG4bK1540213071
From: <sip:1 at 10.1.1.14:5070>;tag=620071678
To: 
<sip:116006 at 10.1.1.44;transport=TCP>;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed
Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Expires: 1200
Contact: <sip:10.1.1.44:5060;transport=tcp>
Content-Length: 0


09:58:10.361507 IP (tos 0x10, ttl 64, id 32295, offset 0, flags [none], 
proto UDP (17), length 484) 10.1.1.44.5060 > 10.1.1.14.37883: SIP, 
length: 456
NOTIFY sip:1 at 10.1.1.14:37883 SIP/2.0
Via: SIP/2.0/UDP 
10.1.1.44;branch=z9hG4bKc408.509e6347000000000000000000000000.0
To: sip:1 at 10.1.1.14;tag=620071678
From: sip:116006 at 10.1.1.44;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed
CSeq: 2 NOTIFY
Call-ID: 449986375
Content-Length: 0
User-Agent: kamailio (4.0.4 (i386/linux))
Max-Forwards: 70
Event: presence
Contact: <sip:10.1.1.44:5060;transport=tcp>
Subscription-State: active;expires=1200

Thx
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140611/67cf97b5/attachment.html>