REST - Starting call with hasAudio false still uses sendrecv in SDP causing call to timeout

lamflam

New Member
Using Web Call Server Version 5.2.755

I'm passing the following to /rest-api/call/startup

JSON:
{
    "callId": "1234567",
    "callee": "1234567",
    "hasVideo": false,
    "hasAudio": false,
    "sipLogin": "[login]",
    "sipAuthenticationName": "[authName]",
    "sipPassword": "[password]",
    "sipDomain": "[sipDomain]",
    "appKey": "callApp",
    "sipRegisterRequired": false,
    "toStream": "1234567"
}
Once the call and stream are created, /rest-api/stream/find-all/ returns:
JSON:
{
    "sessionId": "127.0.0.1:6255815454129927085",
    "mediaSessionId": "1234567_127.0.0.1:6255815454129927085",
    "name": "1234567",
    "published": true,
    "hasVideo": false,
    "hasAudio": true,
    "status": "PUBLISHING",
    "sdp": "v=0\r\no=root 448804546 448804546 IN IP4 172.18.170.115\r\ns=Twilio Media Gateway\r\nc=IN IP4 34.203.251.173\r\nt=0 0\r\nm=audio 10350 RTP/AVP 0 8\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n",
    "audioCodec": "PCMU",
    "record": false,
    "width": 0,
    "height": 0,
    "bitrate": 0,
    "minBitrate": 0,
    "maxBitrate": 0,
    "quality": 0,
    "history": false,
    "gop": 0,
    "fps": 0,
    "audioBitrate": 0,
    "codecImpl": "",
    "transport": "UDP",
    "cvoExtension": false,
    "createDate": 1599089222305
  }
And according to the these docs this should pass an SDP with "a=recvonly" to the SIP endpoint, however it's still passing "a=sendrecv" which causes the SIP provider to prematurely end the call because it's expecting inbound audio but not getting anything. The stream object also somehow was "hasAudio" set to true even though I'm passing "hasAudio" as "false".

Is there something else I need to do in order to get this pass `a=recvonly` in the SDP?
 

Max

Administrator
Staff member
Hello!
We tested the SIP call using /rest-api/call/ startup with the parameters:
Code:
{
  "callId":"1234567",
  "callee":"10002",
  "hasVideo":"false",
  "hasAudio":"false",
  "sipLogin":"10001",
  "sipAuthenticationName":"10001",
  "sipPassword":"1111",
  "sipDomain":"192.168.0.0",
  "sipPort":"5060",
  "appKey":"defaultApp",
  "sipRegisterRequired":"true",
  "toStream":"1234567"
}
on our WCS version 5.2.755 the problem is not reproduced.
Please collect and send us a report as described here.
Form for sending reports and logs
Please, for further diagnostics, tell us which SIP PBX do you use?
Dump traffic with the command
Code:
tcpdump -i any -s 4096 -w log.pcap
and send it to us for analysis.
The dump should be started before the call starts and finished after the stop.

If possible, please provide SSH access to your WCS server and SIP accounts for calls
You can send using a private form
 
Last edited:

lamflam

New Member
Thank you for the response. We are hitting a Twilio SIP domain after following the instructions at https://flashphoner.com/docs/wcs5/184/html/en/wcs-user-guide/sip_as_rtmp_with_twilio.htm and I just noticed that this must have been an issue before since WCS has the setting to generate an inaudible RTP stream. I do have `generate_av_for_ua=Twilio Media Gateway` set in the properties file, but Twilio is still saying it is detecting silence from the WCS side of the call and times out after exactly 25 minutes.

I will gather the report and forward as well as set up credentials for you to be able to run a test against our Twilio SIP domain, I cannot give ssh access to the server however.
 

lamflam

New Member
Further debugging, found that WCS is sending a SIP update to Twilio at 25 minutes into the call and Twilio is responding with 405 - Method Not Allowed. Once Twilio returns this 405 the call is dropped.

Why is WCS consistently sending an UPDATE message at 25 minutes? If there a way around this or a way for WCS to continue the call even on a 405?


172.31.76.59 is the WCS IP
54.172.60.0 is the Twilio IP
Code:
--------------------> UPDATE sip:172.25.44.16:5060 SIP/2.0
from:   /172.31.76.59:30009
to:     /54.172.60.0:5060
time:   1599153880259
timeStamp:
isSender:       true
transactionId:  z9hg4bked6609608a8b71fc61b9e409b263b736
callId: event-1488675

UPDATE sip:172.25.44.16:5060 SIP/2.0
Via: SIP/2.0/UDP 172.31.76.59:30009;branch=z9hG4bKed6609608a8b71fc61b9e409b263b736
CSeq: 3 UPDATE
Call-ID: event-1488675
From: "aiera-wcs" <sip:aiera-wcs@aiera-wcs-test.sip.twilio.com>;tag=3b403227
To: <sip:event-1488675@aiera-wcs-test.sip.twilio.com>;tag=12357438_6772d868_d15660e5-0c95-4b64-9cb3-d2784ebab21e
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
X-Twilio-CallSid: CAce0a13c53ca1c16bad7f87484e27c9e6
Max-Forwards: 70
Route: <sip:54.172.60.0;lr>
Supported: timer
Min-SE: 90
Session-Expires: 1800;refresher=uac
Contact: <sip:aiera-wcs-951335054@54.167.187.20:30009>
Content-Length: 0


17:24:40,262 DEBUG          sipMessages - UDPMessageChannelThread-30009-273

<-------------------- SIP/2.0 405 Method not allowed
from:   /54.172.60.0:5060
to:     /172.31.76.59:30009
time:   1599153880261
timeStamp:
isSender:       false
transactionId:  z9hg4bked6609608a8b71fc61b9e409b263b736
callId: event-1488675

SIP/2.0 405 Method not allowed
CSeq: 3 UPDATE
Call-ID: event-1488675
From: "aiera-wcs" <sip:aiera-wcs@aiera-wcs-test.sip.twilio.com>;tag=3b403227
To: <sip:event-1488675@aiera-wcs-test.sip.twilio.com>;tag=12357438_6772d868_d15660e5-0c95-4b64-9cb3-d2784ebab21e
Via: SIP/2.0/UDP 172.31.76.59:30009;rport=30009;received=54.167.187.20;branch=z9hG4bKed6609608a8b71fc61b9e409b263b736
Server: Twilio
Contact: <sip:172.25.44.16:5060>
X-Twilio-CallSid: CAce0a13c53ca1c16bad7f87484e27c9e6
Content-Length: 0


17:24:40,262 INFO  SipUserAgentListener - EventScannerThread-27 Requested by uri sip:aiera-wcs-951335054@54.167.187.20:30009 SipUserAgent SIP UA: login: aiera-wcs assignedPort: 30009 listeningPort: 30009
17:24:40,263 INFO      SipCallProcessor - EventScannerThread-27 terminate: sipCall.id=event-1488675
17:24:40,263 INFO      SipCallProcessor - EventScannerThread-27 Stop rtc media session id event-1488675, sipCallId event-1488675
17:24:40,263 INFO          MediaSession - EventScannerThread-27 Stop MediaSession id: event-1488675
17:24:40,266 INFO          MediaSession - EventScannerThread-27 'event-1488675' has been terminated
17:24:40,266 INFO          MediaSession - EventScannerThread-27 Stop MediaSession id: event-1488675_127.0.0.1:7128225000401468489
17:24:40,270 INFO                 Agent - EventScannerThread-27 ICE state changed from Completed to Terminated. Local ufrag 052d7b70/ee07/11ea/8b3b/4f25d336c06c9etse1ehaejs2t
17:24:40,270 INFO  ergingDatagramSocket - EventScannerThread-27 Closing.
17:24:40,270 INFO         StunUdpSocket - EventScannerThread-27 Close socket
17:24:40,271 INFO          MediaSession - EventScannerThread-27 Stop MediaSession id: 052d7b70-ee07-11ea-8b3b-4f25d336c06c
17:24:40,272 INFO          MediaSession - EventScannerThread-27 '052d7b70-ee07-11ea-8b3b-4f25d336c06c' has been terminated
17:24:40,276 INFO            RestClient - API-ASYNC-pool-13-thread-16 SEND REST OBJECT ==>
URL:http://localhost:8081/apps/CallApp/ErrorStatusEvent
OBJECT:
{
  "nodeId" : "DbnxXbU4HjGDDasKOHLUpHEaG895Za1A@127.0.0.1",
  "appKey" : "callApp",
  "sessionId" : "127.0.0.1:7128225000401468489",
  "status" : "INTERNAL_SIP_ERROR",
  "info" : "INTERNAL_SIP_ERROR"
}
 

lamflam

New Member
Hello!
We tested the SIP call using /rest-api/call/ startup with the parameters:
Code:
{
  "callId":"1234567",
  "callee":"10002",
  "hasVideo":"false",
  "hasAudio":"false",
  "sipLogin":"10001",
  "sipAuthenticationName":"10001",
  "sipPassword":"1111",
  "sipDomain":"192.168.0.0",
  "sipPort":"5060",
  "appKey":"defaultApp",
  "sipRegisterRequired":"true",
  "toStream":"1234567"
}
on our WCS version 5.2.755 the problem is not reproduced.
Please collect and send us a report as described here.
Form for sending reports and logs
Please, for further diagnostics, tell us which SIP PBX do you use?
Dump traffic with the command
Code:
tcpdump -i any -s 4096 -w log.pcap
and send it to us for analysis.
The dump should be started before the call starts and finished after the stop.

If possible, please provide SSH access to your WCS server and SIP accounts for calls
You can send using a private form
Hi Max,

I was able to track this down to something else entirely. We are using Twilio and everything works for the first 25 minutes. WCS5 sends a SIP UPDATE after 25 minutes which Twilio responds to with a 405 METHOD NOT SUPPORTED and then WCS5 immediately terminates the call. Is this UPDATE message necessary? Is there a way to avoid it or should it not be terminating the call on a failure? Here are the logs for the exchange:


172.31.76.59 is the WCS IP
54.172.60.0 is the Twilio IP

Code:
--------------------> UPDATE sip:172.25.44.16:5060 SIP/2.0
from:   /172.31.76.59:30009
to:     /54.172.60.0:5060
time:   1599153880259
timeStamp:
isSender:       true
transactionId:  z9hg4bked6609608a8b71fc61b9e409b263b736
callId: event-1488675

UPDATE sip:172.25.44.16:5060 SIP/2.0
Via: SIP/2.0/UDP 172.31.76.59:30009;branch=z9hG4bKed6609608a8b71fc61b9e409b263b736
CSeq: 3 UPDATE
Call-ID: event-1488675
From: "aiera-wcs" <sip:aiera-wcs@aiera-wcs-test.sip.twilio.com>;tag=3b403227
To: <sip:event-1488675@aiera-wcs-test.sip.twilio.com>;tag=12357438_6772d868_d15660e5-0c95-4b64-9cb3-d2784ebab21e
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
X-Twilio-CallSid: CAce0a13c53ca1c16bad7f87484e27c9e6
Max-Forwards: 70
Route: <sip:54.172.60.0;lr>
Supported: timer
Min-SE: 90
Session-Expires: 1800;refresher=uac
Contact: <sip:aiera-wcs-951335054@54.167.187.20:30009>
Content-Length: 0


17:24:40,262 DEBUG          sipMessages - UDPMessageChannelThread-30009-273

<-------------------- SIP/2.0 405 Method not allowed
from:   /54.172.60.0:5060
to:     /172.31.76.59:30009
time:   1599153880261
timeStamp:
isSender:       false
transactionId:  z9hg4bked6609608a8b71fc61b9e409b263b736
callId: event-1488675

SIP/2.0 405 Method not allowed
CSeq: 3 UPDATE
Call-ID: event-1488675
From: "aiera-wcs" <sip:aiera-wcs@aiera-wcs-test.sip.twilio.com>;tag=3b403227
To: <sip:event-1488675@aiera-wcs-test.sip.twilio.com>;tag=12357438_6772d868_d15660e5-0c95-4b64-9cb3-d2784ebab21e
Via: SIP/2.0/UDP 172.31.76.59:30009;rport=30009;received=54.167.187.20;branch=z9hG4bKed6609608a8b71fc61b9e409b263b736
Server: Twilio
Contact: <sip:172.25.44.16:5060>
X-Twilio-CallSid: CAce0a13c53ca1c16bad7f87484e27c9e6
Content-Length: 0


17:24:40,262 INFO  SipUserAgentListener - EventScannerThread-27 Requested by uri sip:aiera-wcs-951335054@54.167.187.20:30009 SipUserAgent SIP UA: login: aiera-wcs assignedPort: 30009 listeningPort: 30009
17:24:40,263 INFO      SipCallProcessor - EventScannerThread-27 terminate: sipCall.id=event-1488675
17:24:40,263 INFO      SipCallProcessor - EventScannerThread-27 Stop rtc media session id event-1488675, sipCallId event-1488675
17:24:40,263 INFO          MediaSession - EventScannerThread-27 Stop MediaSession id: event-1488675
17:24:40,266 INFO          MediaSession - EventScannerThread-27 'event-1488675' has been terminated
17:24:40,266 INFO          MediaSession - EventScannerThread-27 Stop MediaSession id: event-1488675_127.0.0.1:7128225000401468489
17:24:40,270 INFO                 Agent - EventScannerThread-27 ICE state changed from Completed to Terminated. Local ufrag 052d7b70/ee07/11ea/8b3b/4f25d336c06c9etse1ehaejs2t
17:24:40,270 INFO  ergingDatagramSocket - EventScannerThread-27 Closing.
17:24:40,270 INFO         StunUdpSocket - EventScannerThread-27 Close socket
17:24:40,271 INFO          MediaSession - EventScannerThread-27 Stop MediaSession id: 052d7b70-ee07-11ea-8b3b-4f25d336c06c
17:24:40,272 INFO          MediaSession - EventScannerThread-27 '052d7b70-ee07-11ea-8b3b-4f25d336c06c' has been terminated
17:24:40,276 INFO            RestClient - API-ASYNC-pool-13-thread-16 SEND REST OBJECT ==>
URL:http://localhost:8081/apps/CallApp/ErrorStatusEvent
OBJECT:
{
  "nodeId" : "DbnxXbU4HjGDDasKOHLUpHEaG895Za1A@127.0.0.1",
  "appKey" : "callApp",
  "sessionId" : "127.0.0.1:7128225000401468489",
  "status" : "INTERNAL_SIP_ERROR",
  "info" : "INTERNAL_SIP_ERROR"
}
 
Top