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
2011/4/13 Pan B. Christensen pan@ibidium.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.
From: Iñaki Baz Castillo
2011/4/13 Pan B. Christensen pan@ibidium.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
-
Iñaki Baz Castillo -
Pan B. Christensen