Hi Brian,
Can you provide more details? Ideally HTTP Response trace showing multiple sessionId for different legs of the same call?
You can send it to the developer support team and create a support ticket.
Here is the json data for the three legs of a call. I listed to the recordings and verified that it is one call being transferred two different times. Notice that the sessionId is different in all three legs
They are not legs of the same call, they are technically different calls. When the warm transfer is initiated it creates a new session. As you can see even recording IDs are different. If user initiates blind transfer all legs will be in one session (in this case you will be able to see legs by calling the api with "view=Detailed" parameter).
How do we initiate a transfer that will not be considered a warm transfer?
Here is a discussion of the same issue:
https://devcommunity.ringcentral.com/ringcentraldev/topics/ringout-quirks Hrm...that's a problem indeed. I was under the assumption that sessionId was supposed to be a unique identifier across multiple legs of a cal (and at first glance the numbers are nearly identical except for a single digit).
So I went to our engineering team and here is the answer they provided me:
Usually RingOut has just one presence event when "from" number is 1) either external PSTN number 2) or direct device (DL) number associated with extension.
In this particular case, there are really two sessions because you have specified your own RC phone number as a "from" number.
If we need to forward our calls in a different way so that each leg can be tied together by sessionId, then we can do that.
It depends on how you make/answer the call (on deskphone, softphone, mobile app, etc). There are some Knowledge Base articles you can check out:
https://support.ringcentral.com/article/Deskphones-Transfer-Calls.html
https://support.ringcentral.com/article/901.html
https://support.ringcentral.com/article/8051.html
In the last article - transfer button lets you choose warm or blind transfer.
We have been successfully transferring calls using both the blind and warm methods. The problem remains that we have found no way of tying the different legs of the call together. Each leg has a different sessionId. No other data seems to be able to tie them together.
Is this a bug in the software, as is alluded to in the post mentioned above, or am I missing something?
Brian, let me clarify:
1) Do you experience the same issue with blind transfers? I am pretty sure that in case of blind transfer you will have the same session ID across all legs.
2) In case of warm transfer technically there are two separate calls so they have different session IDs. You are right, these calls are logically linked by transfer operation. At the moment we do not return any indication in a call log about such link but we can consider it as a future API enhancement. The way how we can implement it is returning previous session ID(s) along with current session ID (there may be a sequence of transfers). Will it solve your problem if call log will have this information?
