from字段：The From header field is a required header field that indicates the originator of the request. It is one of two addresses used to identify the dialog. The From header field contains a URI, but it may not contain the transport, maddr, or ttl URI parameters. A From header field may contain a tag used to identify a particular call. A From header field may contain a display name, in which case the URI is enclosed in < >. If there is both a URI parameter and a tag, then the URI including any parameters must be enclosed in < >. Examples are shown in Table 6.8. A From tag was optional in RFC 2543 but is mandatory to include in RFC 3261.
to字段：**The To header field is a required header field in every SIP message used to indicate the recipient of the request. Any responses generated by a UA will contain this header field with the addition of a tag. (Note that an RFC 2543 client will typically only generate a tag if more than one Via header field is present in the request.) Any response generated by a proxy must have a tag added to the To header field. A tag added to the header field in a 200 OK response is used through- out the call and incorporated into the dialog. The To header field URI is never used for routing—the Request-URI is used for this purpose. An optional display name can be present in the header field, in which case the SIP URI is enclosed in < >. If the URI contains any parameters or username parameters, the URI must be enclosed in < > even if no display name is present. The compact form of the header field is t. Examples are shown in Table 6.12.
- invite 到 200 ok属于一个事务
- bye和200 ok属于一个事务
# 事务1: INVITE 180 200
# 事务2: ACK
# 事务3: BYE 200 ok
# 由于事务3的发起方是B, 所以
所以在处理OpenSIPS脚本的时候，特别是关于from_tag和to_tag的处理的时候，我们不能先入为主的认为初始化和序列化的的所有请求里from_tag和to_tag都是不变的。 也不能先入为主的认为from_url和 to_url是一成不变的。
The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit). In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 184.108.40.206 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI.