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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 26 Oct 2001 04:58:18 -0700

Hi Christer,

Like a 200 OK? [which sets up two subscriptions or two active calls] Or a
183 Session Progress (with the resource reservation works) so that now you
have two audio ringback streams being sent to the same call.  Does ringing
on both dialegs mean that two phones are ringing(ie, two incoming call
indications) somewhere or you have two responses that says the same phone is
ringing.

No I don't think that is a good idea. It is the same request - it should be
responded to uniquely on one dialeg and the duplicate removed (IMO).

Jo is right. In bis-05 they did add text (which I missed) in 13.1.1 to
handle the INVITE case but the general request handling text still treats it
as a new request.

Robert.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 12:42 PM
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]
> Subject: Re: [Sip] Handling of duplicate requests with 
> differing request
> paths.
> 
> 
> 
> Hi,
> 
> Can't you just send whatever response you sent when you first received
> the request (via the other path)?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> > What is the "correct" response code for a UAS wishing to 
> reject a duplicate
> > request with differing via path? In other words, the 
> subsequent request
> > belongs to same SIP "dia-leg" [dialog/call-leg :)] and with 
> the same CSeq as
> > a previously received pending request but with different 
> topmost Via header
> > [ie, same To, From, Call-Id, CSeq & request-uri but 
> different topmost Via].
> > The SIP standard (bis-04 or bis-05) does not seem to 
> address this (that I
> > can find). This situation is simply treated as an 
> different/independent
> > request (which in my mind undesirable especially for subscriptions).
> > 
> > For instance, this would be the case where a proxy has 
> forked a INVITE or
> > SUBSCRIBE request and both requests have found their way to 
> the same UAS but
> > via different paths. The UAS will normally want to respond 
> to duplicate
> > requests with different paths with and error and simply 
> process the request
> > received initially. How about:
> > 
> > 482 Request Merged?
> > 
> > Regards,
> > 
> > Robert.
> > 
> > _______________________________________________
> > 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
> 

_______________________________________________
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 15:13:05 +0300

Hi,

What if some kind of Via hiding is used, so that the UAS doesn't see
that separate routes have been used? The only Via headers included may
be common for both routes.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Pekka Pessi <[email-masked]>
Date: 26 Oct 2001 16:09:20 +0300

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.

					Pekka

---

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

Hi

>In message <[email-masked]> Fairlie-Cuninghame, Robert ><[email-masked]> writes:

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