Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Repair Jira Macros

...

Page Properties


Target releaseSDK 6.12.0
Epic

Jira Legacy
serverDialogic System JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId8f70d0a49d998c43-20dab14a-363f37e0-81e294cb-5b2706a93a6ae776ac9fe88f
keyBRKT-990

FR

Jira Legacy
serverDialogic System JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId8f70d0a49d998c43-20dab14a-363f37e0-81e294cb-5b2706a93a6ae776ac9fe88f
keyBRKT-995

Document status

Status
colourBlueGreen
titleDraftFinal

Document owner


Goals

Currently, the 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.201" 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 not 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.

...

#TitleUser StoryImportanceNotes
1

Add an entry to the beginning of the SIP INVITE header list for the SIP URI value from the SIP INVITE.

The complete SIP Request URI value string i.e. 1234@dialogic.com:5060 will appear after the name of the new entry.

The name of new entry will be Request-URI.

i.e. Request-URI: 1234@dialogic.com:5060

As a user, I would like to know the SIP URI value, so I can determine the original phone number of a call that was forwarded.High

This information will be present for the application to use after the BfvLineWaitForCall API function call returns. The user will need to malloc memory for the sip_header_list member of the structure args_telephone in order to receive both the SIP URI value and the headers from the SIP INVITE. The user will need to parse the SIP INVITE headers list to get the SIP Request URI.

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

This feature should also not impact or be aware of the diversion values. 

3



...

The user will need to malloc memory before calling the API function BfvLineWaitForCall() for the for the sip_header_list member of the structure args_telephone before calling the API function BfvLineWaitForCall() in order to receive both the SIP URI value and the headers from the SIP INVITE.

An entry for the SIP URI from the SIP INVITE will be added to the beginning of the SIP INVITE header list. The complete sip Request URI value string i.e. 1234@dialogic.com:5060 will appear after the name of the new entry. The name of the new entry will be Request-URI. An example of the  SIP INVITE URI entry at the beginning of the SIP INVITE header list is:

Request-URI: 1234@dialogic.com:5060

This value will be available to the application when the BfvLineWaitForCall() API function returns. The user will need to parse the SIP INVITE headers list to get the SIP Request URI which will be the first entry in the list.

This aligns with when the called_party_number value and the SIP Headers are available to the application after MillIntCallWaitForSetup() processing. 

...