SIP TRUNKS (203) UPDATES

[VISA MC]

This appears to be working correctly now. Any idea why it would have been using the wrong protocol all day Friday for multiple accounts? It seems it is still in our best interest to set this to UDP to avoid whatever happened on Friday.


Today’s test call

10/07/2019 7:58:59 AM - L:10.2[Line:10000>>13143212522] got Terminated Send Req BYE from 204.11.192.39:5080 tid=5c23b40c08e47310 Call-ID=aduFkmJuMwcIqPLBac6kXQ..: BYE sip:[email protected]:5080;transport=udp SIP/2.0 Via: SIP/2.0/ ;branch=z9hG4bK-524287-1---5c23b40c08e47310;rport Max-Forwards: 70 Contact: <sip:[email protected]:5060> To: <sip:[email protected]>;tag=8UyUg1tUrZB4j From: "" <sip:[email protected]>;tag=79a42557 Call-ID: aduFkmJuMwcIqPLBac6kXQ.. CSeq: 3 BYE User-Agent: 3CXPhoneSystem 16.0.3.676 (676) Content-Length: 0

Friday’s test calls

10/04/2019 9:53:41 AM - ~Target=Unknown:1231881xxxx@(Ln.10000@12314920255)
10/04/2019 9:53:22 AM - [CM503025]: Call(C:194): Calling T:Line:10000>>1231881xxxx@[Dev:sip:[email protected]:5060;transport=TCP] for L:194.1[Extn:100]
10/04/2019 9:53:22 AM - Route to L:194.2[Line:10000>>1231881xxxx] sends Invite-OUT Send Req INVITE from 204.11.192.36:5060 tid=e19aea0f6311660b Call-ID=98VaTUd8GDC8lvsTHTrtxQ..:
INVITE sip:[email protected]:5060;transport=TCP SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-524287-1---e19aea0f6311660b;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060;transport=TCP>
To: <sip:[email protected]:5060;transport=TCP>
From: ""<sip:[email protected]:5060;transport=TCP>;tag=4b819236
Call-ID: 98VaTUd8GDC8lvsTHTrtxQ..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer
User-Agent: 3CXPhoneSystem 16.0.3.525 (525)
Remote-Party-ID: <sip:[email protected]:5060>;party=calling
Content-Length: 284

 

[JohnS_3CX]

Friday attempt: User-Agent: 3CXPhoneSystem 16.0.3.525 (525)
Today's attempt: User-Agent: 3CXPhoneSystem 16.0.3.676 (676)

It seems you were running the alpha still at the time, not update 3 yet.
Regardless though, since Callcentric does not advertise TCP in their records, we cannot know what happened unless there was a capture (to show the DNS requests before the call takes place).