Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: Wendelspanswick on August 23, 2018, 11:07:18 AM
-
We have added some SIP trunks to a 3300 V8, inbound calls are coming in fine but outbound calls drop after about 150 seconds.
The 3300 sits on the local network behind a firewall, we have a dedicated SIP trunk gateway with a static IP of 84.252.199.200 (changed for security) on the public side of the firewall which is tunneled though to the local IP of the 3300 (192.168.1.11).
The TalkTalk SIP circuit is pointed at the endpoint which is the gateway public IP.
I'm guessing that TalkTalk are rejecting the calls as they are tagged with the local IP of the 3300 rather than the gateway IP but I can't see how to resolve this?
Or am I barking up the wrong tree.
No. Time Source Destination Protocol Length Info
1 0.000000 84.252.199.200 91.255.255.255 SIP/SDP 888 Request: INVITE sip:07700123456@91.255.255.255 |
2 0.001658 91.255.255.255 84.252.199.200 SIP 412 Status: 100 trying -- your call is important to us |
3 0.838899 91.255.255.255 84.252.199.200 SIP/SDP 1013 Status: 183 Session Progress |
4 3.468886 91.255.255.255 84.252.199.200 SIP 690 Status: 180 Ringing |
5 6.132382 91.255.255.255 84.252.199.200 SIP/SDP 999 Status: 200 OK |
6 6.162939 84.252.199.200 91.255.255.255 SIP 541 Request: ACK sip:07700123456@91.255.255.255:5060;alias=10.44.56.154~5060~1 |
7 90.003357 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
8 90.491062 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
9 91.491566 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
10 93.491550 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
11 97.491500 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
12 101.491455 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
13 105.492445 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
14 109.492394 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
15 113.492372 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
16 117.492313 91.255.255.255 192.168.1.11 SIP/SDP 1057 Request: INVITE sip:anonymous@192.168.1.11:5060;transport=udp, in-dialog |
17 120.051172 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
18 120.492785 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
19 121.492257 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
20 123.493267 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
21 127.493221 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
22 131.493185 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
23 134.726536 84.252.199.200 91.255.255.255 SIP 474 Request: BYE sip:07700123456@91.255.255.255:5060;alias=10.44.56.154~5060~1 |
24 134.728471 91.255.255.255 84.252.199.200 SIP 476 Status: 200 OK |
25 135.493141 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
26 139.493090 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
27 143.493054 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
28 147.494022 91.255.255.255 192.168.1.11 SIP 581 Request: BYE sip:anonymous@192.168.1.11:5060;transport=udp |
-
Always dropped after 150s exactly?
-
I've spoken to TalkTalk and it seems its the combination of the Session Timer and the local IP in the Contact Header...
The 3300 sends out a Session Refresh request for 180 seconds, TalkTalk respond after half this time (90 seconds) but its being sent to the local IP address in the Contact Header and not the public IP, the 3300 doesn't get the Refresh Confirmation so drops the call.
I can resolve this temporarily by upping the Refresh Timer or setting it to 0 (no Session Refresh request sent) but ideally I want the 3300 to send out the public IP in the Contact Header.
-
Change the sip device capability of you sip trunk ( set to 71 )
-
Hi
I work with "Wendelspanswick"
Can you explain in more detail please
"Change the sip device capability of you sip trunk ( set to 71 )"
There seems to be quite a few settings and none seem to fit with "71"
Thanks
-
What do you mean by "SIP trunk gateway"?
- Like using an MBG to proxy it [that's the only supported way with TTB's Tipicall SIP trunks, which I assume you're using if you're connecting to 91.146.112.10]?
- Or some other model of SIP gateway [just because TTB only tested with MBG doesn't mean that others won't work]?
- Or gateway in the more general networking sense, ie a new router just for this SIP trunk?
I would leave session timer at 0 - IME, the media is renegotiated every time the session expires which doesn't help anything.
SIP peer profiles don't have SIP device capability entries so I don't know where Sunspark is referring to, maybe it's an MBG thing.
The 3300 will only ever send it's own IP in a SIP header, so if it doesn't have a public, it won't send it. If the provider expects a public IP then you need the ALG on your edge device to rewrite it or use a SIP gateway.
-
Sorry guys. You should keep 90s for session timer and change the sip device capability for softphone users.
-
Go to your time out settings for INTERNAL call timer for outgoing call time allowed. If you see 150 secs there change that to no timer/off and your problem will go. For some strange reason sip trunks are set as internal calls on the 3300.
-
What do you mean by "SIP trunk gateway"?
- Like using an MBG to proxy it [that's the only supported way with TTB's Tipicall SIP trunks, which I assume you're using if you're connecting to 91.146.112.10]?
- Or some other model of SIP gateway [just because TTB only tested with MBG doesn't mean that others won't work]?
- Or gateway in the more general networking sense, ie a new router just for this SIP trunk?
I would leave session timer at 0 - IME, the media is renegotiated every time the session expires which doesn't help anything.
SIP peer profiles don't have SIP device capability entries so I don't know where Sunspark is referring to, maybe it's an MBG thing.
The 3300 will only ever send it's own IP in a SIP header, so if it doesn't have a public, it won't send it. If the provider expects a public IP then you need the ALG on your edge device to rewrite it or use a SIP gateway.
The gateway is one provided by TalkTalk, its a Cisco Router managed by them and its just a data link, this connects to the customers network via the customers firewall and IT have tunneled it through their network to the IP of the 3300.
We have set the refresh timer to 9999 for now which gives us a maximum call time of 2 hrs 40 mins which is OK but not perfect.
I will have a word with IT to see if they can modify the outgoing SIP header as it passes through their firewall so that it substitutes the public IP for the internal IP.
Thank you for your help.