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

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

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 8:58 AM
> To: Bob Penfield
> Cc: [email-masked]
> Subject: Re: [Sip] Handling of duplicate requests with 
> differing request
> paths.
> 
> 
> 
> Hi Bob,
> 
> >>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.
> > 
> >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.
> 
> 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...

I think bis-05 is quite clear that the tag in the 2xx and the tag in the 482
will NOT be the same. Section 8.2.7 specifies rules for generating the
response. It says that:

   However, if the To field in the request did not contain a tag, the URI in
the To field in 
   the response MUST equal the URI in the To field in the request.
Additionally, the UAS 
   MUST addatag to theTo field in the 1113
   response. This serves to identify the UAS that is responding, possibly
resulting in a 
   component of a dialog 1114
   ID. The same tag MUST be used for all responses to that request, both
provisional and 
   final. Procedures for 1115
   generation of tags are defined in Section 21.3. 1116

If you look at section 21.3, it says that tags are generated to be globally
unique. Since the two merged requests are DIFFERENT requests, for different
transactions, they will therefore each have globally unique, and therefore
different, tags in the responses.

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.

---
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: Christer Holmberg <[email-masked]>
Date: Tue, 06 Nov 2001 10:04:16 +0200

Hi,

>>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
>>generated the 200, instead of doing the decission based on Via branch values that
>>can't be matched...
>
>the To field in the response MUST equal the URI in the To field in the request.
>Additionally, the UAS MUST addatag to theTo field in the 1113
>resulting in a component of a dialog 1114 ID. The same tag MUST be used for all responses to that request, >both provisional and final. Procedures for 1115 generation of tags are defined in Section 21.3. 1116
> 

True. Great! :)
 
>core, not in the transaction layer (thus via, request uri are both

Good! So, the UAS will only need the Via branch value to find out that
the request was merged in the first place, but NOT to match the ACK to
the INVITE.

Regards,

Christer Holmberg
Ericsson Finland