Hello,

the request within dialogs are sent to the address in the Contact header of the request/response creating the dialog. In you trace, the SUBSCRIBE has a Contact with no transport, the default one being UDP.

Of course, a higher priority than Contact in sending would be Record-Route, but it is not the case of your example.

In other words, SIP allows to create dialogs on one transport and request a follow up on another transport. Even the response to a request can have different destination (ip, port or protocol) than the address from where the request was sent, Via header specifying where it should be sent.

Cheers,
Daniel

On 11/06/14 21:32, Klaus Feichtinger wrote:

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@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@10.1.1.14:5070>;tag=620071678
To: <sip:116006@10.1.1.44;transport=TCP>
Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Contact: <sip:1@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@10.1.1.14:5070>;tag=620071678
To: <sip:116006@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@10.1.1.14:37883 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.44;branch=z9hG4bKc408.509e6347000000000000000000000000.0
To: sip:1@10.1.1.14;tag=620071678
From: sip:116006@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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda