Hello, After the recent discussion on jingle hold, I realised some things.
- For the compatibility case, if the other side is an older version that does not support informational messages or the senders="" hack, then the Hold interface should not be present. - If the other end is the new jingle, then the informational messages are optional and the other end could return "feature-not-implemented/unsupported-info", so Hold can fail. That information should be transmitted to the UI so further actions can be taken. - In the case of SIP, the same thing could happen, if I send a direction change to "none", the other side could very well reply with an inverse direction change (ie, refuse the hold), in which case we should also fail the hold (I don't know if anyone implements it this way, but I can see no reason why someone wouldn't have done it). For the last two cases, we should allow the folowing: Hold refused by other party: (Unheld, any reason) → (Pending_Hold, Requested) → (Unheld, Rejected) -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd
signature.asc
Description: This is a digitally signed message part
_______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
