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

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

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 26 Oct 2001 12:36:20 +0100

> What is the "correct" response code for a UAS wishing to reject a 
> duplicate request with differing via path?

482.

> 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).

It does seem to be alluded to in step 2 of Section 13.3.1 of
bis-05.  However, this only appears to be for INVITE requests,
which I'd imagine is a mistake.

> 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?

Sounds ideal.

 - Jo.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Oct 2001 14:41:34 +0300

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