sessionId property ties together multiple legs of a call

  • 1
  • Question
  • Updated 2 years ago
We have inbound calls that get transferred one or more times within the company. When I look at the json data for those multiple legs, there is nothing that ties them together. I saw a post from Benjamin Dean that states:
"You can use the `sessionId` property as that is unique across multiple legs of a call. Does that answer your last question?"
https://devcommunity.ringcentral.com/ringcentraldev/topics/outbound-call-issue

In my json data, the sessionId changes for each leg. Is there some setting that I need to change so that the sessionId will stay the same for each leg of the call?
Photo of Brian Blank

Brian Blank

  • 140 Points 100 badge 2x thumb

Posted 2 years ago

  • 1
Photo of Anton Nikitin

Anton Nikitin, Official Rep

  • 2,914 Points 2k badge 2x thumb
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 devsupport@ringcentral.com
Photo of Brian Blank

Brian Blank

  • 140 Points 100 badge 2x thumb
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 

Photo of Anton Nikitin

Anton Nikitin, Official Rep

  • 2,914 Points 2k badge 2x thumb
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).
Photo of Brian Blank

Brian Blank

  • 140 Points 100 badge 2x thumb
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.
Photo of Anton Nikitin

Anton Nikitin, Official Rep

  • 2,914 Points 2k badge 2x thumb
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:

http://success.ringcentral.com/articles/RC_Knowledge_Article/Transferring-calls-via-IP-phones
http://success.ringcentral.com/articles/RC_Knowledge_Article/901
http://success.ringcentral.com/articles/RC_Knowledge_Article/8051

In the last article - transfer button lets you choose warm or blind transfer.
Photo of Brian Blank

Brian Blank

  • 140 Points 100 badge 2x thumb
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?
(Edited)
Photo of Anton Nikitin

Anton Nikitin, Official Rep

  • 2,914 Points 2k badge 2x thumb
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?
Photo of Brian Blank

Brian Blank

  • 140 Points 100 badge 2x thumb

We are experiencing the same result with a blind transfer


Photo of Anton Nikitin

Anton Nikitin, Official Rep

  • 2,914 Points 2k badge 2x thumb
Brian, can you provide more details about your scenario with blind transfer? I have just tried it myself and I can see all legs under the same session ID. There can be some differences in internal processing, so it is important to know if your legs are VOIP or PSTN, is it outbound or inbound call, from which party's standpoint you are looking at API results, etc.
Photo of Brian Blank

Brian Blank

  • 140 Points 100 badge 2x thumb

Anton,

This is the exact description:

I have a cell phone and I call a ring central phone number, (Polycom vvx410) I answer the call on the ring central handset, say a few words, press the transfer button on the handset, dial an extension (on the same account) then hangup before the other extension answers the call, it rings on the other extension, I pick it up, say a few words then end the call.  The json data downloaded from the call log shows two different instance id's along with two recordings.  From my vantage point regardless of technicality the call is the same as it originated from a cell phone was answered then passed to another party (same RC account).  So if I were to evaluate the call to see if my staff were performing as expected I only had one call, but I see two calls in RC logs with no way of knowing it was the same call.  Now lets look at background information, the RC handsets are the Polycoms as noted above and the are no softphones or other devices involved, however there was a POD change on the account that allows for recording a message before being answered by the party receiving the call.  I cannot define that POD change as that is all I know.  If it is firmware or a new software version or whatever, that is unknown.  The issue revolving the session ID is less important if I can see that the call was transferred and where it went and that there is enough call detail to identify that it is the same call.  The Polycoms are hooked through standard broadband connecting to RC, so every handset is VOIP. the transfer process i described is known by me as a blind transfer, but I get the same results if I soft-transfer.  (RE the POD change, I never had the session information until after the POD change, so I do not know if it worked before.)

Photo of Anton Nikitin

Anton Nikitin, Official Rep

  • 2,914 Points 2k badge 2x thumb
Brian,

are you sure that "Default Transfer Type" is set on your Polycom phone to "Blind transfer" as suggested in http://success.ringcentral.com/articles/RC_Knowledge_Article/Transferring-calls-via-IP-phones ? If it is set as "Consultative" then the phone performs warm transfer and there will be different session IDs.

I understand your problem with warm transfer and we will try to find a solution, but in the mean time, do you think that proper blind transfer which preserves session ID will fix your issue?