[jitsi-dev] blind transfer


#1

Hi,

I'm having issues with recent Jitsi builds when performing blind transfers.

Jitsi clients and SIP hardphones connect to an Asterisk PBX in our LAN. This PBX can route calls to DECT phones and other extension types via a PRI link to another PBX.

If *any* extension (any type, from any PBX) calls any Jitsi client (asterisk PBX) and the Jitsi client tries to do a blind transfer to an extension within the "remote PRI-connected" PBX, it succeeds.
However, if the Jitsi client tries to do the same to an extension within the Asterisk PBX (eg. another Jitsi client) then it "fails". It doesn't perform a blind transfer but an attended transfer.
Why is that?

Of course if I use the Asterisk built-in blind transfer feature code, Jitsi can successfully do a blind transfer.

I'm not sure the Jitsi log reveals anything regarding this unless I enable SIP debugging and I specifically dump it. Before I do this, could this be a known issue / expected behavior / etc.?

Thanks,

Vieri


#2

It would probably help if you can elaborate on your definition of
attended transfer, because it feels to me that that this is where some
of the confusion is coming from.

The only difference between a blind [0] and an attended [1] transfer
is that with the former the transferee would start a new call to the
transfer target whereas in the latter she would replace an existing
call. In order for Jitsi to mistakenly perform an attended transfer it
would therefore need to accidentally create and include in it's REFER
request a replaces header with the proper values for remote and local
tags and call ID.

Obviously this is quite unlikely so I assume that what you are
experiencing is Asterisk behaving on way when calls are being
forwarded to the PSTN and another way when calls are transferred to
internal extensions. I am afraid that the most probably cause that I
can come up with is a misconfiguration (or a bug?) in Asterisk itself.

Hope this helps,
Emil

[0] Blind Transfer Sample Flow: http://tools.ietf.org/html/rfc5359#section-2.4
[1] Attended Transfer Sample Flow:
http://tools.ietf.org/html/rfc5359#section-2.5

--sent from my mobile

···

On Apr 24, 2013 12:36 PM, "Vieri" <rentorbuy@yahoo.com> wrote:

Hi,

I'm having issues with recent Jitsi builds when performing blind transfers.

Jitsi clients and SIP hardphones connect to an Asterisk PBX in our LAN. This PBX can route calls to DECT phones and other extension types via a PRI link to another PBX.

If *any* extension (any type, from any PBX) calls any Jitsi client (asterisk PBX) and the Jitsi client tries to do a blind transfer to an extension within the "remote PRI-connected" PBX, it succeeds.
However, if the Jitsi client tries to do the same to an extension within the Asterisk PBX (eg. another Jitsi client) then it "fails". It doesn't perform a blind transfer but an attended transfer.
Why is that?

Of course if I use the Asterisk built-in blind transfer feature code, Jitsi can successfully do a blind transfer.

I'm not sure the Jitsi log reveals anything regarding this unless I enable SIP debugging and I specifically dump it. Before I do this, could this be a known issue / expected behavior / etc.?

Thanks,

Vieri


#3

Hi Emil,

My understanding of:
- blind transfer: A calls B, B dials C and A rings C while A and B are immediately disconnected
- attended transfer: A calls B, B calls C, B talks to C while A is on-hold, B transfers A to C so A and B are disconnected

In my network I have Jitsi clients as well as other SIP softphones (eg. SJphone), all registered to the same PBX. If I repeat the same steps for a blind transfer with SJphone, all's as I expect it to be. However, if I use Jitsi, instead of a blind transfer, I'm getting an attended transfer (according to my definitions above), ie. B can't disconnect from A and let A ring C (B actually dials C until C picks the phone up - meanwhile, A is left in stand-by until B decides to transfer A to C).

I hope I've explained it clearly.
If it were an Asterisk bug or misconfiguration then I suppose I couldn't perform blind trasnfers with SJphone. Or maybe SJphone is buggy or doesn't comply to standards... I might try with yet another softphone (I currently have Linphone but doesn't seem to support blind transfers via GUI).

I guess I might need to do a sip debug on this.

Vieri

···

--- On Wed, 4/24/13, Emil Ivov <emcho@jitsi.org> wrote:

It would probably help if you can
elaborate on your definition of
attended transfer, because it feels to me that that this is
where some
of the confusion is coming from.

The only difference between a blind [0] and an attended [1]
transfer
is that with the former the transferee would start a new
call to the
transfer target whereas in the latter she would replace an
existing
call. In order for Jitsi to mistakenly perform an attended
transfer it
would therefore need to accidentally create and include in
it's REFER
request a replaces header with the proper values for remote
and local
tags and call ID.

Obviously this is quite unlikely so I assume that what you
are
experiencing is Asterisk behaving on way when calls are
being
forwarded to the PSTN and another way when calls are
transferred to
internal extensions. I am afraid that the most probably
cause that I
can come up with is a misconfiguration (or a bug?) in
Asterisk itself.

Hope this helps,
Emil

[0] Blind Transfer Sample Flow: http://tools.ietf.org/html/rfc5359#section-2.4
[1] Attended Transfer Sample Flow:
http://tools.ietf.org/html/rfc5359#section-2.5

--sent from my mobile

On Apr 24, 2013 12:36 PM, "Vieri" <rentorbuy@yahoo.com> > wrote:
>
> Hi,
>
> I'm having issues with recent Jitsi builds when
performing blind transfers.
>
> Jitsi clients and SIP hardphones connect to an Asterisk
PBX in our LAN. This PBX can route calls to DECT phones and
other extension types via a PRI link to another PBX.
>
> If *any* extension (any type, from any PBX) calls any
Jitsi client (asterisk PBX) and the Jitsi client tries to do
a blind transfer to an extension within the "remote
PRI-connected" PBX, it succeeds.
> However, if the Jitsi client tries to do the same to an
extension within the Asterisk PBX (eg. another Jitsi client)
then it "fails". It doesn't perform a blind transfer but an
attended transfer.
> Why is that?
>
> Of course if I use the Asterisk built-in blind transfer
feature code, Jitsi can successfully do a blind transfer.
>
> I'm not sure the Jitsi log reveals anything regarding
this unless I enable SIP debugging and I specifically dump
it. Before I do this, could this be a known issue / expected
behavior / etc.?
>
> Thanks,
>
> Vieri
>


#4

Hey Vieri,

Hi Emil,

My understanding of: - blind transfer: A calls B, B dials C and A
rings C while A and B are immediately disconnected

B dials C is not a part of a blind transfer, just a second unrelated
call. Have you checked the diagrams I sent?

A blind transfer would be A calls B, B transfers A to C, A calls C.

- attended transfer: A calls B, B calls C, B talks to C while A is
on-hold, B transfers A to C so A and B are disconnected

Sounds right. An important part here is that A's call to C replaces B's
call with C because when B transferred A, its refer message indicated
the dialog that has to be replaced.

In my network I have Jitsi clients as well as other SIP softphones
(eg. SJphone), all registered to the same PBX. If I repeat the same
steps for a blind transfer with SJphone, all's as I expect it to be.
However, if I use Jitsi, instead of a blind transfer, I'm getting an
attended transfer (according to my definitions above),

Well, as I said, this might be a "definitions" problem so it would be
helpful if we could agree on using the SIP/IETF ones. Right now I really
don't get it.

Jitsi has a different interface for Blind and Attended transfers. A
blind transfer pops up a new "Transfer Call" dialog that lets you
transfer to any number (screenshot attached).

When an attended transfer is possible jitsi brings up a menu with the
possible calls that you can replace (screenshot attached).

Unless you use the latter I don't see how Jitsi could ever do an
attended transfer. If you use the latter then Jitsi can only do an
attended transfer.

If you want a blind transfer, you have to use the "Transfer Call" dialog.

Is this what you are doing?

ie. B can't
disconnect from A and let A ring C (B actually dials C until C picks
the phone up - meanwhile, A is left in stand-by until B decides to
transfer A to C).

OK, that's a bit more helpful, but I still don't understand. Why does B
dial anyone? B should just be sending a Refer here. If B really dials
someone then, yes, A would be placed on hold. This is not because of any
transfer, but because Jitsi to automaticall places all calls on hold
when a new one connects.

I hope I've explained it clearly. If it were an Asterisk bug or
misconfiguration then I suppose I couldn't perform blind trasnfers
with SJphone. Or maybe SJphone is buggy or doesn't comply to
standards...

I really think this is mostly an explanation problem. I just don't get
it when you say: blind transfers behave like attended ones. An attended
transfer is the replacement of one call to another. A blind transfer is
a single call to any destination where no previous calls exists. I don't
see how a call can be replaced if it doesn't exist. I am hence confused :).

I might try with yet another softphone (I currently have
Linphone but doesn't seem to support blind transfers via GUI).

I guess I might need to do a sip debug on this.

Yup, or you can also send us the logs so that we can have a look at the
SIP traces.

Cheers,
Emil

···

On 24.04.13, 13:34, Vieri wrote:

Vieri

--- On Wed, 4/24/13, Emil Ivov <emcho@jitsi.org> wrote:

It would probably help if you can elaborate on your definition of
attended transfer, because it feels to me that that this is where
some of the confusion is coming from.

The only difference between a blind [0] and an attended [1]
transfer is that with the former the transferee would start a new
call to the transfer target whereas in the latter she would replace
an existing call. In order for Jitsi to mistakenly perform an
attended transfer it would therefore need to accidentally create
and include in it's REFER request a replaces header with the proper
values for remote and local tags and call ID.

Obviously this is quite unlikely so I assume that what you are
experiencing is Asterisk behaving on way when calls are being
forwarded to the PSTN and another way when calls are transferred
to internal extensions. I am afraid that the most probably cause
that I can come up with is a misconfiguration (or a bug?) in
Asterisk itself.

Hope this helps, Emil

[0] Blind Transfer Sample Flow:
http://tools.ietf.org/html/rfc5359#section-2.4 [1] Attended
Transfer Sample Flow:
http://tools.ietf.org/html/rfc5359#section-2.5

--sent from my mobile

On Apr 24, 2013 12:36 PM, "Vieri" <rentorbuy@yahoo.com> wrote:

Hi,

I'm having issues with recent Jitsi builds when

performing blind transfers.

Jitsi clients and SIP hardphones connect to an Asterisk

PBX in our LAN. This PBX can route calls to DECT phones and other
extension types via a PRI link to another PBX.

If *any* extension (any type, from any PBX) calls any

Jitsi client (asterisk PBX) and the Jitsi client tries to do a
blind transfer to an extension within the "remote PRI-connected"
PBX, it succeeds.

However, if the Jitsi client tries to do the same to an

extension within the Asterisk PBX (eg. another Jitsi client) then
it "fails". It doesn't perform a blind transfer but an attended
transfer.

Why is that?

Of course if I use the Asterisk built-in blind transfer

feature code, Jitsi can successfully do a blind transfer.

I'm not sure the Jitsi log reveals anything regarding

this unless I enable SIP debugging and I specifically dump it.
Before I do this, could this be a known issue / expected behavior /
etc.?

Thanks,

Vieri

--
https://jitsi.org


#5

Hi Emil,

> My understanding of: - blind transfer: A calls B, B
dials C and A
> rings C while A and B are immediately disconnected

B dials C is not a part of a blind transfer, just a second
unrelated
call. Have you checked the diagrams I sent?

A blind transfer would be A calls B, B transfers A to C, A
calls C.

Right. That's what I meant, really. I was just explaining it from a user's point of view but I should have just said "B types C's extension and presses the Transfer button".

So we agree on the definitions of "blind" and "attended".

Jitsi has a different interface for Blind and Attended
transfers. A
blind transfer pops up a new "Transfer Call" dialog that
lets you
transfer to any number (screenshot attached).

Right! that's where my troubles begin.
B is Jitsi so when A calls B, B picks up the call and presses the transfer icon, the same transfer window that you attached pops up. So Jitsi clearly knows that it needs to perform a blind transfer.
Now, if B types C's extension and presses ENTER, the popup window closes and 2 things can happen (I know it's already confusing):

1) nothing happens, ie. A is still talking to B

2) A is muted (not really on-hold otherwise A would be hearing music via Asterisk, as it happens when B presses the PAUSE button) and there's a NEW call from B to C (so a new CALL DIALOG window opens up). So in this scenario, what was supposed to be a blind transfer turns out to be an attended transfer.

If B types C's extension and clicks the TRANSFER button instead of pressing ENTER then same as above.

If B types C's extension, selects the item within the list below where the typed extension appears within the "searched contact" list and then clicks the TRANSFER button then the BLIND transfer is correctly performed.
Is this expected behavior?
Does B need to select the number within "searched contact" if B already typed it within the text field?

If this is the way to go then OK although it implies an extra (redundant) step on behalf of the user.

As far as the new call from B to C coming up not 100% of the time: maybe it is an issue/bug I'm having with Asterisk. So I need more time to figure this out. However, I think you can reproduce the "searched contact" thing I described above...

Thanks,

Vieri

···

--- On Wed, 4/24/13, Emil Ivov <emcho@jitsi.org> wrote:


#6

Hey Vieri,

Hi Emil,

My understanding of: - blind transfer: A calls B, B

dials C and A

rings C while A and B are immediately disconnected

B dials C is not a part of a blind transfer, just a second
unrelated
call. Have you checked the diagrams I sent?

A blind transfer would be A calls B, B transfers A to C, A
calls C.

Right. That's what I meant, really. I was just explaining it from a user's point of view but I should have just said "B types C's extension and presses the Transfer button".

So we agree on the definitions of "blind" and "attended".

Jitsi has a different interface for Blind and Attended
transfers. A
blind transfer pops up a new "Transfer Call" dialog that
lets you
transfer to any number (screenshot attached).

Right! that's where my troubles begin.
B is Jitsi so when A calls B, B picks up the call and presses the transfer icon, the same transfer window that you attached pops up. So Jitsi clearly knows that it needs to perform a blind transfer.
Now, if B types C's extension and presses ENTER, the popup window closes and 2 things can happen (I know it's already confusing):

1) nothing happens, ie. A is still talking to B

Hm, I think I also saw this with asterisk.

2) A is muted (not really on-hold otherwise A would be hearing music via Asterisk, as it happens when B presses the PAUSE button)

Does A's call dialog say something about being on-hold?

and there's a NEW call from B to C (so a new CALL DIALOG window opens up).

Wow! Now that's a true mystery. We don't start calls when executing a
transfer. This is really strange!

So in this scenario, what was supposed to be a blind transfer turns out to be an attended transfer.

Eeer ... well ... I'd say it turns into a weird call scenario :slight_smile: but I
see what you mean. Anyway ... this doesn't really matter that much. I am
just saying that this is the part that got me confused because with
attended transfers the transferer initiates the second call manually.

If B types C's extension and clicks the TRANSFER button instead of pressing ENTER then same as above.

Hm ... how is this different from the above scenario?

If B types C's extension, selects the item within the list below where the typed extension appears within the "searched contact" list and then clicks the TRANSFER button then the BLIND transfer is correctly performed.
Is this expected behavior?

No. The same thing should happen regardless of whether you type the
number and press Enter or you pick the contact and do initiate the
transfer with the mouse.

Does B need to select the number within "searched contact" if B already typed it within the text field?

No.

If this is the way to go then OK although it implies an extra (redundant) step on behalf of the user.

As far as the new call from B to C coming up not 100% of the time: maybe it is an issue/bug I'm having with Asterisk.

It could be.

So I need more time to figure this out. However, I think you can reproduce the "searched contact" thing I described above...

Actually the only one I can reproduce is 1). We'll look at this.
Otherwise I tried a bunch of transfers using Enter now and they all just
worked ....

Cheers,
Emil

···

On 24.04.13, 14:56, Vieri wrote:

--- On Wed, 4/24/13, Emil Ivov <emcho@jitsi.org> wrote:

Thanks,

Vieri

--
https://jitsi.org


#7

OK Emil, thanks.
If everything else works for you then I really must have something wrong.
Apart from Asterisk, what other SIP servers/proxies do you usually test Jitsi with (freeswitch, kamailio)?
Just asking so I can make my own tests and compare.

Thanks,

Vieri

···

--- On Wed, 4/24/13, Emil Ivov <emcho@jitsi.org> wrote:

> Now, if B types C's extension and presses ENTER, the
popup window closes and 2 things can happen (I know it's
already confusing):
>
> 1) nothing happens, ie. A is still talking to B

Hm, I think I also saw this with asterisk.

Actually the only one I can reproduce is 1). We'll look at
this.


#8

Hey Vieri,

···

On 24.04.13, 17:12, Vieri wrote:

--- On Wed, 4/24/13, Emil Ivov <emcho@jitsi.org> wrote:

Now, if B types C's extension and presses ENTER, the

popup window closes and 2 things can happen (I know it's
already confusing):

1) nothing happens, ie. A is still talking to B

Hm, I think I also saw this with asterisk.

Actually the only one I can reproduce is 1). We'll look at
this.

OK Emil, thanks.
If everything else works for you then I really must have something wrong.
Apart from Asterisk, what other SIP servers/proxies do you usually test Jitsi with (freeswitch, kamailio)?
Just asking so I can make my own tests and compare.

We do a lot of testing with asterisk and ippi.com (which runs OpenSIPS).

Dan Bogos has promised to help us with the deployment of a Kamailio
server on jit.si around June and we hope to be able to use that as a
reference implementation.

Cheers,
Emil

--
https://jitsi.org