#94: When "481 Subscription does not exist" is received, a *new* SUBSCRIBE
should be generated
---------------------+------------------------------------------------------
Reporter: ibc | Owner: vadim
Type: defect | Status: reopened
Priority: major | Milestone: QuteCom 2.2-RC4
Component: phapi | Version: 2.2-RC3
Resolution: | Keywords: presence subscribe
---------------------+------------------------------------------------------
Comment(by ibc):
After several hours of testing and debugging I think that I've found the
bug:
* Qutecom "sometimes" doesn't react when receiving a NOTIFY so
retransmissions are sent by the presence server.
* The last retransmissions arrives 1-2 seconds later so the '''real'''
"expires" values is not so "real".
* So when Qutecom sends the refresh SUBSCRIBE it arrives 1-2 seconds
after the subscription has expired in the presence server and receives a
481.
* Then Qutecom sends a '''new''' initial SUBSCRIBE (correct) and receives
a NOTIFY.
* The next refresh SUBSCRIBE for the new subscription is wrong since it
doesn't contain "Route" header (required of course since it's an in-dialog
request and the proxy is doing loose-routing prefectly). So the proxy
rejects the SUBSCRIBE with "403".
* After this occurs, Qutecom doesn't send any SUBSCRIBE anymore.
I attach a complete SIP trace showing and explaining in detail this issue,
please check it.
My recommendation/suggesitions for this issue:
* Qutecom should send the refresh SUBSCRIBE 5-10 seconds before it
expires to avoid the 481 when a retransmission has occurred in some
NOTIFY. This is the way in which other softphones work. So, if a NOTIFY
says "expires=30" then Qutecom should send the next refresh SUBSCRIBE
after 20-25 seconds.
* Qutecom should react on '''any''' negative response (as 403, 500,
503...). For now, if it receives it, the subscription ends forever since
Qutecom won't send SUBSCRIBE anymore.
--
Ticket URL: <http://trac.qutecom.org/ticket/94#comment:5>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
