Transport protocol related question - how to bind a dialog to a negotiated transport protocol
11 Jun
2014
11 Jun
'14
10:32 p.m.
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
12 Jun
12 Jun
12:09 a.m.
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(a)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
8:21 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3819
days inactive
3820
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Klaus Feichtinger