Is the field "CallForwardOnNoAnswerNumber" an "Inbound Call Route"?

[dani]

In other words... can the field "CallForwardOnNoAnswerNumber" take all the complex syntax options described in page 121 of the Admin Guide?

I ask because I'm looking for the right way to include the internal variable $1 in the bridging instructions, but i can't make it work...

Thanks

[RonR]

No.  It can only be a telephone number in TK format : SP2(18005551212)

If you don't mind the PHONE Port continuing to ring until the call is answered by the forwarding number, you can do a simulated CallForwardOnNoAnswer:

InboundCallRoute : {ph,sp2(17771234567@in.callcentric.com;d=10)}

This will ring the PHONE Port for 10 seconds before a call is placed to 17771234567 at Callcentric.  The PHONE Port will continue to ring until Callcentric answers (or the caller gives up).

[RonR]

dani,

I just ran several tests with WireShark to satisfy my own curiosity.  The results are the same as I and others have found in the past:


- X_SpoofCallerID must be enabled for CallerID to be passed

- {sp2($1>17771234567@in.callcentric.com)}   CallerID of "$1" is passed

- {sp2($2>17771234567@in.callcentric.com)}   CallerID of "$2" is passed

- {sp2(18005551212>17771234567@in.callcentric.com)}   CallerID of 18005551212 is passed

- {sp2(17771234567@in.callcentric.com)}   CallerID of caller is passed

$1 and $2 are passed as literal strings and not replaced by internal values as described in the OBi Device Administration Guide.  I've found the same thing is true when trying to use the $2 variable in OutboundCallRoutes.  I've asked Obihai about this in the past, but my emails went unanswered.

[dani]

Hi RonR

This is very interesting and useful, because of the following:

A bit ago we were talking with infin8loop about this, and realized that voip.ms has a callerID setting for each subaccount/extension. If we leave this field BLANK, then caller number gets transmitted. If we put a value there, it overwrites the caller number. One would assume that this setting is for outgoing calls only, but its behavior became very clear in our experiments.

Now... leaving this field blank fixes the transfer of caller number when bridging a pstn call to a voicemail, BUT it wrecks outgoing calls, as they now have my voip acct# as caller number.

This is where your last message comes in: where exactly in my Obi settings should I put that string  ("mypstnnr > mysipnr@voip.ms"), so the Obi hardwires my callerid number when using SP2?

Thanks

Dani

[RonR]

This is where your last message comes in: where exactly in my Obi settings should I put that string  ("mypstnnr > mysipnr@voip.ms"), so the Obi hardwires my callerid number when using SP2?

I'm not sure what you're asking.

What I was testing was call forwarding via SIP URI from an InboundCallRoute rule : {sp2(cid>callee)}

If you're wanting to hardwire the CallerID to your PSTN number as you forward a call to your voip.ms number, you would use:

{sp2(pstn_nmbr>voip.ms_nmbr@voip.ms)}

[dani]

Yes, now I realize I was talking about something different:

On the current settings, my voip provider doesn't have my own nr as default outbound callerID number, and expects it to be provided on each call.

Can I have the Obi provide explicit callerID number on every voip outbound call?

It would be nice to do it both when the digitmap sends something to SP2, and when using **2.

Thanks, and sorry for the confusion.

[RonR]

On the current settings, my voip provider doesn't have my own nr as default outbound callerID number, and expects it to be provided on each call.

Can I have the Obi provide explicit callerID number on every voip outbound call?

It may be possible to use the Voice Services -> SPx Service -> URI parameter to accomplish what you want.  It's not clear to me how CallerID spoofing interacts with this, so more experimentation will be required tomorrow.

From the OBi Device Administration Guide:

This parameter affects the way the AOR is formed by the device in outbound SIP Requests. The AOR has the format: user@domain.

If the value of URI is empty, device gets the user portion of its AOR from the AuthUserName, and the domain portion the value of ITSP Profile's UserAgentDomain if it is not empty, or that of the ProxyServer otherwise.

If the value URI is not empty and does not contain "@", it is used as the user portion of the AOR while the domain portion is formed the usual way.

If the value of URI contains "@', it is interpreted as a full AOR and device takes it as the AOR as is.

Some Examples:

1) Let ProxyServer = sip.myitsp.com, AuthUserName = 4089991123, URI=[empty], UserAgentDomain=[empty], then
AOR = 4089991123@sip.myitsp.com

2) Change UserAgentDomain to users.myitsp.com, then
AOR = 4089991123@users.myitsp.com

3) Change URI to bobdylan, then
AOR = bobdylan@users.myitsp.com

4) Change URI to bobdylan@superusers.myitsp.com, then
AOR = bobdylan@superusers.myitsp.com

[dani]

Interesting.
My test before calling it a night:
I put my nr in the URI field, as 2223334444.
Called to GV, caller id shows as +12223334444.

Called my cellphone, and the call was REJECTED by the service provider.

Let's see tomorrow....

Thanks

[RonR]

I put my nr in the URI field, as 2223334444.
Called to GV, caller id shows as +12223334444.

Called my cellphone, and the call was REJECTED by the service provider.

After some additional testing, ...

Since your service provider expects you to provide your own CallerID, putting your PSTN number in the URI parameter appears to accomplish exactly what you want (I would use 12223334444).  When incoming calls are forwarded to another number with X_SpoofCallerID enabled, your CallerID (in the URI parameter) gets overridden by the caller's as one would hope.

I don't understand why you were able to successfully call one number (Google Voice) but have a call to another number (cell phone) rejected.  Is this reproducible, and if so, can you tell what's going on from looking at the two calls with WireShark?

[infin8loop]

I put my PSTN phone number in Voice Services -> SP2 Service -> URI as 11231231234
on the same Obi that has Line CallForwardOnNoAnswerNumber : sp2(10555)  to the voip.ms mailbox.

This fixed the callerid number for outbound calls on voip.ms. I didn't know there was an issue because I haven't made any outbound calls on voip.ms since getting rid of the DID I had for testing.  I had the DID in the callerid override in the voip.ms primary account and had no subaccounts at the time.  Now I use two subaccounts and leave the primary account unregistered.  I never populated the callerid number override in the voip.ms subaccounts configuration.

With the URI populated on the Obi I made test calls through the voip.ms subaccount_1 on sp2 to my cell, GV, and my other PSTN line.  All calls received showed the proper callerid number (the one in the URI) and the receiving PSTN line showed the correct callerid number and name (confirming AT&T looked it up correctly).

The Line CallForwardOnNoAnswerNumber : sp2(10555) still works in that the callerid number of the inbound calls are kept when sending calls to voice mail.

Thanks RonR.  I would have never gleaned this information from manual.  I remember reading the description of the URI and going, "huh?".  LOL

"It's always something"  - Roseanne Roseannadanna didn't know she could have been talking about voip.

[dani]

Yes, it happens every time: if the URI field is empty calls to the Rogers and Bell cellphones I have available for testing go through, but provide strange callerID.

If the URI has my PSTN number, i get a recording "The number **22223334444 has been rejected by the service provider". It mentions the **2, so the message must come from the Obi.

If I clear the URI again, reboot and redial... the call goes through.

Calls to GV go through fine, in both cases, but shows a different callerID.

[infin8loop]

This is becoming comical.  A little while ago I tried to make an outbound call through voip.ms on sp2 - the one with the URI parameter coded and it failed. Turns out the subaccount_1 registration was suddenly failing with a 403 (bad auth).  I had not touched password (or any configuration for that matter) on either the Obi or at voip.ms for the subaccount since making the earlier test calls after populating the URI. I reset the password on the Obi and at voip.ms  - nope, it wasn't having it.  So I set the URI back to empty (default checked), rebooted and boom registration successful. The entire time the subaccount_2 on my other Obi remained registered to the same voip.ms server (the URI on that Obi was never set to anything).

I may try it all again but not right now.

[dani]

This is going nowhere.

That URI field is definitely messing up the voip.ms registration. May have to be kept empty for now.

RonR: can callerID be passed within the route/digitmap?

something like ... if calling 12223334444 dial 15556667777>**212223334444
(where 5556667777 is my own PSTN number and **2 is voip.ms)

Thanks

[RonR]

dani,

CallerID can be set on a call forwarded by an InboundCallRoute rule:

InboundCallRoute : {sp2(18005551212>12341234567@sip.voip.ms)}

CallerID of 18005551212 is sent on the call forwarded to 12341234567 at voip.ms.


You cannot use this syntax on a CallForwardOnNoAnswerNumber, however, as the OBi will send:

18005551212>12341234567

as the called number at voip.ms.


CallerID can be set in an OutboundCallRoute rule:

OutboundCallRoute : ...,{(<**2:>(Msp2)):sp2(18005551212>$2)},...

CallerID of 18005551212 will be sent on all calls placed from the PHONE Port that are dialed as **2 + number.

[dani]

I think that was it!

OBI URI: empty
OBI X_SpoofCallerID: enabled
OBI PHONE > OutboundCallRoute: ..,{(<**2:>(Msp2)):sp2(18005551212>$2)},...
OBI LINE Port > CallForwardOnNoAnswerEnable: enabled
OBI LINE Port > CallForwardOnNoAnswerNumber: sp2(109)
voip.ms callerID on main account: empty
voip.ms callerID on sub-account: empty
voip.ms sub-account with extension 109 connected to mailbox, minimum ring time, no device registered

Incoming CallerID is passed on bridged calls, and outbound calls on voip.ms go out with the proper callerID.

Chances are by fixing this we broke something else. Let's see if we find it

Thanks!