Subject: RE: [Sip] Handling of duplicate requests with differing request p aths.

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 02:28:22 -0500

inline.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 2:05 AM
> To: [email-masked]
> Cc: A Venkatraman; Fairlie-Cuninghame, Robert; Pekka Pessi; Jo Hornsby
> Subject: Re: [Sip] Handling of duplicate requests with 
> differing request
> paths.
> 
> 
> 
> Hi,
> 
> Still a small clarification I would like to get on this issue:
> 
> Assume that the UAS receives the INVITE from two separate "routes". It
> sends 200 to the first one, and 482 to the other. 
> 
> Now, the ACK to the 482 response has the same Via branch as its
> corresponding INVITE, but the ACK to the INVITE that generated the 200
> MAY have another Via branch than the INVITE.
> 
> So, my question is: IF the ACK to the 200 has another Via branch than
> its INVITE, is there a possibility that the ACK will be routed so that
> when it is received by the UAS it will contain an IDENTICAL Via branch
> as the ACK to the INVITE that generated 482? 

Yes. I suspect this will happen in some cases. The treatment of ACK-200 as a
separate transaction would imply that the branch ID is different. But,
existing proxies may in fact use the same branch ID.

> IF that is possible, the
> UAS will not know that they are two separate ACKs.

No, it will know. Section 17.2.3 on matching requests to transactions, is
clear that you use the tag in the To of the ACK to match it against the
response that was sent. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Itamar Gilad <[email-masked]>
Date: Tue, 6 Nov 2001 15:55:25 +0200

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tue, November 06, 2001 9:47 AM
> To: 'Christer Holmberg'; Bob Penfield
> Cc: [email-masked]
> Subject: RE: [Sip] Handling of duplicate requests with 
> differing request
> p aths.
> 
> The way an ACK gets matched to its 2xx is strictly through the dialog
> identifiers - To, From and Call-ID, and this matching happens 
> in the UA
> core, not in the transaction layer (thus via, request uri are both
> irrelevant).
> 
> Thanks,
> Jonathan R.
> 

Does that apply to a stateful proxy too?

For example: what about when the INVITE gets spiraled through proxy P and it
Record-Routes both times.  The ACK will also get spiraled because of the
Route list, but the proxy needs to inspect the Req-URI in the ACK each time
it hits the proxy in order to correctly identify which of the original
INVITEs it matches.

Here's another bizarre one:  INV and 200 go through proxy P1.  The UAS puts
me@P1 as Contact therefore The ACK hits P1 with a different Req-URI (me@P1)
than the original INVITE. In this case inspecting the Req-URI will not map
the ACK to the original INVITE.

thanks
  Itamar

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 23:04:58 -0500

> From: Shan Lu [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 10:19 AM
> To: 'Jonathan Rosenberg'; [email-masked]
> > You need different response codes when there is a differing 
> > set of protocol
> > behaviors that a client should take. There isn't anything a 
> > client can do
> > about a merged request, and anything it might do (try later) 
> > is no different
> > than what it would do for a loop detected (which is also, 
> try later).
> > Therefore, I think it is fine for the same response code to 
> > be used in this
> > case.
> > 
> 
> Isn't "try later" something that a UAC can always do? 

Sure.

>Then I am
> wondering why we need response codes 404, 410, 483, and 486, just to
> name a few?

These response codes imply additional semantics. 486, for example, would
cause some kind of busy tone or something to be played. 404 might ask the
user if they want to delete the entry from the address book since it doesn't
appear to be valid. 

Request merging and loops are both protocol errors that have little interest
to the human user, and there is nothing much to convey to them or do beyond
try later.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 23:27:57 -0500

> From: Itamar Gilad [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 8:55 AM
> To: 'Jonathan Rosenberg'; 'Christer Holmberg'; Bob Penfield
> Cc: [email-masked]

Absolutely not. Matching of ACK for 2xx to a particular 2xx is a UAS
function.

> it hits the proxy in order to correctly identify which of the original

There is no need to correctly identify which of the original IVNITEs it
matches in the case of a proxy. The proxy is not retransmitting the 2xx;
there is no need to match. You may want to do it for purposes of call
statefulness or something like that. Thats different. See below.

> the ACK to the original INVITE.

Correct. Only UAS match ACK to 2xx, and its done with call legs.

If you are building a call stateful proxy that needs to do this, the call
legs give you part of the story. There will be an instance of the call leg
for each spiral through the proxy. Then, to match to a particular instance,
the proxy will need to use the r-uri of the incoming request. This is true
not just for ACK-2xx, but for re-INVITE, BYE and other things.

-Jonathan R.
---