6 Mar
2009
6 Mar
'09
10:36 a.m.
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
6 Mar
6 Mar
10:39 a.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
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(a)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
http://www.asipto.com
11:46 a.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
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
11:58 a.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
On 03/06/2009 11:46 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
ok, I will check it and fix.
Thanks,
Daniel
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
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)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
http://www.asipto.com
12:06 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
2009/3/6 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
humm, I remember reporting this exact bug and it was fixed... maybe I
reported it in OpenSIPS.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
12:08 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
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
3:36 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=5…
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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
3:46 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
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=5…
Juha Heinanen schrieb:
--
Daniel-Constantin Mierla
http://www.asipto.com
i would just like to add that in this example, i
had kamailio sip proxy
in front of kamailio presence server:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
+++ 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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
7 Mar
7 Mar
2:41 a.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
Klaus Darilion writes:
i looked at the patch and it seems to solve the problem.
-- juha
8 Mar
8 Mar
8:07 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
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:
i looked at the patch and it seems to solve the problem.
-- juha
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)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
http://www.asipto.com
8:18 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
2009/3/8 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:24 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
Hello,
On 03/08/2009 08:18 PM, Iñaki Baz Castillo wrote:
2009/3/8 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
NOTIFY will have in r-uri the contact from SUBSCRIBE not the contact
from 200ok.
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).
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
--
Daniel-Constantin Mierla
http://www.asipto.com
8:29 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
2009/3/8 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Yes, that waht I mean since the SUBSCRIBE in the examples does contain
"transport=tcp2 :)
Well, when I reported whit bug in OpenSIPS it did exist. Have been
changes in Kamailio presence module fixing this behaviour?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
8:36 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
On 03/08/2009 08:29 PM, Iñaki Baz Castillo wrote:
2009/3/8 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
Yes, that waht I mean since the SUBSCRIBE in the examples does contain
"transport=tcp2 :)
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
--
Daniel-Constantin Mierla
http://www.asipto.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.
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.
9 Mar
9 Mar
9:12 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
El Domingo, 8 de Marzo de 2009, Daniel-Constantin Mierla escribió:
Ok, thanks for pointint it. :)
--
Iñaki Baz Castillo
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.
5:07 a.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
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
11:28 p.m.
New subject: [Kamailio-Users] bug in subscribe when contact uses tcp transport?
Hello Juha,
On 03/09/2009 05:07 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
ok, good it is working.
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?
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
http://www.asipto.com
5743
days inactive
5746
days old
16 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion