Blind Transfer on outgoing calls

on a multi device ext will only work if the the second phone is registered if it is unplugged it also fail to transfer

I figured out the issue but no solution, any help is appriciated

this seems to be related to asterisk 1.8 where it is automatically updating, the RPID of the transferred extension, so a call is made from extension 200 (external caller ID: 7185551212) to 8005551212 than exten 200 transfers to 210 asterisk is sending a sip update with a NEW Remote-Party-ID using the 3 digit extension number as RPID which is causing a error and of course a hangup,

following is a trace of the update

UPDATE sip:+18005551212@64.152.60.78:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK576273e1
Max-Forwards: 70
From: "Caller ID Name" ;tag=as7bb989d5
To: ;tag=gK04926d30
Contact:
Call-ID: 28399c19139232af2b89b08d1087844c@192.168.1.1:5060
CSeq: 104 UPDATE
User-Agent: Asterisk PBX SVN-branch-1.8-r313142
Remote-Party-ID: "-> Ext 210 (via 200-mytenant@my.pbxdomain.com)" ;party=calling;privacy=off;screen=no
X-Asterisk-rpid-update: Yes
Content-Length: 0


Thanks

After reviewing the capture, i see in the capture that asterisk send the reinvite for the call to be transferred and before the carrier respond to the invite, asterisk send the UPDATE packet. the carrier send a 100 trying and 200 ok and the carrier get no response back from asterisk on the 200 ok which ultimately times out the call.

Can anyone please advise why asterisk is sending the UPDATE packet before the carrier can respond to the 200ok and also why there is no response back from the 200 ok the carrier send after the UPDATE?

any help

https://issues.asterisk.org/jira/browse/ASTERISK-18999 ?

I notice that we are only having this issue when the call is termanting via Broadvox all other carreirs will work with no problem, we opened a ticket with Broadvox but they dont see anything on their side cuasing it,

Is any one using Asterisk 1.8 With Broadvox and don't experiences this issue?

any help is appreciate

Another issue what i noticed on 1.8 with Broadvox which might be related, that when an ext is set to fmfm with Confirm call acceptance if i will select 1 or 2 everything will work fine but if i will just hang up the call the call will get lost, the way it should be and that's how it is working with all other Carriers that it will like i pressed 2 to decline the call and it will jump back the the ext VM

I use broadvox with 1.8 and do not seem to have these issues, but I peer with broadvox through a gateway asterisk box, not directly to MTE. have you tried rpid_update=no for the specific broadvox outgoing trunk?

No, i didn't try with rpid_update=no, will it not cause me any other CID issues?

We also peer with broadvox through a gateway asterisk box

I just tried with rpid_update=no but no look

here is a copy of the sip.conf

type=peer
host=bvox ip address
qualify=4000
canreinvite=no
dtmfmode=info
disallow=all
allow=ulaw
rpid_update=no

i found this on a forum

"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."

so try this.. instead of setting rpid_update on the outbound trunk to broadvox, try it on the inbound trunk from the MTE box. So if on your gateway you have a trunk that peers with your MTE box labeled GWMTE, then put this setting there and see if it tells the MTE that updates are not a supported feature.

Thanks eeman for your respond, but so far no look,

here is a copy:

[MTE1]
type=friend
nat=no
qualify=yes
username=MTE1
secret=*****
host=IP address
dtmfmode=rfc2833
context=mte_out
canreinvite=no
disallow=all
allow=ulaw
rpid_update=no

hmm can you do a packet capture and at least see if the rpid-update flag is now set to no?

X-Asterisk-rpid-update: Yes

I'm seeing X-Asterisk-rpid-update: Yes

I would suggest submitting a bug report to digium then, outlying the evidence that you are sending rpid updates to your carrier and that you do not wish to send update messages, only initial rpid. Obviously this flag should do something, and clearly isnt even changing the list of options.