Sip rfc 4538 authorization request through dialog

Background:

Generally, when a UA receives a request that creates a dialog (invite/Subscribe/refer), it must decide whether to authorize the request, in some cases, UA determines whether to authenticate the request by determining whether the request is in a created dialog,

For example, after invite creates a dialog, UA does not need to authenticate other requests (prack, Act, etc.) sent in this dialog, but the problem is that for refer, message, and SUBSCRIBE requests, A new dialog will be created. If the UA wants to know whether these requests are based on a new dialog request after a created dialog, what is the judgment? This specification came into being.

 

Applicability of this specification:

Invite, refer, and subscribe methods will create a dialog. Generally, invite is used to create a dialog, and then reffer and subscribe are used to create an independent dialog, but for reffer or subscribe, how does UA determine that these requests are newly created in an existing dialog?

 

This specification introduces a new SIP Message Header target-dialog and its corresponding opiontag to indicate whether UA supports this extension.

The refer method is used as an example to describe how to use this extension, for example:

User A sends an invite and forwards it to user B through server a and server B in the middle. User B returns the 200 OK message. If user B supports this extension, it adds the tdialog option in the support header, inform the other party that it supports this extension. After receiving the 200ok message with the tdialog option, user a creates a dialog between user a and user B.

After a call is established, server a wants to send a refer to user B and responds with the 200 OK message. The server knows that user B supports this extension. Therefore, the server adds the target-dialog header to the refer request, the ID of the dialog created for invite, including call-ID, from-tag, and to-tag.

After receiving the refer, user B finds the target-dialog header and confirms that the request already has a difer. User B determines that the request must be sent by user A or the proxy in the middle, therefore, user B receives and processes the request.