Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
J
jami-lrc
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 22
    • Issues 22
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Requirements
    • Requirements
    • List
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • savoirfairelinux
  • jami-lrc
  • Issues
  • #352

Closed
Open
Opened Nov 03, 2015 by RingBot@RingBotOwner

Fix unattended transfer

Issue generated from Tuleap's migration script. Originally submitted by: Alexandre Lision (alision)

When making an unattended transfer, the peer that got transfered does not see the new call, although it's properly handled in the daemon.

After some investigation I found out that when the peer receive a transfer request (refer_to field in invite), the daemon creates a new outgoing call, and hang up the previous one (as explained here: http://www.in2eps.com/fo-sip/tk-fo-sip-service-04.html).

Problem is, daemon doesn't warns that it is doing that, therefore clients can't handle this new outgoing call.

The next thing emitted by the daemon about that call is a state changed to CONNECTING. But LRC has no knowledge of this call, and rejects it.

We need to agree on what daemon should emit:

  • a simple call state change, and LRC will handle the unknown call. But in this case, we should remove the incomingCall signal and replace it by a call state change as well.

  • create a new signal just as incomingCall (or reuse the NewCallCreated signal)

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: savoirfairelinux/ring-lrc#352