Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties


Target releaseSDK 6.12.0
Epic

Jira Legacy
serverDialogic JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId8f70d0a4-20da-363f-81e2-5b2706a93a6a
keyBRKT-990

FR

Jira Legacy
serverDialogic JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId8f70d0a4-20da-363f-81e2-5b2706a93a6a
keyBRKT-984

Document status

Status
colourBlue
titleDraft

Document owner


Goals

Currently, SR140 does not pass the SIP Request URI information to the application.  It does appear in the ECC log, so it gets to our SIP stack.  Customers sometimes want the part with the number@ip_address (e.g. "1111@10.160.110.201Image Added" here) because it is different from the rest of the information in the SIP INVITE.  Normally, the called number (sometimes incorrectly called the DID) is provided in the To: field in the SIP INVITE message and that's what we pass up to the application.  (In fact, the To: field is a SIP header and an application can get all SIP headers.)  Sometimes though, usually if a call gets forwarded, the called number will be reflected in the SIP URI though and no the To field.  We do not currently pass the SIP URI up to the application and so as a feature request, we would be looking to make the Request URI accessible to the application.

Background and strategic fit

When processing an inbound call, the CALL_RES called_party_number is set to the alphanumeric value contained in the SIP “To:” header. Typically, this value is the same value as contained in the SIP INVITE Request-Line. Sometimes though – usually if a call gets forwarded – the called number in not reflected in the “To:” field but in the SIP Request-URI, which is not passed to the application.  The To: phone number value (part before the @ symbol) is available to the application in the called_party_number.  The complete To: header is available to the application from parsing the SIP headers passed to the application. 

By implementing this feature, it will allow customers to retrieve the SIP the SIP Request URI from the inviteSIP Invite.

Assumptions


Requirements

#TitleUser StoryImportanceNotes
1

Add member to CALL_RES Structure for SIP URI value in INVITE.   Name is TBD.

The application would like to retrieve the SIP URI Invite value.High

This information will be present for the application to use after the BfvLineWaitForCall API function call returns.

2This feature will not change the current behavior for the CALL_RES called_party_number value.
High

Also is not impacted by the diversion values. 

3



User interaction and design

Add to CALL_RES structure a string to contain the value of the SIP URI value from the initial SIP INVITE.  This value will be available to application when the BfvLineWaitForCall API function returns.  This aligns with when the called_party_number value and the SIP Headers are available to the application.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome
Do we want to complete SIP Request URI string i.e. 1234@dialogic.com:5060 or just the phone number part to be available?

Not Doing