[ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP

SourceForge.net
Bugs item #2335193, was opened at 2008-11-24 00:35
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Presence server forces refresh SUBSCRIBE's being always UDP

Initial Comment:
Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module.
This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence
server has a Contact with no "transport=tcp":

-------------
# alice -> OpenSIPS (with presence server)
SUBSCRIBE sip:[hidden email] SIP/2.0
Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw
Contact: <sip:alice@192.168.0.129:6060;transport=tcp>
Event: presence

# OpenSIPS -> alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw
Contact: <sip:[hidden email]:5060>
--------------

As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp").

While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense:
Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost.

IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK.


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-25 19:25

Message:
OK - perfect - I will do the backport and also check if there are other
similar cases.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-25 16:21

Message:
It seems to work properly now.
Thanks.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-25 15:33

Message:
check the revision 5032. It was my fault - the commit failed because I
didn't updated the sources first.

Try now.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-25 13:13

Message:
Could you please say me which rev has the patch? I've done a svn update and
got:

U    socket_info.h
U    modules/nat_traversal/nat_traversal.c
U    modules/acc/acc.c
U    modules/tm/doc/tm_admin.xml
U    modules/tm/uac.c
U    modules/tm/README
Actualizado a la revisión 5031.

(I think no one of these modules are involved in this report, are they?)


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-25 12:53

Message:
Hi Iñaki,

I just commited a fix on SVN trunk - could you please test it - it was a
blind fix :D...

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel