Issue with incoming number for Jive.net gateway

[Robert Birch]

I am having an issue with a gateway with Jive.net (GotoConnect is the new name)

An inbound call is passing the FROM information as the username of the gateway, then +phone number.
Ex. 0zQFTo7cYVdESeD1fio3EK9TpYUP19+xxx5551212

I can't do alpha numberic in the destination number, so is there a way to reformat it to remove the unneeded parts at the beginning or is there something in the gateway configuration I should be changing?

Here is the invite I am being sent:

2021/10/29 17:03:35.850503 162.250.61.8:5061 -> 172.31.43.62:5080
INVITE sip:gw+37c420ed-feed-43e7-a820-156fae733e6c+5875551212@xxx.xxx.xxx.xxx5080;transport=udp;gw=37c420ed-feed-43e7-a820-156fa
33e6c;x-ebcid=Ag_fGnMT2AA SIP/2.0
Record-Route: <sip:MS0xMC4xMjAuMjQ5LjI0OC01MDYw@162.250.61.8:5061;lr>
Via: SIP/2.0/UDP 162.250.61.8:5061;branch=z9hG4bK0746be84125cbdab64NJ2C1E64P30BHI6GSISCHK70NJAC1M60;rport;x-sc
Via: SIP/2.0/UDP 10.120.249.248:5060;rport;branch=z9hG4bK2wRKXR.f
Via: SIP/2.0/UDP 10.120.242.181:5060;branch=z9hG4bK0cedda91
Max-Forwards: 67
f: "ROBERT BIRCH" <sip:4035551212@reg.jiveip.net>;tag=as33db7613
t: <sip:0zQFTo7cYVdESeD1fio3EK9TpYUP19+5875551212@v1.rejis.jumpy>
m: <sip:4035551212@10.120.242.181:5060>
i: 1b8f991b321edd310e70d2330cf0d2a8@reg.jiveip.net
CSeq: 102 INVITE
User-Agent: Jive AS
Date: Fri, 29 Oct 2021 23:03:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, MESSAGE
k: replaces
X-ref: 289956251_116777615@67.231.3.21
Privacy: none
P-Asserted-Identity: "ROBERT BIRCH" <sip:4035551212@reg.jiveip.net>
c: application/sdp
l: 240
Session-ID: e376906a4438de475052176a303a528d

v=0
o=root 412976405 412976405 IN IP4 10.120.242.181
s=Jive
c=IN IP4 162.250.61.239
t=0 0
m=audio 34658 RTP/AVP 0 18 101
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150

I found I can modify the inbound route and change the condition to ${sip_to_user), then I can put in the whole string 0zQFTo7cYVdESeD1fio3EK9TpYUP19+xxx5551212 and it will match, but this defeats the purpose of the GUI and I can't forward the call as it wants to send that info as the outbound Caller ID.

Any help would be greatly appreciated.

Thanks,
Robert Birch

 

[Adrian Fretwell]

It is an interesting one...
You can match on destination with something like ^.*\+(4035551212)$ and then use the captured group (after the +) to set the caller ID.

Changing the To header can lead to unexpected results because the providers SIP proxy will want to see it in responses to the INVITE.

Probably overkill but you could put a proxy between your gateway and the provider, OpenSIPS or Kamailio, to modify the To header, the proxy will ensure that the header gets restored for any reply packets.
https://opensips.org/docs/modules/3.2.x/uac.html#func_uac_replace_from

 

[Robert Birch]

Yes, that might be a better way to do it, my issue is I really don't want to do something "special" with the inbound route, as if I do someting else, I need to remember to fix it again.

Is there something I can get the trunk provider to change, or something I can do with the gateway definition to fix it?

Thanks

 

[Adrian Fretwell]

I don't think there is anything in the gateway definition that could fix it. Talking to the trunk provider is a good idea.

 

[Robert Birch]

So I spent some time with the trunk provider going over this. They tell me that the invite being sent is gw+<uuid of fusion gateway>+<phonenumber>

From doing some googling, i saw a post about putting auto_to_user in the extension field in the advanced settings for the gateway. This does not seem to make any difference. I am assuming that something in Fusion is causing the issue whether it be the way the trunk is defined or something else.

Is there a way to do an XML dump of the gateway definition from fs_cli or something like that so I can confirm the settings?

Thanks

 

[Robert Birch]

I managed to figure this out with some trial and error. I think the real issue was setting Extension to "auth_to_user" with the quotes. If I did it without the quotes, it wouldn't work.

Odd, but at least it is working.

Thanks for all the help.