[asterisk-dev] SIP CANCEL/To tag

[Johansson Olle E]

31 mar 2006 kl. 02.39 skrev alex at pilosoft.com:

> Hello,
>
> Asterisk will not use the tag that was generated by remote site for  
> the
> To: field when sending CANCEL message.
>
> Relevant line of chan_sip.c:
>         /* Add tag *unless* this is a CANCEL, in which case we need  
> to send it exactly
>            as our original request, including tag (or presumably  
> lack thereof) */
>         if (!strcasestr(ot, "tag=") && sipmethod != SIP_CANCEL) {
>                                        ^^^^^^^^^^^^^^^^^^^^^^^
>
> This causes a problem with certain gateways, which do expect CANCEL to
> contain the tag that was generated by the gateway in response (and  
> sent in
> the 100 or 180 response).
>
> RFC3261 is conflicting itself about it. On one hand 8.2.6.2 says:
>
>    If a request contained a To tag in the request, the To header field
>    in the response MUST equal that of the request.  However, if the To
>    header field in the request did not contain a tag, the URI in  
> the To
>    header field in the response MUST equal the URI in the To header
>    field; additionally, the UAS MUST add a tag to the To header  
> field in
>    the response (with the exception of the 100 (Trying) response, in
>    which a tag MAY be present).  This serves to identify the UAS  
> that is
>    responding, possibly resulting in a component of a dialog ID.  The
>    same tag MUST be used for all responses to that request, both final
>    and provisional (again excepting the 100 (Trying)).  Procedures for
>    the generation of tags are defined in Section 19.3.
>
> I read it that UAC after receiving a message with a tag should  
> always use
> the tag.
>
> On other hand, 9.1 says:
>
>    The following procedures are used to construct a CANCEL  
> request.  The
>    Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>    fields in the CANCEL request MUST be identical to those in the
>    request being cancelled, including tags.
>
> What does "including tags" really mean in this context? Does it  
> mean the
> tags, as updated by UAS?

It means that we should send exactly what we sent in the INVITE,
not the ones added later in the session by the UAS.

/O