Sip rfc 4538 authorization request through dialog

Source: Internet
Author: User
Tags rfc

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.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.