Saranya.Rajkumar.IX: Published

2022-05-26T16:10:30Z

Published

WikiSysop: Created page with "{{ComponentRN |ComponentId=0371606b-df5e-41e2-869d-2009e76b916e |JQL=project = "WebRTC Media Service" AND id = WRTCMS-1014 OR id = WRTCMS-1005 OR id = WRTCMS-965 OR id = WRTCM..."

2022-05-26T06:15:40Z

Created page with "{{ComponentRN |ComponentId=0371606b-df5e-41e2-869d-2009e76b916e |JQL=project = "WebRTC Media Service" AND id = WRTCMS-1014 OR id = WRTCMS-1005 OR id = WRTCMS-965 OR id = WRTCM..."

New page

{{ComponentRN
|ComponentId=0371606b-df5e-41e2-869d-2009e76b916e
|JQL=project = "WebRTC Media Service" AND id = WRTCMS-1014 OR id = WRTCMS-1005 OR id = WRTCMS-965 OR id = WRTCMS-966
|DeploymentTypeId=ec194bf2-b79a-436d-8ff6-eaff94d9f43a, 5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-05-13
|Highlight=This release includes new fields for troubleshooting purposes and contains important improvements and fixes.<br />
}}
{{Issue
|TicketNumber=WRTCMS-1014
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Previously, on receiving of SIP re-Invite WebRTC Gateway didn’t stop existing DTLS context. In case when WebRTC GW didn’t finish to process existing DTLS context and new re-Invite was received it could lead to situation when previous context was used for re-established media connection. As result, no media was present for the call.Now, WebRTC GW always stops and destroys existing DTLS context in case when new SIP re-Invite is received.
|LocalContent=WebRTC Gateway now clears the existing DTLS context when a new SIP re-invite is received. Previously, when the WebRTC Gateway did not complete processing of the existing DTLS context and a new SIP re-invite was received, the existing DTLS context was used for re-establishing media connection which might have resulted in no media for the call.
}}
{{Issue
|TicketNumber=WRTCMS-1005
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Previously, WebRTC MS incorrectly handled next scenario:# Call is established# Agent performs consult call# Agent puts consult call on hold. SIP NOTIFY is sent to the WebRTC Gateway# WebRTC Gateway processes SIP NOTIFY, sends 200 OK so the SIPS and sends “EVENT-TALK” message to the client# While the hold operation is still in progress agent releases consult call. SIPS sends SIP re-Invite to the WebRTC GW to recover the main call.# WebRTC Gateway processes SIP INVITE and sends OFFER SDP to the client# At the same time client finishes processing of the “EVENT-TALK” and sends OFFER SDP to the WebRTC GWIt could lead to the situation when audio call may stuck in re-Invite state declining all subsequent SIP re-Invite attempts with “486 Busy Here” error.Now, WebRTC MS correctly handles described scenario.
|LocalContent=WebRTC Media Service now correctly handles all the audio calls in SIP re-invite state.

Previously, when WebRTC Media Service handled the scenario in the following way (below), it led to a situation where the audio call got stuck in the SIP re-invite state, declining all subsequent SIP re-invite attempts with the <tt>486 Busy Here</tt> error:

#The WebRTC Call is established.
#The agent performs a consult call.
#The agent puts the consult call on hold and '''SIP NOTIFY''' is sent to the WebRTC Gateway.
#The WebRTC Gateway processes the SIP NOTIFY and sends an '''OK''' message so that the SIP Server sends an '''EVENT-TALK''' message to the client.
#While the hold operation is in progress, the agent releases the consult call and SIP Server sends a SIP re-invite request to the WebRTC Gateway to recover the main call.
#The WebRTC Gateway processes the SIP re-invite and sends '''OFFER SDP''' to the client.
#Simultaneously, the client finishes processing the '''EVENT-TALK''' message and sends '''OFFER SDP''' to the WebRTC Gateway.
}}
{{Issue
|TicketNumber=WRTCMS-966
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=Now WebRTC gateway logs into elasticserach/stdout the message in case if there is no relay candidates received from client side.Also, in such case the metric “{{wrtc_system_error {type="norelay", domain="%DOMAIN NAME%"}}}" will be incremented
|LocalContent=WebRTC Gateway now logs a message into Elasticsearch/stdout even if there are no relay candidates received from the client side, where the '''wrtc_system_error {type="norelay", domain="%DOMAIN NAME%"}''' metric is incremented.

<br />
}}
{{Issue
|TicketNumber=WRTCMS-965
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=Now elasticsearch\\grafana log messages contains the following fields for troubleshooting purposes: “loginName“ - agent login name for given webrtc session ”callUUID” - Genesys callUUID that can be tracked through voice and webrtc services
|LocalContent=The Elasticsearch\Grafana log messages now include the following fields for troubleshooting purposes:

*'''loginName''' - Agent name for the given WebRTC session.
*'''callUUID''' - Genesys Call UUID that is tracked through voice and WebRTC services.
}}

@@ Line 4: / Line 4: @@
 |DeploymentTypeId=ec194bf2-b79a-436d-8ff6-eaff94d9f43a, 5439f1be-1868-4091-b058-1667389b6ce1
 |ReleaseDate=2022-05-13
-|Highlight=This release includes new fields for troubleshooting purposes and contains important improvements and fixes.<br />
+|Highlight=This release includes important improvements and fixes.<br />
 }}
 {{Issue

RN/WebRTCMedia Service/100.0.038.0000 - Revision history

Saranya.Rajkumar.IX: Published

WikiSysop: Created page with "{{ComponentRN |ComponentId=0371606b-df5e-41e2-869d-2009e76b916e |JQL=project = "WebRTC Media Service" AND id = WRTCMS-1014 OR id = WRTCMS-1005 OR id = WRTCMS-965 OR id = WRTCM..."