ThePhoneMn
Vendor
IP Office SE with SIP connected to Edgemarc 4700. Just upgraded the solution to 10.1.2 over the weekend. I got an alarm the SIP trunk went down, after researching SysMon, which was capturing and logging, I found where the trunk went down.
Calls were working fine until someone tried dialing 1781, which is someone waiting to long to dial the entire number so the call went out after the delay timer expired. The SIP trunk came back up after about 60 seconds.
Is this normal? Would IPO put the SIP trunk OOS if a 400 BAD REQUEST is received? See Sysmon log below (I replaced some data with x)
15:22:28 368070057mS SIP Rx: UDP 192.168.43.2:5060 -> 192.168.43.1:5060
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 192.168.43.1:5060;rport=5060;branch=z9hG4bK19642b623e536fdd5fea05bff167b79e;received=192.168.43.1
From: "413592xxxx" <sip:413592xxxx@192.168.43.2>;tag=d82df98236f4baab
To: <sip:1781@192.168.43.2>
Call-ID: 25bea66e82ecdd181c427698dc1a192f
CSeq: 486447822 INVITE
Content-Length: 0
15:22:28 368070057mS SIP Tx: UDP 192.168.43.1:5060 -> 192.168.43.2:5060
ACK sip:1781@192.168.43.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.43.1:5060;rport;branch=z9hG4bK19642b623e536fdd5fea05bff167b79e
From: "413592xxxx" <sip:413592xxxx@192.168.43.2>;tag=d82df98236f4baab
To: <sip:1781@192.168.43.2>
Call-ID: 25bea66e82ecdd181c427698dc1a192f
CSeq: 486447822 ACK
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,UPDATE
User-Agent: IP Office 10.1.0.2.0 build 2
Content-Length: 0
15:22:28 368070057mS CMLineRx: v=0
CMReleaseComp
Line: type=SIPLine 47 Call: lid=47 id=98467 in=0
Called[] Type=Default (100) Reason=CMDRdirect Calling[384] Type=Internal Plan=Default
IE CMIEFeedback (188) Ver=1 Size=5 Type=2 Reason=400
IE CMIERespondingPartyNumber (230)(P:100 S:100 T:0 N:100 R:4) number=91781
IE CMIEDeviceDetail (231) 0a960019000180a3 LOCALE=enu HW=11 VER=10 class=CMDeviceSIPTrunk type=0 number=47 channel=10 features=0x1 rx_gain=32 tx_gain=32
ep_callid=98467 ipaddr=10.150.0.25 apps=0 loc=999 em_a_loc=999 em_d_loc=0 features2=0x0 is_spcall=1 ignores_dtmf=0 avgsid=
Cause=41, Temporary failure
15:22:28 368070057mS CMARS: LINE ep Received: CMReleaseComp - child->state = CMCSOffering - ARS Call State = CMCSOverlapRecv
15:22:28 368070057mS CMLineTx: v=0
CMReleaseComp
Line: type=SIPLine 47 Call: lid=47 id=98467 in=0
Cause=16, Normal call clearing
15:22:28 368070057mS CMCallEvt: 0a960019000180a3 47.98467.0 -1 SIPTrunk Endpoint: StateChange: END=X CMCSOffering->CMCSDelete
15:22:28 368070057mS CMARS: ModifyCMARSTarget: Short_Code: 1N; - Line_Group_ID: 98 set line status to CMARS_OUTOFSERVICE
15:22:28 368070057mS CMARS: Target: Short_Code: 1N; - Line_Group_ID: 98 has been set to: CMARS_OUTOFSERVICE
Been there, done that
Calls were working fine until someone tried dialing 1781, which is someone waiting to long to dial the entire number so the call went out after the delay timer expired. The SIP trunk came back up after about 60 seconds.
Is this normal? Would IPO put the SIP trunk OOS if a 400 BAD REQUEST is received? See Sysmon log below (I replaced some data with x)
15:22:28 368070057mS SIP Rx: UDP 192.168.43.2:5060 -> 192.168.43.1:5060
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 192.168.43.1:5060;rport=5060;branch=z9hG4bK19642b623e536fdd5fea05bff167b79e;received=192.168.43.1
From: "413592xxxx" <sip:413592xxxx@192.168.43.2>;tag=d82df98236f4baab
To: <sip:1781@192.168.43.2>
Call-ID: 25bea66e82ecdd181c427698dc1a192f
CSeq: 486447822 INVITE
Content-Length: 0
15:22:28 368070057mS SIP Tx: UDP 192.168.43.1:5060 -> 192.168.43.2:5060
ACK sip:1781@192.168.43.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.43.1:5060;rport;branch=z9hG4bK19642b623e536fdd5fea05bff167b79e
From: "413592xxxx" <sip:413592xxxx@192.168.43.2>;tag=d82df98236f4baab
To: <sip:1781@192.168.43.2>
Call-ID: 25bea66e82ecdd181c427698dc1a192f
CSeq: 486447822 ACK
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,UPDATE
User-Agent: IP Office 10.1.0.2.0 build 2
Content-Length: 0
15:22:28 368070057mS CMLineRx: v=0
CMReleaseComp
Line: type=SIPLine 47 Call: lid=47 id=98467 in=0
Called[] Type=Default (100) Reason=CMDRdirect Calling[384] Type=Internal Plan=Default
IE CMIEFeedback (188) Ver=1 Size=5 Type=2 Reason=400
IE CMIERespondingPartyNumber (230)(P:100 S:100 T:0 N:100 R:4) number=91781
IE CMIEDeviceDetail (231) 0a960019000180a3 LOCALE=enu HW=11 VER=10 class=CMDeviceSIPTrunk type=0 number=47 channel=10 features=0x1 rx_gain=32 tx_gain=32
ep_callid=98467 ipaddr=10.150.0.25 apps=0 loc=999 em_a_loc=999 em_d_loc=0 features2=0x0 is_spcall=1 ignores_dtmf=0 avgsid=
Cause=41, Temporary failure
15:22:28 368070057mS CMARS: LINE ep Received: CMReleaseComp - child->state = CMCSOffering - ARS Call State = CMCSOverlapRecv
15:22:28 368070057mS CMLineTx: v=0
CMReleaseComp
Line: type=SIPLine 47 Call: lid=47 id=98467 in=0
Cause=16, Normal call clearing
15:22:28 368070057mS CMCallEvt: 0a960019000180a3 47.98467.0 -1 SIPTrunk Endpoint: StateChange: END=X CMCSOffering->CMCSDelete
15:22:28 368070057mS CMARS: ModifyCMARSTarget: Short_Code: 1N; - Line_Group_ID: 98 set line status to CMARS_OUTOFSERVICE
15:22:28 368070057mS CMARS: Target: Short_Code: 1N; - Line_Group_ID: 98 has been set to: CMARS_OUTOFSERVICE
Been there, done that