Subject: [SIP] Not adding To tag in the re-invite final Response.

From: "Provin Gurung" <[email-masked]>
Date: Sun, 30 Jul 2000 14:33:34 -0400

This is on reference to the Appendix G. Changes to be made, section.

It state the following:

"Bug: A INVITEs B through a proxy, B responds to A with a tag in the To
field. Later, A sends a  re-INVITE to B, with a tag in the To field, through
the proxy. This request is malformed, so the proxy returns a 400 error.
Normally, a proxy will insert a tag into the To field of a 400 response. But
here, it cannot, since a tag is already present in the request. Thus, the
rule should be that if a request arrives with a tag, the entity sending a
response MUST NOT insert an additional tag, even if it a different entity
than the one that created the tag in the first place."

However I am worried about the ACK. Normally a proxy would generate an ACK
for the 4xx response that it received. Now if the proxy also proxies the
final response upstream without changing any tag information in the To
field, how would it identify that the ACK that might come back from the
upstream proxy/UA is destined for the proxy and not to be proxied
downstream.

Or should in case of re-Invites the Proxy should not send ACK's for non 2xx
final responses?

Thanks,

Proveen

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 31 Jul 2000 10:55:06 +0100

> "Bug: A INVITEs B through a proxy, B responds to A with a tag in the
> To field. Later, A sends a  re-INVITE to B, with a tag in the To
> field, through the proxy. This request is malformed, so the proxy
> returns a 400 error. Normally, a proxy will insert a tag into the
> To field of a 400 response. But here, it cannot, since a tag is
> already present in the request. Thus, the rule should be that if
> a request arrives with a tag, the entity sending a response MUST NOT
> insert an additional tag, even if it a different entity than the one
> that created the tag in the first place."

I think that this is a bug which has actually been fixed.  See
Section 6.44 (To) of the July 13 bis, which says the following:
    "Section 11 describes when the “tag” parameter MUST appear in
     subsequent requests. Note that if a request already contained
     a tag, this tag MUST be mirrored in the response; a new tag
     MUST NOT be inserted."

> However I am worried about the ACK. Normally a proxy would generate
> an ACK for the 4xx response that it received. Now if the proxy
> also proxies the final response upstream without changing any
> tag information in the To field, how would it identify that the ACK
> that might come back from the upstream proxy/UA is destined for the
> proxy and not to be proxied downstream.

With the new bis rules about UAs having to insert Contact headers,
the signallying route is always well-defined for re-INVITES (whether
Record-Route was used or not).  Given this fact, only in the most
bizarre of cases will a re-INVITE not result in either:
 a) a 2xx class response; or
 b) a non-2xx class response.

In the case of 2xx, the reliability is end-to-end, as usual.
And in the case of non-2xx, the reliability is hop-by-hop, as usual.
The stateful proxy knows if it sent a response and what class
it was, so it is easy for it to deduce if the ACK is for itself or
not.

We had a bit of a discussion about this last week; see the thread
entitled "ACK handling at Stateful Proxies".

> Or should in case of re-Invites the Proxy should not send ACK's for
> non 2xx final responses?

Nah.  Proxies typically treat INVITES and re-INVITES identically;
the potentially different behaviour is implied by the presence or
otherwise of a Route header.

HTH,

 - Jo.
--
  Jo Hornsby; IT Professional         --       mailto:[email-masked]
 Ubiquity Software Corporation        --         http://www.ubiquity.net/

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip