Subject: RE: [Sipping] Call transfer on a forked call

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Tue, 5 Dec 2006 23:58:21 -0500

I think you are talking about attended xfer which transfer target(s) are
still in alerting state. I think there is a RFC/draft which mentions
that it is not supported.

>-----Original Message-----
>From: Kapil Nayar [mailto:[email-masked]] 
>Sent: Tuesday, December 05, 2006 4:17 PM
>To: [email-masked]
>Subject: [Sipping] Call transfer on a forked call
>
>Hi
>
>Consider a scenario:
>1. Transferor initiates a new call towards the transfer 
>target. Transfer target replies with 302 but with multiple contacts.
>3. Transferor forks the call to the multiple contacts which 
>are alerted. Transferor completes the transfer at this point 
>through REFER message to transferee.
>
>Is it legal to:
>a. Include multiple "Refer To:" headers with replaces parameters.
>b. Expect the transferee to send individual Invite-w-replaces 
>to multiple contacts based upon each "Refer To:" header.
>c. Expect the transferee to terminate the call when one of the 
>transfer targets answers the call.
>d. Does the NOTIFY from transferee to transferor needs to 
>distinguish between the individual "Refer To:"
>sessions?
>
>Any pointers to drafts/ RFCs covering this scenario(s) would 
>be welcome.
>
>thanks,
>Kapil
>
>Send instant messages to your online friends 
>http://uk.messenger.yahoo.com 
>
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip 
>Use [email-masked] for new developments of core SIP
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Kapil Nayar <[email-masked]>
Date: Wed, 6 Dec 2006 17:41:21 +0000 (GMT)

Hi Sanjay

Are you referring to RFC 3515 - which disallows
multiple Refer-To headers in REFER and forking on
REFER sent within a dialog? Although, I don't
understand why the RFC restricts it.

Sometime back there was an IETF effort with respect to
supporting multiple Refer-To in REFER or rather doing
a single REFER for multiple targets. But, I don't see
any current active draft/ RFC in this regard.

The scenario that I describe is somewhat similar to an
attended xfer (alerting stage) on multiple targets
which I feel is very much valid. 
I am sure there must be a standard SIP procedure to do
this already - or else I can certainly propose one
here.

thanks,
Kapil

PS: Wondering if this should go to SIP mailing list. 

--- "Sanjay Sinha (sanjsinh)" <[email-masked]>
wrote:

> >Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Dec 2006 13:10:47 -0500

Kapil,

The confusion concerning the validity of your scenario corresponds to
how rfc3891 section 4 relates to your questions.  You might want to
clarify your message flow since it currently sounds like it might
violate the following MUST NOT.

RFC 3891 section 4 snippet:

"A UAC MUST NOT send an INVITE with a Replaces header field that
attempts to replace an early dialog which was not originated by the
target of the INVITE with a Replaces header field."

> Sent: Wednesday, December 06, 2006 12:41 PM
> To: Sanjay Sinha (sanjsinh); [email-masked]
> Subject: RE: [Sipping] Call transfer on a forked call
> 
> Hi Sanjay
> 
> Are you referring to RFC 3515 - which disallows multiple 
> Refer-To headers in REFER and forking on REFER sent within a 
> dialog? Although, I don't understand why the RFC restricts it.
> 
> supporting multiple Refer-To in REFER or rather doing a 
> single REFER for multiple targets. But, I don't see any 
> current active draft/ RFC in this regard.
> 
> attended xfer (alerting stage) on multiple targets which I 
> feel is very much valid. 
> I am sure there must be a standard SIP procedure to do this 
> already - or else I can certainly propose one here.
> 
> thanks,
> Kapil
> 
> > I think you are talking about attended xfer which transfer 
> target(s) 
> > are still in alerting state. I think there is a RFC/draft which 
> > mentions that it is not supported.
> >

---

From: Kapil Nayar <[email-masked]>
Date: Wed, 6 Dec 2006 23:54:11 +0000 (GMT)

Hi Brett

You are right in stating that the scenario violates
the existing RFCs, 3891 for one.
In fact, if I read the archives correctly, the earlier
drafts (draft-ietf-sip-replaces-02.txt)leading to RFC
3891 indeed allowed the target to replace the
early-dialog irrespective of the dialog initiation
(target could be UAC or UAS). The draft was reworded
in Mar'03 to limit this usage only on UACs - in order
to avoid the race conditions due to forking if the
target is a UAS.

In my view the RFC was finalized based on the present
day Use Cases. Probably, the authors did not have had
the compulsion to explore further Use Cases at that
time.
 
And, this is the reason for my seeking a clarification
at this time.

Thanks,
Kapil

--- Brett Tate <[email-masked]> wrote:

> multiple 
> > > >target. Transfer target replies with 302 but
> with
> > > multiple contacts.
> > > >are alerted. Transferor completes the transfer
> at
> > > this point
> > > >to multiple contacts based upon each "Refer
> To:"
> > > header.
> > > >c. Expect the transferee to terminate the call
> when
> > > one of the
> > > >d. Does the NOTIFY from transferee to
> transferor
> > > needs to

---

From: [email-masked]
Date: Wed, 6 Dec 2006 20:51:49 -0500

From: Kapil Nayar <[email-masked]>

   [...]. The draft was reworded in Mar'03 to limit this usage only on
   UACs - in order to avoid the race conditions due to forking if the
   target is a UAS.

   In my view the RFC was finalized based on the present day Use
   Cases. Probably, the authors did not have had the compulsion to
   explore further Use Cases at that time.

You have just explained that the RFC was finalized as it is in order
to avoid a race condition.  Exploring further user cases is not going
to make the race condition vanish.  You should perhaps explain
alternative methods of avoiding or dealing with the race condition.

Dale