Subject: Re: [Sip] Handling of duplicate requests with differing request paths.

From: Pekka Pessi <[email-masked]>
Date: 01 Nov 2001 17:09:50 +0200

In message <[email-masked]> Christer Holmberg <[email-masked]> writes:
>>I realize that; my assertion remains: we have
>>a working mechanism -- why augment it with an
>>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...

	You can have different tag value for those transactions that you
	respond with 482 than those that you answer with 200.  Of
	course, this does not solve merging problem for re-INVITEs (if
	is there such a problem).

						Pekka

_______________________________________________
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, 02 Nov 2001 08:10:49 +0200

Hi,

>respond with 482 than those that you answer with 200.

Yes, that is an option. Any comments on that?

>Of course, this does not solve merging problem for re-INVITEs (if

Will a re-INVITE be forked/merged, since we have an established route it
shall follow?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 2 Nov 2001 09:14:17 -0500

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: "Pekka Pessi" <[email-masked]>
Cc: "Jo Hornsby" <[email-masked]>; <[email-masked]>
Sent: Friday, November 02, 2001 1:10 AM
Subject: Re: [Sip] Handling of duplicate requests with differing request
paths.

> Will a re-INVITE be forked/merged, since we have an established route it

No, a re-INVITE is not forked. It is sent using Route headers or directly to
the Contact from the original 200(INVITE) response. It also has the tag in
the To header.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 03 Nov 2001 16:25:23 +0200

Hi,

So, would it cause any problems if the UAS DID use separate Tag values
for each final response it sends to a merget INVITE - or at least
separate Tag values for the 200 and 482 responses. In this case we
wouldn't have to add any new features to be able to match the
INVITE/200/ACK - without doing assumtions based on the Via branch value.
The caller would not even notice this, since the forking proxy would ACK
the 482 responses, and only the 200 would reach the UAC.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 5 Nov 2001 08:43:55 -0500

> the 482 responses, and only the 200 would reach the UAC.

Why would the UAS assign a tag at all? Does bis-05 require a tag? I would
think the response should look like any other 4xx response when there have
been no 1xx responses (no tag previously assigned). I think it would be a
mistake to use the same tag returned with the 200. By responding with 482,
we're trying to eliminate a dialog resulting from a fork at some proxy. This
is a separate dialog from the one that got a 200-OK.

cheers,
(-:bob

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 05 Nov 2001 15:57:32 +0200

Hi Bob,

>is a separate dialog from the one that got a 200-OK.

Assuming that there is not tag in the 482, OR if there is a separate tag
than in the 200 (I KNOW that is not how tags are supposed to be used, so
I am more than happy NOT having to change that), the issue is still if
we can rely on the tag to match the ACK to the INVITE that generated the
200, instead of doing the decission based on Via branch values that
can't be matched...

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland