Call Forwarding-Sip Diversion Header

I have an issue with not getting any audio when trying to forward incoming calls to an external extension. in this case a cell phone. My ISP tells me i would need to be using a SIP diversion header to make it work. can anybody point me in the right direction?

Diversion headers should have no effect on audio. They are to inform users about the redirection.

hey David. Let me clarify. when i use the ‘default’ setting under ‘change external CID configuration’, i get “the number you have dialed is not in service.” when i try to use ‘use dialed number’ is when i get no audio; i don’t want to use the dialed number. i want to use the number of the incoming call

Thats for callerid, not anything for diversion. Default = original callerid. So if this was an external call, that is the callerid used. Does your carrier allow that?

There are basically two methods to forward a call, the diversion header instructs the carrier to ‘try another number’ you need to do that as per the providers instructions then the media is between the carrier and the ‘diverted’ destination.
On the other hand, you can ‘answer’ the call then send it to the final destination (find me follow me) in this case you are responsible for properly routing the media of both legs.

i assume this means the provider would have to do something each time i want to enable/disable/change the forwarding? then no, i want my local astrisk server to answer the call and forward it. that way i can change and toggle on the on/off

this is what i am working on. i have read in the past this is an issue because our local PBX will be trying to dial out using some random DID (the one that called in) that’s why i assume i am getting “the number you have dialed is not in service.” is my assumption correct?

then first step turn on rtp debugging, there will be two streams for the incoming call and two for the bridged outgoing call. all four need to be populated, mostly it will be your router not Asterisk bolloxing rtp. Incompleted calls always your conformant agreement with calls to your carrier

No. The Diversion header tells the recipient which number initiated the diversion. The new destination is carried in the Refer-To header, of the REFER mthod, post-answer, and in the Contact header of a 301 or, more normally, 302 response.

Moreover, many people say “forward” when they actually mean relay, in which case the destination is in the request URI of a more or less normal INVITE. It may have a Diversion number giving the virtual extension that sent it onwards to the miscellaneous destination, but I don’t think that FreePBX does that by default, and I think you have to set it explicitly in raw Asterisk.

Thanks for that, better that you tell the OP how to actually do that.

Direct In Dialling numbers are only meaningful for incoming calls. If you relay the call, the trunk is determined by the outgoing destination. If you truly forward it, the instruction to forward will be sent on the incoming channel, so go to the immediate upstream source.

I need to understand what they are actually, and what the provider wants to see, doing first. Also, as I said, Diversion headers don’t apply to media. If they really want a Diversion header, it is for some administrative or commercial reason.

Information on managing Diversion headers is provided at

https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information#ManipulatingPartyIDInformation-REDIRECTINGdialplanfunction

but that is in raw Asterisk terms.

This seems to have something about setting them in FreePBX, although it looks like it is setting the header directly, rather than through the Asterisk connected line update process:

Also looking at this, what the provider wants to know is the number on which they delivered the call that is being relayed, and without that they may refuse to forward the caller ID. Again this has nothing to do with media. If the call fails, ti will be the whole call that fails, not just the media.

I couldn’t find any FreePBX documentation on doing a true transfer, but there may well be a way, short of directly calling the Tranfer application in custom dial plan.

wow. thanks for taking the time to point things out to a noob like me. i’m sure it took a 2-digit year-number in experience to get there. one day…

firstly, i am trying not to involve the provider. i want to be able to make any and all forwarding changes locally on the pbx. I am not sure why they are asking me to make a diversion header; before today i had not idea what it was. i simply asked them “quick question. When I try to forward calls to a cell, will I have a problem due to you blocking random outgoing DID’s?” and they responded with “You would need to make sure you’re using a sip diversion header when the call is forwarded.” at this point i would say i am not getting to the media, because the phone i use to test this just says “the number you have dialed is not in service”.

here is what i want to achive when i’m done: when a number “A” dials our PBX, i want to be able to forward (relay, most likely) that call to a user’s cell phone, with number “A” as the CID. i guess at this point, at least tell me how to troubleshoot this. is there a telltale sign on the asterisk logs that’ll tell me what’s up? do you want to see them? or am i better off checking on the router?

Is the call arriving from the same provider? If not you are probably out of luck, as STIR/SHAKEN policies mean that there are only really two choices for dealing with random caller IDs: reject the call outright, which seems to be what is happening, or flag the caller ID as probable spam.

If it is the same provider, unless someone comes up with a better way, the forum posting I referenced is probably your best starting point. Whilst it would be better to use the Asterisk REDIRECTING features, without a worked example, you are going to need a lot of familiarity with writing custom dialplan for FreePBX, or you will need to find GUI options that do it for you.

As far as the Asterisk core is concerned, relaying to a miscellaneous destination is no different from connection to a local extension, and though it could do so, Asterisk won’t normally add a Diversion header when delivering to a local extension.

It is important to understand that you are dealing with local policy decisions by the provider, not general principles. It is also possible that their support tech doesn’t really understand, and there is no permitted way of setting a caller ID that you do not own (which I believe is the most common case).

not usually. random incoming number, FMFM to user’s cell phone when they’re not home.

this is what i need to know before pounding hours into this.

can you tell me for sure that this is the case, to your knowledge? if it is so, i guess i will humble myself back to "use dialed number’ and try to carry my cross that way. i’ve been working on getting this to work in my spare time for over a year now. i’m starting to feel like i want it to work :smiley:

It’s going to depend on the country, but because of caller ID spoofing as part of criminal frauds, I believe US service providers now indicate the trustworthiness of caller ID and will only give the highest level of trust if the caller ID is one associated with the account, or, possibly one that they have verified to be under your control, e.g. they have called that number and confirmed its owner’s permission to have it presented by your system.

What I think the diversion header thing is about is that if they can associate the outgoing call with one they are sending to you, they may be prepared to accept that the caller ID being presented with the one being presented to you, but I haven’t seen many people mentioning providers doing anything like this (although there seem to have been Diversion questions very recently). They can only do this if they handled the incoming leg of the call.

they are our provider, so any calls hitting this PBX here will be coming from them, so i assume that yes, they are handling the incoming leg of the call. but, if this is something even you are kind of unfamiliar with, i have no chance getting this to work with my current knowledge. are any of the forum posts you referenced something you believe would be helpful?

could you clarify that please david? “arriving from the same provider” is not the same as origninating from, correct? i mistook your statement till now. if a verizon caller calls me, and the call is coming in and being relayed out on the same trunk, that’s what you’re talking about, yes? because yes, that’s the case; we only have one trunk on our PBX.

Have you tried enabling call confirm and testing? I have run into this before and it was due to this being a Local channel and the destination side expecting media to be flowing when the call is answered. Call confirm makes the confirmation announcement play and thus sends media.

My bet is that this would work. I’ve seen enabling Fax Detection on the inbound route as a workaround too, or setting progressinband=yes in SIP settings.

Wow, 19 posts with no resolution, for what is apparently a very common problem with (usually) easy solutions.

IMO, this is very unlikely to be related to Diversion headers or other signaling issues. I am assuming that this is an on-site PBX behind a NAT (if not, please provide details). The recommended fix for this problem: In your router/firewall, ensure that the RTP port range (default is UDP ports 10000-20000) is forwarded (from any external IP) to the LAN address of the PBX.

If for some reason you can’t do this, e.g. you don’t have administrative control of the firewall, setting Inband Progess for the trunk to Yes (for a pjsip trunk) or progressinband=yes (for chan_sip) will usually work. As a last resort, try Fax Detection as suggested by @adell4444, but note that this answers the call immediately, which often has unwanted side effects.

If you still have trouble, please paste the Asterisk log for a failed call, including SIP trace, at pastebin.freepbx.org and post the link here. Also, post the make/model of your router/firewall, along with any VoIP-related settings.

I got a bit lost, but the OP seemed to be reporting both media problem and outright connection refusals, in a way that left me confused as to whether any of the media problems were not really connection refused ones.