13 Apr
2011
13 Apr
'11
2:49 p.m.
Hello all,
I'm having problems with attended transfer in certain scenarios. Let me first try to
document the relevant parts of the setup:
There are two load-balanced Asterisk gateways connected to the old Nortel system.
Currently, PSTN connections are done by Nortel. We then have two load-balanced kamailio
servers. The phones are connected to these. There are several other servers not relevant
to this question.
Blind transfer works in any scenario. I've been told that attended transfer works in
any scenario if the original call is SIP to SIP. If the original call is from Nortel/PSTN
to SIP, then attended transfer will usually not work.
Scenarios:
A call comes in from Nortel/PSTN (user A) through Nortel1 to a SIP device (user B). User B
pushes the transfer button (puts current call on hold and makes a new call) and dials a
Nortel / PSTN number to user C. This call goes out through the nortel2 server. Users B and
C talk a short while before user B pushes the Transfer button again to connect users A and
C. In this scenario, the REFER is forwarded by kamailio to nortel1, which replies
"SIP/2.0 481 Call leg/transaction does not exist." The call to join is of course
on the other asterisk (nortel2).
A similar scenario is where user B transfers to another SIP user. This call will only
exist in one of the kamailio servers, and Asterisk will give the same response to the
REFER.
A third scenario is where both calls are handled by the same Asterisk server. This
scenario works.
I'm assuming I'll have to build REFER-handling logic into kamailio, but am unsure
of how to proceed. Any suggestions?
Thanks in advance.
With kind regards,
Pan
16 Apr
16 Apr
3:20 p.m.
2011/4/13 Pan B. Christensen <pan(a)ibidium.no>no>:
Scenarios:
A call comes in from Nortel/PSTN (user A) through Nortel1 to a SIP device
(user B). User B pushes the transfer button (puts current call on hold and
makes a new call) and dials a Nortel / PSTN number to user C. This call goes
out through the nortel2 server. Users B and C talk a short while before user
B pushes the Transfer button again to connect users A and C. In this
scenario, the REFER is forwarded by kamailio to nortel1, which replies
"SIP/2.0 481 Call leg/transaction does not exist." The call to join is of
course on the other asterisk (nortel2).
The problem here is just in Nortel 1. It receives an in-dialog REFER
through the dialog between user A and B, and such dialog contains a
"replaces" parameter so user B can generate an INVITE with "Replaces"
header to user C and the attended transfer completes.
But for this to work you should use a single Nortel instance rather
than two or more (I assume that the Nortel behaves as a PBX). The
REFER Nortel (User 1) receives indicates it to call to another PSTN
number, so it would generate a new call to the PSTN (rather than
routing such an INVITE to the other Nortel box).
It's not possible your scenario. It's certainly hard to balance
traffic when you need a PBX role.
A similar scenario is where user B transfers to
another SIP user. This call
will only exist in one of the kamailio servers, and Asterisk will give the
same response to the REFER.
A third scenario is where both calls are handled by the same Asterisk
server. This scenario works.
I'm assuming I'll have to build REFER-handling logic into kamailio, but am
unsure of how to proceed. Any suggestions?
No, Kamailio can do nothing here. REFER is just an in-dialog request
Kamailio correctly routes in the loose_route section. The problem is
not the proxy, the problem is the explained above.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
18 Apr
18 Apr
6:56 p.m.
From: Iñaki Baz Castillo
2011/4/13 Pan B. Christensen <pan(a)ibidium.no>no>:
Scenarios:
A call comes in from Nortel/PSTN (user A) through Nortel1 to a SIP device
(user B). User B pushes the transfer button (puts current call on hold and
makes a new call) and dials a Nortel / PSTN number to user C. This call
goes
out through the nortel2 server. Users B and C talk a short while before
user
B pushes the Transfer button again to connect users A and C. In this
scenario, the REFER is forwarded by kamailio to nortel1, which replies
"SIP/2.0 481 Call leg/transaction does not exist." The call to join is of
course on the other asterisk (nortel2).
The problem here is just in Nortel 1. It receives an in-dialog REFER
through the dialog between user A and B, and such dialog contains a
"replaces" parameter so user B can generate an INVITE with "Replaces"
header to user C and the attended transfer completes.
But for this to work you should use a single Nortel instance rather
than two or more (I assume that the Nortel behaves as a PBX). The
REFER Nortel (User 1) receives indicates it to call to another PSTN
number, so it would generate a new call to the PSTN (rather than
routing such an INVITE to the other Nortel box).
...
The Asterisk servers named nortel1 and nortel2 are not PBXes, they are
gateways to the old Nortel PBX system. Their main purpose is to bridge SIP
and ISDN PRI (qsig). PBX features reside on a different set of Asterisk
servers, which have already been changed to failover instead of
load-balanced because of issues with calling queues.
...
It's not possible your scenario. It's certainly hard to balance
traffic when you need a PBX role.
...
I was fearing that answer. The customer wants the whole system
load-balanced, but I've found this difficult in Asterisk on several
occations. Perhaps I'll have to convince them to change these servers also
to a failover design, but that'll require interface cards for an additional
8 PRI's in both ends.
...
A similar scenario is where user B transfers to
another SIP user. This
call
will only exist in one of the kamailio servers, and Asterisk will give the
same response to the REFER.
A third scenario is where both calls are handled by the same Asterisk
server. This scenario works.
I'm assuming I'll have to build REFER-handling logic into kamailio, but am
unsure of how to proceed. Any suggestions?
No, Kamailio can do nothing here. REFER is just an in-dialog request
Kamailio correctly routes in the loose_route section. The problem is
not the proxy, the problem is the explained above.
...
Thank you very much for your reply.
With kind regards,
Pan B. Christensen
4970
days inactive
4975
days old
2 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
Pan B. Christensen