Rogers Sip trunks work until 1 call fails (due to no response)

[d00ner62]

I have a situation where my sip trunks work fine for a week or so, then all of a sudden they stop. If i do a system monitor trace, i can see 3 invites from the provider and then it "fails over" to the cell phone that the sip provider was told to send calls to when the trunk is down.

I am still sending sip options to rogers every 1 minute and receive a 200 ok.

once the cell phone starts receiving calls the sip trunks still say "idle", we can still call out. but when a call come in, the ipo receives 3 "invitation" messages and then the calls go to the fail over cell phone.

If i reboot the ipo it fixes the problem until a later date when the ipo basically stops responding to the invite messages.

any ideas or similar experiences?

 

[janni78]

A monitor trace would be nice.

"Trying is the first step to failure..." - Homer

 

[pmcook]

I hate SIP. I mean I really hate it. So many bugaboos and its always something different with each provider. And when the day comes they finally work out all the bugs, something else will be taking its place.

 

[intrigrant]

It must be FUMP over wifi

 

[pmcook]

WiFi is just as bad especially if it rains. It is ironic, is it not, that we are embracing early 20th century call quality using 21st century technology.

 

[d00ner62]

Here is a monitor trace

I have changed the phone numbers and IPs

A proper call shows the exact same sip invite however it shows 1 invite and then goes through a regular sip call

when the problem is happening i see the following trace and then the failover cell gets the call

Please note it is just 3 SIP invites and then it ends

10:39:12 1022093719mS SIP Rx: UDP 173.46.30.254:5060 -> 10.0.0.1:5060
INVITE sip:5195550053@10.0.0.1SIP/2.0
Via: SIP/2.0/UDP 173.46.30.254:5060;branch=z9hG4bKuuovga204011kmgme4v0.1
Max-Forwards: 68
To: <sip: 5195550053@10.0.0.1:5060>
From: "9995551234"<sip: 9995551234@173.46.30.202:5060>;tag=as763ebecd
Call-ID: 0c6a5cd7087c1319709801d2701b4eba@173.46.30.13
Contact: <sip: 9995551234@173.46.30.202:5060;transport=udp>
CSeq: 102 INVITE
User-Agent: Rogers SIP Core
Remote-Party-ID: "9995551234" <sip: 9995551234@173.46.30.13>;privacy=off;screen=no
Date: Sat, 03 Oct 2015 14:39:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
X-user: 0745*100
P-Asserted-Identity: "9995551234" <sip: 9995551234@173.46.30.13>
Content-Type: application/sdp
Content-Length: 279

v=0
o=root 1072328538 1072328538 IN IP4 173.46.30.202
s=Rogers SIP
c=IN IP4 173.46.30.202
t=0 0
m=audio 43906 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv
10:39:13 1022094221mS SIP Rx: UDP 173.46.30.202:5060 -> 10.0.0.1:5060
INVITE sip: 5195550053@10.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bKuuovga204011kmgme4v0.1
Max-Forwards: 68
To: <sip: 5195550053@10.0.0.1:5060>
From: "9995551234"<sip: 9995551234@173.46.30.202:5060>;tag=as763ebecd
Call-ID: 0c6a5cd7087c1319709801d2701b4eba@173.46.30.13
Contact: <sip: 9995551234@173.46.30.202:5060;transport=udp>
CSeq: 102 INVITE
User-Agent: Rogers SIP Core
Remote-Party-ID: "9995551234" <sip: 9995551234@173.46.30.13>;privacy=off;screen=no
Date: Sat, 03 Oct 2015 14:39:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
X-user: 0745*100
P-Asserted-Identity: "9995551234" <sip: 9995551234@173.46.30.13>
Content-Type: application/sdp
Content-Length: 279

v=0
o=root 1072328538 1072328538 IN IP4 173.46.30.202
s=Rogers SIP
c=IN IP4 173.46.30.202
t=0 0
m=audio 43906 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv
10:39:13 1022095223mS SIP Rx: UDP 173.46.30.202:5060 -> 10.0.0.1:5060
INVITE sip: 5195550053@10.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bKuuovga204011kmgme4v0.1
Max-Forwards: 68
To: <sip: 5195550053@10.0.0.1:5060>
From: "9995551234"<sip: 9995551234@173.46.30.202:5060>;tag=as763ebecd
Call-ID: 0c6a5cd7087c1319709801d2701b4eba@173.46.30.13
Contact: <sip: 9995551234@173.46.30.202:5060;transport=udp>
CSeq: 102 INVITE
User-Agent: Rogers SIP Core
Remote-Party-ID: "9995551234" <sip: 9995551234@173.46.30.13>;privacy=off;screen=no
Date: Sat, 03 Oct 2015 14:39:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
X-user: 0745*100
P-Asserted-Identity: "9995551234" <sip: 9995551234@173.46.30.13>
Content-Type: application/sdp
Content-Length: 279

v=0
o=root 1072328538 1072328538 IN IP4 173.46.30.202
s=Rogers SIP
c=IN IP4 173.46.30.202
t=0 0
m=audio 43906 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv

 

[janni78]

Was this a default trace?
Usually if the IPO doesn't answer a SIP INVITE there's something wrong with the SIP Line setup.

"Trying is the first step to failure..." - Homer

 

[janni78]

Can you show a working call?

"Trying is the first step to failure..." - Homer

 

[d00ner62]

Here is a successful call

11:06:46 182751mS SIP Rx: UDP 173.46.30.202:5060 -> XX.XX.XX.XX:5060
INVITE sip: 5195550053@XX.XX.XX.XX SIP/2.0
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bK55jjfr207gu01mkne390.1
Max-Forwards: 68
To: <sip: 5195550053@ XX.XX.XX.XX:5060>
From: "9995551234"<sip: 9995551234@173.46.30.202:5060>;tag=as7cdb1aee
Call-ID: 57326afd540a63997304ef1322e881ae@173.46.30.13
Contact: <sip: 9995551234@173.46.30.202:5060;transport=udp>
CSeq: 102 INVITE
User-Agent: Rogers SIP Core
Remote-Party-ID: "9995551234" <sip: 9995551234@173.46.30.13>;privacy=off;screen=no
Date: Sat, 03 Oct 2015 15:07:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
X-user: 0745*100
P-Asserted-Identity: "9995551234" <sip: 9995551234@173.46.30.13>
Content-Type: application/sdp
Content-Length: 277

v=0
o=root 576102745 576102745 IN IP4 173.46.30.202
s=Rogers SIP
c=IN IP4 173.46.30.202
t=0 0
m=audio 28614 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv
11:06:46 182755mS CMCallEvt: 0000000000000000 0.1008.0 -1 BaseEP: NEW CMEndpoint f4bffa78 TOTAL NOW=1 CALL_LIST=0
11:06:46 182758mS SIP Tx: UDP XX.XX.XX.XX:5060 -> 173.46.30.202:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 173.46.30.202:5060;branch=z9hG4bK55jjfr207gu01mkne390.1
From: "9995551234" <sip: 9995551234@173.46.30.202:5060>;tag=as7cdb1aee
Call-ID: 57326afd540a63997304ef1322e881ae@173.46.30.13
CSeq: 102 INVITE
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,UPDATE
Supported: timer,100rel
Server: IP Office 9.1.1.0 build 10
To: <sip: 5195550053@ XX.XX.XX.XX:5060>;tag=cde16f23f2771c1b
Content-Length: 0

11:06:46 182760mS CMCallEvt: CREATE CALL:3 (f5340a58)
11:06:46 182761mS CMCallEvt: 0000000000000000 0.1009.0 -1 BaseEP: NEW CMEndpoint f533f164 TOTAL NOW=2 CALL_LIST=0
11:06:46 182763mS CMLineRx: v=0
CMSetup
Line: type=SIPLine 17 Call: lid=17 id=1008 in=1
Called[ 5195550053] Type=Default (100) Reason=CMDRdirect SndComp Calling[9995551234@173.46.30.202] Type=Unknown Plan=Default
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ULaw
IE CMIEFastStartInfoData (6) 4 item(s)
IE CMIECallingPartyName (110)(Type=CMNameDefault) name=9995551234
IE CMIERespondingPartyName (228)(Type=CMNameDefault) name=9995551234
IE CMIERespondingPartyNumber (230)(P:100 S:100 T:0 N:100 R:4) number=9995551234@173.46.30.202
IE CMIEDeviceDetail (231) c0a82a33000003f0 LOCALE=enu HW=15 VER=9 class=CMDeviceSIPTrunk type=0 number=17 channel=1 features=0x0 rx_gain=32 tx_gain=32 ep_callid=1008 ipaddr=192.168.42.51 apps=0 loc=999 em_loc=999 features2=0x0 is_spcall=1
11:06:46 182764mS CD: CALL: 17.1008.1 BState=Idle Cut=1 Music=0.0 Aend="Line 17" (0.0) Bend="" [] (0.0) CalledNum= 5195550053 () CallingNum=9995551234@173.46.30.202 (9995551234) Internal=0 Time=3 AState=Idle
11:06:46 182764mS CMCallEvt: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: StateChange: END=A CMCSIdle->CMCSDialInitiated
11:06:46 182764mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: LOOKUP CALL ROUTE: GID=17 type=100 called_party= 5195550053 sub= calling=9995551234@173.46.30.202 dir=in complete=1 ses=0
11:06:46 182764mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: SET BESTMATCH: length 0 vs -1 match= dest=Incoming
11:06:46 182764mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: SET BESTMATCH: length 10 vs 0 match= 5195550053 dest=204
11:06:46 182764mS CMCallEvt: Priority hike: call 3 priority 0->1
11:06:46 182764mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: LOOKUP ICR: DDI= 5195550053 CGPN=9995551234@173.46.30.202 (Destination 204 ) => CDPN=204
11:06:46 182765mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: ADD TARGET (N): number=204 type=100 depth=1 nobar=1 setorig=1 ses=0
11:06:46 182765mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: SET USER: James Nowell orig=1
11:06:46 182765mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: ADD USER: James Nowell depth=1 disallow_cw=0 dnd=0 real_call=1 group_call=0 type(CMNTypeDefault) incl(0x0) excpt(0x0), allow_redir(1) remote=00000000 simult 0 (0)
11:06:46 182765mS CMCallEvt: 0000000000000000 0.1010.0 -1 BaseEP: NEW CMEndpoint f5340fe4 TOTAL NOW=3 CALL_LIST=1
11:06:46 182765mS CMCallEvt: 0000000000000000 0.1010.0 -1 James Nowell.-1: NEW CMExtnEndpoint f5340fe4, Name=James Nowell, Extn=204, Phys Extn=204
11:06:46 182767mS CMTARGET: c0a82a33000003f2 254.1010.0 3 James Nowell.0: ADD PRIMARY
11:06:46 182768mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: INITIAL TARGETING SUCCEEDED
11:06:46 182768mS CMTARGET: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: GetNoAnswerTimer:15
11:06:46 182768mS CMCallEvt: c0a82a33000003f0 17.1008.1 3 SIPTrunk Endpoint: StateChange: END=A CMCSDialInitiated->CMCSDialled
11:06:46 182769mS CMLineTx: v=0
CMProceeding
Line: type=SIPLine 17 Call: lid=17 id=1008 in=1
11:06:46 182770mS CMCallEvt: 0000000000000000 0.1009.0 3 TargetingEP: StateChange: END=B CMCSIdle->CMCSOffering
11:06:46 182771mS CMCallEvt: c0a82a33000003f2 254.1010.0 3 James Nowell.0: StateChange: END=T CMCSIdle->CMCSOffering
11:06:46 182772mS CMExtnEvt: James Nowell: CMExtnHandler::SetCurrent( id: 0->1010 )
11:06:46 182772mS CMExtnTx: v=204, p1=0
CMSetup
Line: type=IPLine 250 Call: lid=254 id=1010 in=0

 

[janni78]

What does your SIP URI tab look like?

"Trying is the first step to failure..." - Homer

 

[d00ner62]

Via= Public IP
Local URI *
COntact= Use Internal Data
Display Name= Use Internal Data
PAI= none
Registration= None
Incoming group= 17
Outgoing group= 17
Max Calls per channel= 10

 

[AvantiWade]

What do you have set for the SIP line under the SIP Advanced Tab - Association Method?

This is a security feature that is built into the office, here's the manual exerp:

Default = By Source IP Address.
This setting sets the method by which a SIP line is associated with an incoming SIP request.

The match criteria used for each line can be varied. The search for a line match for an incoming request is done against each line in turn using each lines Association Method. The order of line matching uses the configured Line Number settings until a match occurs. If no match occurs the request is ignored. This method allows multiple SIP lines with the same address settings. This may be necessary for scenarios where it may be required to support multiple SIP lines to the same ITSP. For example when the same ITSP supports different call plans on separate lines or where all outgoing SIP lines are routed from the system via an additional on-site system. The options are:

The key part is the bold section. If you have your providers DNS name setup in the ITSP section then it will do a DNS resolution to verify that the IP matches the incoming SIP request, if for some reason the IP's don't match it will reject the call. I am betting thats what's happening to you.

To verify do a NSLOOKUP of the name you have in the ITSP tab, then verify it matches the IP address the SIP invites were coming from. If they don't match thats the issue.

It happened to me where our local DNS server wasn't properly resolving DNS record changes or SRV Records so it was rejecting incoming calls.

 

[d00ner62]

Ill check that

But why would an IP Office reboot correct this?

 

[AvantiWade]

Reboot causes the IP Office to refresh its DNS Cache by re-looking up the address.

Try what I did. Ask your ITSP for the IP addresses for each call server that you will be receiving incoming sip traffic from. Take those IP's and put them in the Transport tab in the ITSP Proxy Address section. Separate each IP by a comma. I bet you won't have any issues after you do that. It's not ideal because if they for some reason roll out a new call server with a different IP you won't be able to resolve calls from it. But it will prove out DNS as your issue.

As a follow up, is the IP Office using your internal DNS or your ISP's DNS?