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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 26 Oct 2001 06:43:25 -0700

Hi Christer & Pekka,

What would actually happen (eg whether the same or different tag is used in
responses) would be implementation specific [if a UAS ignored the text that
Jo Hornsby pointed out]. It would depend on how a negative result to the
algorithm specified in Section 17.2.3 (Matching Requests To Server
Transactions) is handled.  

However, that discussion (for INVITE anyway) is irrelevant because Bis-05
does describe the correct behavior for an INVITE request (ie send 482
response) but it is not specified for non-INVITE requests.

Also Via hiding was removed from the SIP spec in bis-02 - so that is the
answer to that question. :)

Regards, 

Robert.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 2:18 PM
> To: Pekka Pessi
> Cc: [email-masked]; Robert; [email-masked]
> Subject: Re: [Sip] Handling of duplicate requests with 
> differing request
> p aths.
> 
> 
> 
> Hi
> 
> >In message 
> <[email-masked]> 
> Fairlie-Cuninghame, Robert ><[email-masked]> writes:
> >>Like a 200 OK? [which sets up two subscriptions or two active calls]
> > 
> >         Does it? Both have identical to-tags.  How is the original
> >         client going to tell difference?  It does not have 
> a benefit of
> >         branch parameter.
> 
> I agree with Pekka. There are no via headers in the response when the
> UAC receives it, and if the To-tags are identical the UAC 
> will treat the
> response as a retransmission of the final response (the UAS 
> will resend
> the final response until it receives the ACK).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Fri, 26 Oct 2001 17:03:30 +0300

Hi,

>Transactions) is handled.

I am not sure I understand how it can be an implementation specific
issue. If the UAC receives two (or more) identical 200 OK responses,
doesn't it always assume it is a re-transmisson?
 
>answer to that question. :)

I know. I had 3GPP on my mind, but the way it's done there doesn't
affect this.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Oct 2001 17:16:18 +0300

Hi,

Another question related to this:

If the UAS receives multiple instances of the INVITE, it may send 200 to
the first and then 482 to the others.

Now, it also have to receive separate ACKs for all the final responses,
so my question is: will the Via branch always be the same in the ACK as
it was in the INVITE (or whatever request method), or how does the UAS
map the ACK to a specific 482 (or 200)?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Pekka Pessi <[email-masked]>
Date: 26 Oct 2001 17:39:52 +0300

>map the ACK to a specific 482 (or 200)?

	For the 482, the branch value is always identical.  The ACK for
	200 may follow different route, so the branch value may be
	different as well as the requestURI.  Section 5.1.1 in bis-04,
	13.1 in bis-05.

						Pekka

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Oct 2001 17:45:00 +0300

Hi,

>         different as well as the requestURI.  Section 5.1.1 in bis-04,

So, if we have sent one 200 OK, and multiple 482, and we receive an ACK
with a branch we can't match, we have to assume that it belongs to the
200 OK. That is, of course, true even in a normal case where we only
received one instance of the INVITE, and only sent one final response
(200 OK).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 26 Oct 2001 19:32:46 +0300

Hello,

As it was pointed out, section 13.3.1 indicates that a 482 response has
to be generated by the UAS. However, it is true that this should be a
general behavior applicable not only to INVITEs but to any method.
Furthermore, proxies should follow this behavior as well.

We will clarify this.

Regards,

Gonzalo

A Venkatraman wrote:
> 
> Since the 4xx response is ACKed by the proxy, the VIA will have the same
> branch.
> If it is a 2xx, ACK may be received with a different VIA (ie from the UAC,
> if not Record-routed). In this case, the UAS will keep retransmitting the
> 200
> 
> From:   [email-masked] [mailto:[email-masked]]  On Behalf Of Christer
> Holmberg
> Sent:   Friday, October 26, 2001 9:16 AM
> To:     [email-masked]
> Cc:     Fairlie-Cuninghame, Robert; Pekka Pessi
> Subject:        Re: [Sip] Handling of duplicate requests with differing request
> paths.
> 
> Hi,
> 

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "A Venkatraman" <[email-masked]>
Date: Fri, 26 Oct 2001 09:53:20 -0500

-----Original Message-----

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Oct 2001 09:05:11 +0200

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? IF that is possible, the
UAS will not know that they are two separate ACKs.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "A Venkatraman" <[email-masked]>
Date: Mon, 29 Oct 2001 09:08:21 -0600

Christer
It is mandatory to include a Contact in the 200 response to an INVITE.
The ACK will therefore be sent to the CONTACT and should have the topmost
VIA of the UAC or its outbound proxy.
Unless, the proxies in the path have record-routed, in which case, the
topmost VIA will be that of the first immediately preceding proxy from the
UAS which record-routed.
In both cases, the VIA of the 200 will differ from the VIA of the 482.

Venkat

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On Behalf Of Christer
Holmberg
Sent:	Monday, October 29, 2001 1: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,

Regards,

Christer Holmberg
Ericsson Finland

Gonzalo Camarillo wrote:
> > > >What would actually happen (eg whether the same or different tag is
used
> > in
> > > >responses) would be implementation specific [if a UAS ignored the
text
> > that

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 29 Oct 2001 19:11:02 +0200

Hello,

Exactly. The proxy ACKing the 482 will not be in the route set of the
dialog. Therefore it will not handle the ACK for the 2xx response.

Regards,

Gonzalo

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 29 Oct 2001 17:21:04 -0000

> <snip>
> Q1. Is 482 the proper response? This isn't a loop, is it?

It's important not to get too hung-up on the
default Reason Phrases.  An implementor is
free to use "Request Merged", or sommat, as
the Reason Phrase that accompanies the 482.
482 is specified by bis-05, and I think
fits very well semantically with the
"classical" notion of a 482.

> Q2. 200 followd by 4xx works if the paths are due to a forking proxy,
> which will sit there collecting responses and send upstream the "best
> one". Now what if the requests travel different paths because a
> stateless load balancer distributes requests round robin to a farm of
> proxies and multiple requests end up in the same UAS? In this case, both
> 200 and 4xx are received by the UAC.

This load balancer is broken, then; or, at least,
the system that it is working in as a whole is
broken.  It should not be possible to observe
any such behaviour from any other SIP client's /
server's perspective.

> Let's further assume that the UAS
> responds with 1xx to the first request -- an early dialog is setup.
> According to 13.2.2.3, the subsequest 4xx causes the UAC to terminate
> the INVITE transaction, which means the call is dropped. And what if the
> 4xx arrives before 1xx? Does this mean that a load balancer here has to
> be at least transaction stateful? This is also a valid case when
> different proxies are used for retransmissions.

Retransmissions should always go to the same
server (proxy).

> Q3. An INVITE is forked and then merged at a stateless proxy which
> precedes the UAS. The topmost VIA of the requests are the same. So the
> UAS thinks they are retransmissions.

Hmmm...I don't think that this can happen in
practise, but we might need to tighten up
the definition of how unique a branch ID is
to make it explicit.

I may be misreading, but it seems to me that
bis-05 only guarantees uniqueness within a
particular transaction (line 2188).  I think
it might be inferred that it's actually also
going to be unique with a set of N transactions
that share a particular { Request-URI, From,
To, Call-ID, CSeq }-tuple; however, I might
just be being optimistic.

Step 3 of section 16.5 does suggest a format
for forming branch IDs, but this is not
mandatory (as is right, I do think).  I would
prefer to see something that explicitly states
that branch IDs should be unique with a
particular client's space.

> 200 Oks are returned, but through
> different paths. Now you have one dialog setup b/w UAC and UAS, but
> through different routes. Will this cause problem for proxies (SF) all
> the path?

Hopefully the above will solve that problem.

 - Jo.

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 29 Oct 2001 11:52:49 -0500

<snip>

200 and 4xx are received by the UAC. Let's further assume that the UAS

UAS thinks they are retransmissions. 200 Oks are returned, but through

Thanks,

Shan Lu

sentitO Networks

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 29 Oct 2001 20:11:34 +0200

Hello,

> particular client's space.

What we want is that the UAS (or proxy) behind the stateless proxy can
distinguish between both incoming requests (each of them has traversed a
differenet set of nodes). If the stateless proxy calculates the brach
using, besides request-URI, Cseq, etc, the Via header of the incoming
request, the problem is resolved. The UAS will see different top Via
headers even though both requests com from the same stateless proxy.

We will add that in either section 16.5 or 16.9.

Regards,

Gonzalo

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 29 Oct 2001 17:10:46 -0500

> From: Jo Hornsby [mailto:[email-masked]] 
> Sent: Monday, October 29, 2001 12:21 PM
> To: Shan Lu; [email-masked]
> Subject: RE: [Sip] Handling of duplicate requests with 
> differing request paths.
> 
> 

This sounds like a pretty good reason to define a new cause code rather
than let everybody come up with their own reason phase.

> any such behaviour from any other SIP client's /

Not sure what is broken. Load balancer forwards INVITE #1 to Proxy #1
and INVITE #2 (retransmission of #1) to Proxy #2. Nothing wrong for a
stateless load balancer. UAS responsds with 200 to #1 and 4xx to #2
which both are sent upstream to UAC. The question is: does 4xx terminate
the transaction according to 13.2.2.3.

> Retransmissions should always go to the same

In a perfect world, yes. What if the proxy that forwards initial INVITE
goes down? Let's say its backup (through DNS lookup) has a slightly
different view of the network topology and sends retransmissions through
a different path.

<snip>

Shan Lu
sentitO Networks

---

From: [email-masked]
Date: Mon, 29 Oct 2001 16:23:00 -0600

Two issues: I was pretty sure that we had decided not to return an
error code at all (since the forked messages may have gone through
proxies that added proxy-require headers, etc); this would leave the
clients to sort things out.

That notwithstanding, if we are choosing a status code for this
situation, we should make sure it doesn't override any other "useful"
status codes at the proxy (by being a lower number). For example,
a UA receiving a "482 Request Merged" is not ever useful. A 500
response, however, might convey some information.

To avoid having a "Request Merged" response overriding a useful
response, I'd suggest that we select status code 599 for request
merging.

Unless, of course, my first assertion was correct (and I do believe
that it is): proxies shouldn't merge requests at all, and this
should be a UAS issue.

/a

> From: Shan Lu [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 4:11 PM
> To: 'Jo Hornsby'; [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 30 Oct 2001 01:56:17 +0200

Hi,

> that it is): proxies shouldn't merge requests at all, and this

Yes, the one that returns the 482 is the UAS. The only thing a proxy
does is to compute a different branch in the Via for the requests that
will be merged by the UAS.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Oct 2001 07:42:24 +0200

Hi,

Consider the following scenario:

        |-----P2-----|
UAC ---P1            P3--- UAS
        |------------|

Now, the UAC sends an INVITE, which is forked by P1. One INVITE goes via
P2 and P3, and the other INVITE via P3 only.

The P1-P2-P3 INVITE reaches the UAS first, and a 200 (including a
Contact header) is sent back. Then, the P1-P3 INVITE reaches the UAS,
and the UAS sends 482 back.

Now we come to the ACKs. If P3 inserted Record-Route for BOTH INVITEs,
will there be any difference in the Via headers of the two ACKs?

And, if the 482 was sent all the way back to P1, or the UAC, and BOTH P1
and P3 inserted Record-Route, won't we again get the same situation,
because the ACKs will use exactly the same route?

Someone said that this may not be a real-life case, but I don't agree on
that. And, isn't 3GPP talking about some kind of "inbound" proxy also?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 30 Oct 2001 16:55:26 +0200

Hello,

> Consider the following scenario:

Yes because P3 inserted a different branch in the Via header for each of
the two INVITEs that it forwarded to the UAS. That's how you can
distinguish the ACKs. The ACK for the non-2xx final response will have
the same branch as the previous INVITE and thus it will be absorved by
the server transaction. When the ACK for the 2xx final response arrives,
there is no server transaction that matches the ACK's top Via header
(line 2770 of bis-05 PDF version). Therefore, the ACK for the 2xx final
response will be handled by the Transaction User (in this case the UAS
core).

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Oct 2001 16:52:41 +0200

Hi,

>response will be handled by the Transaction User (in this case the UAS

True. Thanks!

It would, though, be good if the branch value in the ACK to the 200
could be the same as the branch in the INVITE, so that they could be
directly matched. It would also be more saft, since the UAS doesn't have
to ASSUME an ACK belongs to the INVITE/200 just because it can't find a
matching branch value...

Of course, that would require that the branch is generated in some other
way, and still is unique for each leg, than currently...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Oct 2001 17:02:53 +0200

Hi,

>>directly matched.
>The entity that generates the branch for the ACK does not have to be
>and typically is not) the same entity that generated the branch for the
>INVITE. That's why ACKs for 2xx responses are slightly different than
>ACKs for non-2xx final responses.

I know. So, one could argue that the branch parameter shouldn't even be
in the Via header - or another header/header value would be used for
this. It could be somewhere else, so that the UAC could pick it from the
200 response and use it in the ACK.

Regards,

Christer Holmberg
Ericsson Finland

> 
> Regards,
> 
> Gonzalo
> 
>  It would also be more saft, since the UAS doesn't have

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 30 Oct 2001 17:16:15 +0200

Hi,

The entity that generates the branch for the ACK does not have to be
(and typically is not) the same entity that generated the branch for the
INVITE. That's why ACKs for 2xx responses are slightly different than
ACKs for non-2xx final responses.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 12:53:06 +0200

Hi,

>200 response and use it in the ACK.

I wonder if we could define some kind of "branch-tag" for this (as a To
header parameter, for example), which the UAS could insert in the final
responses to the INVITEs - or at least in the 200 response. The UAC
could then copy it to the ACK request, and it would then be used by the
UAS to match the ACK to the INVITE which generated the 200.

Of course, the use of the tag would be optional, and if either party
doesn't support it the old mechanism would simply be used, ie assuming
that an ACK belongs to the INVITE which generated the 200 because the
Via branch value in the ACK doesn't match any value in the UAS.

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 31 Oct 2001 13:18:58 -0000

> stateless load balancer.

Uh.  Maybe there is nothing wrong with the "stateless
load balancer" (I don't know what its mandate is),
but it certainly represents no entity that I am aware
of in the spec, and thus will break the network if
the "proxy"s behind it are not aware that there is a
"stateless load balancer" serving them.

What I'm saying is that this load balancer cannot
exist on it's own as an entity in a SIP network --
it would have to have cooperating servers that would
legislate against retransmissions being distributed
arbitrarily.

> UAS responsds with 200 to #1 and 4xx to #2

This situation cannot happen if the network is
healthy.

> different view of the network topology and sends retransmissions through

I could imagine clever proxies and UAs being
able to recover this situation.  If not, the
caller will probably just retry.  If I pick up
the 'phone and attempt to make a call, and hear
some strange tone on the line that I don't
recognise, it's almost instinctive to just
"give it another go".

 - Jo.

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 31 Oct 2001 13:27:23 -0000

> Via branch value in the ACK doesn't match any value in the UAS.

Yes: I fail to see the point.  Since we have a well-defined,
working, mechanism for detecting the ACK for the 200, why
invent another way, which will not work in some cases?

 - Jo.

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 31 Oct 2001 13:43:35 -0000

> > > I wonder if we could define some kind of "branch-tag" for
> > > this (as a To header parameter, for example), which the UAS
> > > could insert in the final responses to the INVITEs - or at
> > > least in the 200 response. The UAC could then copy it to the
> > > ACK request, and it would then be used by the UAS to match
> > > the ACK to the INVITE which generated the 200.
> > >
> I want to point out that I am NOT talking about a normal 200/ACK
> matching, but the case where a forked INVITE gets merged in the UAS and
> the UAS sends multiple final responses (one 200 and multiple 482, for
> example). The Via branch value will be identical in the INVITEs and ACKs
> for the "482 legs", but not for the INVITE and ACK for the "200 leg".

I realize that; my assertion remains: we have
a working mechanism -- why augment it with an
additional, and unreliable, extension?

 - Jo.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 15:31:36 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Shan Lu" <[email-masked]>
Date: Wed, 31 Oct 2001 10:06:41 -0500

Hi,

I think the discussion on "load balancer" has been side tracked. My
original point (and I think you actually agreed) is that retransmissions
of the same INVITE can arrive at the same UAS through different paths.
According to the rules in section 13.3.1, line 1816, this would cause
the call to be terminated. That's all I wanted to point out. What is the
solution or whether it warrants a solution, I don't know.

Regards,

Shan Lu
sentitO Networks

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jo Hornsby
> Sent: Wednesday, October 31, 2001 8:19 AM

---

From: "A Venkatraman" <[email-masked]>
Date: Wed, 31 Oct 2001 09:30:21 -0600

It has been stipulated in the spec that when two merged requests arrive at a
UAS, the first one is processed and the second one is responded with a  482.

Now, if the first request that is processed elicits a response higher than
482 (eg. 486 Busy) then the forking proxy will return the best response of
482 to the UAC.

I support the suggestion of choosing a high response code, like 599.

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On Behalf Of
[email-masked]
Sent:	Monday, October 29, 2001 4:23 PM
To:	'Shan Lu'; 'Jo Hornsby'; [email-masked]
Subject:	RE: [Sip] Handling of duplicate requests with differing request
paths.

/a

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 31 Oct 2001 16:19:52 -0000

> I support the suggestion of choosing a high response code, like 599.

599 is in the wrong class.

I would note that this is a general problem: for
instance, 486 seems far more preferable to me
than 404.  Thus far, the notion of a "best"
response has always been a little random; however,
bis-05 seems to open things up nicely by allowing
a proxy to "select" a response from the lowest
class (step 5 of section 16.6).  This then becomes
a nonproblem.

 - Jo.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 19:57:21 +0200

Hi,

>additional, and unreliable, extension?

I don't know if it's more reliable to assume that the ACK belongs to a
specific INVITE just because you can't find a matching Via branch
value...

Anyway, I do think we have more important issues than this one, so we
don't have to argue about it :)

Regards,

Christer Holmberg
Ericsson Finland