rpid_update=no not working

Asterisk Asterisk Support
1

I have rpid_update=no in my sip.conf (also rpid-update=no in case it’s spelled wrong in some doc) yet asterisk sends UPDATEs to Callcentric. Callcentric has a bug that terminates my call if I send the UPDATEs.

My guess is that sendrpid=yes is overriding rpid_update=no or that rpid_update is not implemented correctly. The UPDATEs continue to flow with the header “X-Asterisk-rpid-update: Yes”. I do need sendrpid=yes, although removing it stops the updates.

Environment: FreePBX 2.9.0.7, Asterisk 1.8.6.0, Trunk provider CallCentric, Hardware ESXi 4.1 VM with 1 vCPU, 384 MB ram.

2

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.

Callcentric said:
Hello,

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:185d10bf5c4efd04adb3795048e83645@204.11.192.35:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 76.97.152.43:5060;branch=z9hG4bK04a0550e;rport
Max-Forwards: 70
From: sip:14044786561@ss.callcentric.com;tag=as57b5a533
To: sip:16785134505@66.193.176.35;tag=3527268988-36163
Contact: sip:17772633077@76.97.152.43:5060
Call-ID: 13202124-3527268988-36129@msw1.telengy.net
CSeq: 102 INVITE
User-Agent: FPBX-2.9.0(1.8.6.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
Remote-Party-ID: “6784583747@from-internal/n” sip:6784583747@from-internal/n@66.193.176.35;party=called;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 234

v=0
o=root 810806119 810806120 IN IP4 76.97.152.43
s=Asterisk PBX 1.8.6.0
c=IN IP4 76.97.152.43
t=0 0
m=audio 10592 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

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[29834] chan_sip.c:
<— SIP read from UDP:204.11.192.35:5060 —>
SIP/2.0 408 Request Timeout
v: SIP/2.0/UDP 76.97.152.43:5060;branch=z9hG4bK369fb212;rport=5060
f: sip:14044786561@ss.callcentric.com;tag=as57b5a533
t: sip:16785134505@66.193.176.35;tag=3527268988-36163
i: 13202124-3527268988-36129@msw1.telengy.net
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.

3

They are definitely wrong when they talk about bridging; this is not a bridging issue They are also wrong in saying their server doesn’t support the method. If it didn’t support the method, it should respond with an Unsupported response, not a timed out one. Unfortunately, they don’t send an Allow headers, so one doesn’t know exactly what they do support.

If it is re-inviting, it is re-inviting in order to update the called number, not to do an external bridge. The fact that the address in the c= line matches the contact header address confirms that it is not trying do directmedia.

They are timing out the specific update request. It isn’t the local system that is timing out because of making too many. (It may be that they are trying to forward the UPDATE and timing out doing that, but that would mean they had significant support for the method.)

4

Hello,

To clarify the issue at hand:

When the user receives an incoming call on a Callcentric account and then forwards that call back out on the same Callcentric trunk Asterisk should bridge the two legs of the call and act as a b2bua in this case. In other words we should not be involved in connection process behind the asterisk server. We should only be responsible for the incoming and outgoing leg of the call. This is the behaviour we see in our test environments and personal environments.

We are aware of the in fact that our servers do not respond with an unsupported method response to the UPDATE method. Asterisk should be able to allow the user to choose the reINVITE method used, as we have seen in the past. It is only in this user’s case we are seeing this particular behaviour.

What we need here is the proper settings to prevent asterisk from using the current reINVITE and UPDATE method in order to attempt to reINVITe the call. We can upload the SIP trace of an example call so that this can be better investigated. Please provide the proper instructions to do this.

5

I’m glad to have Callcentric in this thread too. Please remember, this “problem” with the UPDATEs and TIMEOUT only occurs with sendrpid=yes. If I remove that, all is well except I can’t control which DID number appears in outbound caller ID.

HEY: The Callcentric folks reminded me that the function I need can be solved by P-ASSERTED-IDENTITY or REMOTE-PARTY-ID. If an asterisker tells me it’s worth testing, then I’ll do the hack. It involves inserting a custom header and will be new territory for this noob. Details at: callcentric.com/faq/31/219

6

ReINVITE is used for more than just direct media. For a long time it has been used for holds. This is another use.

As far as I can see here, Asterisk is a pure B2BUA throughout the call, with no attempt to optimise the RTP path. It is not using reINVITEs in the sense that led to the misnaming of the canreinvite option in earlier Asterisk versions.

In this case it is re-INVITE-ing to try to change the number displayed on what it is treating as a phone (remember there is no clear distinction between end user terminals and trunks in SIP). Doing this has been something that people have been demanding for some time, especially if they have experience of Cisco phones in native mode, which definitely do this.

I haven’t fully analysed this, but I think it is using UPDATE because it hasn’t yet sent 200 OK, so is not yet able to do a re-INVITE.

I did skim the code, and it looks like the rpid_update option might only control what Asterisk offers in its Allow header, not what it is prepared to source, but I only looked very quickly and may have misunderstood what it was trying to do. If that is the case, that might justify a bug report, on issues. asterisk.org, although there is a risk that it will come back as a documentation error, rather than a code error.

7

I removed the sendrpid=yes that was causing the problem. I get the same functionality using the following in extensions_custom.conf

; Apply appropriate CID based on extension; 31x use the house line, others use the business line
[from-internal-custom]
exten => _1NXXNXXXXXX/_31X,1,SipAddHeader(P-ASSERTED-IDENTITY: "16789470887" <sip:16789470887@callcentric.com>)
exten => _1NXXNXXXXXX,1,SipAddHeader(P-ASSERTED-IDENTITY: "16785134504" <sip:16785134504@callcentric.com>)

; end of [from-internal-custom]

The FAQ at Callcentric mentioned 2 ways to accomplish setting the outbound CID, and I chose the easier (sendrpid). The slightly harder (not managed by FreePBX) PAI works, however, without the hang-up problem, so I now have FollowMe!