Transport protocol related question - how to bind a dialog to a negotiated transport protocol
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
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
Thank you Daniel! Now its all clear and it is working fine.
regards, Klaus
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
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 -
Klaus Feichtinger