On Mon, 2010-01-11 at 15:53 -0500, M. Ranganathan wrote:
> I have found the References header a very handy way of tracking causal
> chains in a B2BUA. I have added a parameter x-sipx-branchid which
> contains the topmost via header of the transaction that triggers the
> request containing the References header. This + call ID allows us to
> nicely tie transactions together.
> 
> However I do not understand the purpose of the rel parameter. I would
> like to see it be used to record the method of the triggering request.
> 
> For example rel=INVITE
> 
> As such rel=CHAIN does not provide much information.

The rel parameter records the manner in which the current dialog relates
to the named dialog.  See
http://tools.ietf.org/html/draft-worley-references-05#section-2:

The currently defined values of the "rel" parameter are:

      "chain" meaning that this request is the logical continuation of
      the dialog with the specified Call-Id through a B2BUA or the like,
      in that it will carry media that have the same meaning to the user

      "inquiry" meaning that this request was generated to obtain
      information needed to properly process a request with the
      specified Call-Id.  (For example, in section 2.16, "Call Pickup"
      of [service-examples], a SUBSCRIBE is generated to discover the UA
      which sent an INVITE to a designated AOR.)

      "join" - this value is permanently reserved so that it may be used
      as a value of cognate data items when describing dialogs related
      by a "Join" header

      "refer" meaning that this request was generated due to a REFER
      with the specified Call-Id

      "replaces" - this value is permanently reserved so that it may be
      used as a value of cognate data items when describing dialogs
      related by a "Replaces" header

      "service" means that this dialog is to obtain "service media" for
      use by the dialog with the specified Call-Id.  "Service media"
      includes music-on-hold, alert tones, and the like.

      "sequel" means that this dialog is the continuation of the
      conversation carried by the dialog with the specified Call-Id

      "xfer" meaning that the dialog of this message and the dialog with
      the specified Call-Id are the two legs of a consultative (or
      attended) transfer.  One endpoint of each dialog will become an
      endpoint of the final dialog.

> I would
> like to see it be used to record the method of the triggering request.
> 
> For example rel=INVITE

Why not use "x-sipx-method=INVITE"?

Dale


_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to