I just heard from Callcentric. They are strongly saying it’s not a bug on their side. I certainly don’t know. I do know that the rpid_update appears not to work.
The problem here encompasses two points:
1 - The way asterisk attempts to bridge the forwarded call
2 - The fact that our servers does not support this method
What your asterisk should be doing, and in fact should normally do, is to:
1 - Send an incoming call to your PBX
2 - Your asterisk should answer the call and then create a new individual channels/INVITES, independent of the incoming call, for the ring group
3 - Bridge the calls, with asterisk acting as the mediator/proxy for the calls
Your current configuration is performing the first and second step. However in the second step it is attempting to reINVITE the original call directly, and not bridge it:
INVITE sip:email@example.com:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 220.127.116.11:5060;branch=z9hG4bK04a0550e;rport
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Remote-Party-ID: “6784583747@from-internal/n” sip:6784583747@firstname.lastname@example.org;party=called;privacy=off;screen=no
o=root 810806119 810806120 IN IP4 18.104.22.168
s=Asterisk PBX 22.214.171.124
c=IN IP4 126.96.36.199
m=audio 10592 RTP/AVP 0 101
We do not support this method of re-INVITE. The outgoing call should not reference the original incoming call back to our servers, as it is attempting to have our servers perform the reINVITE. In other words this method will not work. The UPDATE method is also contributing to this by attempting to update the original INVITE directly on our servers.
The result of this attempt is repeated UPDATE requests which eventually time out:
[2011-10-10 16:57:03] VERBOSE chan_sip.c:
<— SIP read from UDP:188.8.131.52:5060 —>
SIP/2.0 408 Request Timeout
v: SIP/2.0/UDP 184.108.40.206:5060;branch=z9hG4bK369fb212;rport=5060
CSeq: 103 UPDATE
In short your asterisk server is attempting to perform a reINVITE with a method that is not supported by our severs. We know that this is possible as we ourselves use call hunting and call forwarding on Asterisk in our personal and test environments.
To summarize: Your Asterisk server should handle the incoming and outgoing leg of your ring group call independently. It should then bridge the two calls locally in asterisk itself. Our servers should only be a part of the inbound and outbound calls and not the bridging step. Any attempt to modify the original call in session on our end will fail as we will not process this request properly.