if user subscribes using tcp transport, kamailio presence server replies with 200 ok where contact specifies udp transport. this looks like a bug to me, because re-subscribe to contact uri then uses udp transport, which may not even be enabled by firewall between ua and kamailio.
do others agree that this is a bug? if so, any volunteers to fix it?
-- juha
+++ 6-3-2009 10:27:39.692364 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKrzmiknas Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=gonhy Call-ID: ljkaayblocflyyu@taimen CSeq: 62 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 10:27:39.707261 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=54705;branch=z9hG4bKrzmiknas To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-a5a3 From: "Juha Heinanen" sip:jh@test.fi;tag=gonhy Call-ID: ljkaayblocflyyu@taimen CSeq: 62 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-pre2-tls (i386/linux)) Content-Length: 0
Hello Juha,
I see you use a pre-release version. Please update to latest one, I fixed several bugs regarding transport. If still there, then I will fix it.
Cheers, Daniel
On 03/06/2009 10:36 AM, Juha Heinanen wrote:
if user subscribes using tcp transport, kamailio presence server replies with 200 ok where contact specifies udp transport. this looks like a bug to me, because re-subscribe to contact uri then uses udp transport, which may not even be enabled by firewall between ua and kamailio.
do others agree that this is a bug? if so, any volunteers to fix it?
-- juha
+++ 6-3-2009 10:27:39.692364 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKrzmiknas Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=gonhy Call-ID: ljkaayblocflyyu@taimen CSeq: 62 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 10:27:39.707261 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=54705;branch=z9hG4bKrzmiknas To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-a5a3 From: "Juha Heinanen" sip:jh@test.fi;tag=gonhy Call-ID: ljkaayblocflyyu@taimen CSeq: 62 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-pre2-tls (i386/linux)) Content-Length: 0
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla writes:
I see you use a pre-release version. Please update to latest one, I fixed several bugs regarding transport. If still there, then I will fix it.
sorry about that. i had forgotten to upgrade my presence server. i did it now and the same result.
-- juha
----------------------------------------------------------------------
+++ 6-3-2009 11:44:07.897113 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKjyriojar Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:44:07.913387 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=45696;branch=z9hG4bKjyriojar To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-1dda From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
On 03/06/2009 11:46 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I see you use a pre-release version. Please update to latest one, I fixed several bugs regarding transport. If still there, then I will fix it.
sorry about that. i had forgotten to upgrade my presence server. i did it now and the same result.
ok, I will check it and fix.
Thanks, Daniel
-- juha
+++ 6-3-2009 11:44:07.897113 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKjyriojar Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:44:07.913387 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=45696;branch=z9hG4bKjyriojar To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-1dda From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/3/6 Daniel-Constantin Mierla miconda@gmail.com:
sorry about that. i had forgotten to upgrade my presence server. i did it now and the same result.
ok, I will check it and fix.
humm, I remember reporting this exact bug and it was fixed... maybe I reported it in OpenSIPS.
i would just like to add that in this example, i had kamailio sip proxy in front of kamailio presence server:
+++ 6-3-2009 11:44:07.897113 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKjyriojar Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:44:07.913387 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=45696;branch=z9hG4bKjyriojar To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-1dda From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
and that actually works because the front end proxy adds r-r header to the subscribe request and that makes the subscriber to use tcp also for in-dialog subscribes.
however, if i have integrated sip proxy/presence server, i get the earlier described situation, where in-dialog subscribes would be sent via udp:
+++ 6-3-2009 11:58:48.202576 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKcjentvff Max-Forwards: 70 Proxy-Authorization: Digest username="jh",realm="test.fi",nonce="49b0f3f60000000cfef7715324b37ecd354fa849a881407f",uri="sip:test@test.fi",response="1dafa05560f703932997381d497cdb10",algorithm=MD5,cnonce="4a6bc45fed",qop=auth,nc=00000001 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:58:48.212542 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Via: SIP/2.0/TCP 192.98.101.10:5074;rport=51275;branch=z9hG4bKcjentvff To: sip:test@test.fi;tag=8056f5a66bd796abc1d40ab829a9781f-44eb From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5060;transport=tcp Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
so at least in the case when presence server receives a subscribe without r-r headers, it should use in its 200 ok contact the same transport as what was in subscribe's contact.
-- juha
http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=50...
Juha Heinanen schrieb:
i would just like to add that in this example, i had kamailio sip proxy in front of kamailio presence server:
+++ 6-3-2009 11:44:07.897113 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKjyriojar Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:44:07.913387 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=45696;branch=z9hG4bKjyriojar To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-1dda From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
and that actually works because the front end proxy adds r-r header to the subscribe request and that makes the subscriber to use tcp also for in-dialog subscribes.
however, if i have integrated sip proxy/presence server, i get the earlier described situation, where in-dialog subscribes would be sent via udp:
+++ 6-3-2009 11:58:48.202576 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKcjentvff Max-Forwards: 70 Proxy-Authorization: Digest username="jh",realm="test.fi",nonce="49b0f3f60000000cfef7715324b37ecd354fa849a881407f",uri="sip:test@test.fi",response="1dafa05560f703932997381d497cdb10",algorithm=MD5,cnonce="4a6bc45fed",qop=auth,nc=00000001 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:58:48.212542 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Via: SIP/2.0/TCP 192.98.101.10:5074;rport=51275;branch=z9hG4bKcjentvff To: sip:test@test.fi;tag=8056f5a66bd796abc1d40ab829a9781f-44eb From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5060;transport=tcp Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
so at least in the case when presence server receives a subscribe without r-r headers, it should use in its 200 ok contact the same transport as what was in subscribe's contact.
-- juha
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
I am not sure this applies any longer. I did some changes there, I am taking care of it.
Cheers, Daniel
On 03/06/2009 03:36 PM, Klaus Darilion wrote:
http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=50...
Juha Heinanen schrieb:
i would just like to add that in this example, i had kamailio sip proxy in front of kamailio presence server:
+++ 6-3-2009 11:44:07.897113 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKjyriojar Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:44:07.913387 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=45696;branch=z9hG4bKjyriojar To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-1dda From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
and that actually works because the front end proxy adds r-r header to the subscribe request and that makes the subscriber to use tcp also for in-dialog subscribes.
however, if i have integrated sip proxy/presence server, i get the earlier described situation, where in-dialog subscribes would be sent via udp:
+++ 6-3-2009 11:58:48.202576 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKcjentvff Max-Forwards: 70 Proxy-Authorization: Digest username="jh",realm="test.fi",nonce="49b0f3f60000000cfef7715324b37ecd354fa849a881407f",uri="sip:test@test.fi",response="1dafa05560f703932997381d497cdb10",algorithm=MD5,cnonce="4a6bc45fed",qop=auth,nc=00000001 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:58:48.212542 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Via: SIP/2.0/TCP 192.98.101.10:5074;rport=51275;branch=z9hG4bKcjentvff To: sip:test@test.fi;tag=8056f5a66bd796abc1d40ab829a9781f-44eb From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5060;transport=tcp Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
so at least in the case when presence server receives a subscribe without r-r headers, it should use in its 200 ok contact the same transport as what was in subscribe's contact.
-- juha
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Klaus Darilion writes:
http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=50...
i looked at the patch and it seems to solve the problem.
-- juha
Hello Juha,
reviewing your examples, all seems fine. In the first case it is UDP contact because the first proxy is doing transport gateway (tcp-to-udp) and presence server get's the SUBSCRIBE via UDP. Therefore it sets the protocol to UDP.
+++ 6-3-2009 11:44:07.897113 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKjyriojar Max-Forwards: 70 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:44:07.913387 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: sip:192.98.101.10;r2=on;lr Record-Route: sip:192.98.101.10;transport=tcp;r2=on;lr Via: SIP/2.0/TCP
192.98.101.10:5074;received=192.98.101.10;rport=45696;branch=z9hG4bKjyriojar
To: sip:test@test.fi;tag=3d2810ff0e005fca9b24aee8694a9a3d-1dda From: "Juha Heinanen" sip:jh@test.fi;tag=bdxzr Call-ID: rtiqagnmchyfjbd@taimen CSeq: 15 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5082 Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
In your second example, with presence server integrated in first proxy, the contact is TCP in 200ok:
+++ 6-3-2009 11:58:48.202576 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKcjentvff Max-Forwards: 70 Proxy-Authorization: Digest username="jh",realm="test.fi",nonce="49b0f3f60000000cfef7715324b37ecd354fa849a881407f",uri="sip:test@test.fi",response="1dafa05560f703932997381d497cdb10",algorithm=MD5,cnonce="4a6bc45fed",qop=auth,nc=00000001 To: sip:test@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Contact: sip:jh@192.98.101.10:5074;transport=tcp Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0
+++ 6-3-2009 11:58:48.212542 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Via: SIP/2.0/TCP 192.98.101.10:5074;rport=51275;branch=z9hG4bKcjentvff To: sip:test@test.fi;tag=8056f5a66bd796abc1d40ab829a9781f-44eb From: "Juha Heinanen" sip:jh@test.fi;tag=wkpvh Call-ID: ajddfsugncegcre@taimen CSeq: 354 SUBSCRIBE Expires: 3600 Contact: sip:192.98.101.10:5060;transport=tcp Server: OpenXg Kamailio (1.5.0-tls (i386/linux)) Content-Length: 0
Did I miss something? I see not bug in this behavior.
The transport for contact was fixed some time ago. However, during the tests done now I discovered some other issues, like adding double transport parameter when server contact is not specified and missing support for SCTP in some cases. I will commit soon.
Cheers, Daniel
On 03/07/2009 02:41 AM, Juha Heinanen wrote:
Klaus Darilion writes:
http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=50...
i looked at the patch and it seems to solve the problem.
-- juha
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/3/8 Daniel-Constantin Mierla miconda@gmail.com:
Hello Juha,
reviewing your examples, all seems fine. In the first case it is UDP contact because the first proxy is doing transport gateway (tcp-to-udp) and presence server get's the SUBSCRIBE via UDP. Therefore it sets the protocol to UDP.
Yes. It must be checked that the NOTIFY frmo the presence server have a RURI containing "transport=tcp".
But the bug I reported in OpenSIPS was the opposite:
Phone ---(UDP)--- Proxy ---(TCP)--- PresenceServer
I route the SUBSCRIBE to the PresenceServer using TCP by seting: $du="sip:PresenceServer;transport=tcp"
but the 202 replied by the presence server contains a "Contact" with no "transport=tcp". This means that refresh-SUBSCRIBE's from the phone would fail since they would be routed to the PresenceServer using UDP (in case of firewall they'll fail).
Hello,
On 03/08/2009 08:18 PM, Iñaki Baz Castillo wrote:
2009/3/8 Daniel-Constantin Mierla miconda@gmail.com:
Hello Juha,
reviewing your examples, all seems fine. In the first case it is UDP contact because the first proxy is doing transport gateway (tcp-to-udp) and presence server get's the SUBSCRIBE via UDP. Therefore it sets the protocol to UDP.
Yes. It must be checked that the NOTIFY frmo the presence server have a RURI containing "transport=tcp".
NOTIFY will have in r-uri the contact from SUBSCRIBE not the contact from 200ok.
But the bug I reported in OpenSIPS was the opposite:
Phone ---(UDP)--- Proxy ---(TCP)--- PresenceServer
I route the SUBSCRIBE to the PresenceServer using TCP by seting: $du="sip:PresenceServer;transport=tcp"
but the 202 replied by the presence server contains a "Contact" with no "transport=tcp". This means that refresh-SUBSCRIBE's from the phone would fail since they would be routed to the PresenceServer using UDP (in case of firewall they'll fail).
The 200ok for SUBSCRIBE has the transport=tcp in this case and the proxy will add 2 R-R headers to allow udp-tcp translations.
Cheers, Daniel
2009/3/8 Daniel-Constantin Mierla miconda@gmail.com:
Yes. It must be checked that the NOTIFY frmo the presence server have a RURI containing "transport=tcp".
NOTIFY will have in r-uri the contact from SUBSCRIBE not the contact from 200ok.
Yes, that waht I mean since the SUBSCRIBE in the examples does contain "transport=tcp2 :)
But the bug I reported in OpenSIPS was the opposite:
Phone ---(UDP)--- Proxy ---(TCP)--- PresenceServer
I route the SUBSCRIBE to the PresenceServer using TCP by seting: $du="sip:PresenceServer;transport=tcp"
but the 202 replied by the presence server contains a "Contact" with no "transport=tcp". This means that refresh-SUBSCRIBE's from the phone would fail since they would be routed to the PresenceServer using UDP (in case of firewall they'll fail).
The 200ok for SUBSCRIBE has the transport=tcp in this case and the proxy will add 2 R-R headers to allow udp-tcp translations.
Well, when I reported whit bug in OpenSIPS it did exist. Have been changes in Kamailio presence module fixing this behaviour?
Regards.
On 03/08/2009 08:29 PM, Iñaki Baz Castillo wrote:
2009/3/8 Daniel-Constantin Mierla miconda@gmail.com:
Yes. It must be checked that the NOTIFY frmo the presence server have a RURI containing "transport=tcp".
NOTIFY will have in r-uri the contact from SUBSCRIBE not the contact from 200ok.
Yes, that waht I mean since the SUBSCRIBE in the examples does contain "transport=tcp2 :)
But the bug I reported in OpenSIPS was the opposite:
Phone ---(UDP)--- Proxy ---(TCP)--- PresenceServer
I route the SUBSCRIBE to the PresenceServer using TCP by seting: $du="sip:PresenceServer;transport=tcp"
but the 202 replied by the presence server contains a "Contact" with no "transport=tcp". This means that refresh-SUBSCRIBE's from the phone would fail since they would be routed to the PresenceServer using UDP (in case of firewall they'll fail).
The 200ok for SUBSCRIBE has the transport=tcp in this case and the proxy will add 2 R-R headers to allow udp-tcp translations.
Well, when I reported whit bug in OpenSIPS it did exist. Have been changes in Kamailio presence module fixing this behaviour?
yes, there were several fixes including this one and I just committed some extra discovered while testing now.
Cheers, Daniel
El Domingo, 8 de Marzo de 2009, Daniel-Constantin Mierla escribió:
Well, when I reported whit bug in OpenSIPS it did exist. Have been changes in Kamailio presence module fixing this behaviour?
yes, there were several fixes including this one and I just committed some extra discovered while testing now.
Ok, thanks for pointint it. :)
Daniel-Constantin Mierla writes:
Did I miss something? I see not bug in this behavior.
daniel,
i must have been too busy when i sent the message. integrated presence server when provided tcp contact in subscribe indeed uses tcp in its 200 ok response.
since there is still lots of 1.4 versions on the field, would it be possible to patch also 1.4 branch?
-- juha
Hello Juha,
On 03/09/2009 05:07 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Did I miss something? I see not bug in this behavior.
daniel,
i must have been too busy when i sent the message. integrated presence server when provided tcp contact in subscribe indeed uses tcp in its 200 ok response.
ok, good it is working.
since there is still lots of 1.4 versions on the field, would it be possible to patch also 1.4 branch?
The modules from 1.5 should work out of the box with 1.4. My plan is to test them a while in 1.5 and backport before next minor release 1.4.x.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion