RE: [Sipping] Call transfer on a forked call

[Kapil Nayar <[e-mail]>]

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 <[e-mail]> wrote:

> 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."
> 
> 
> > -----Original Message-----
> > From: Kapil Nayar [mailto:[e-mail]] 
> > Sent: Wednesday, December 06, 2006 12:41 PM
> > To: Sanjay Sinha (sanjsinh); [e-mail]
> > 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.
> > 
> > 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)" <[e-mail]>
> > wrote:
> > 
> > > 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:[e-mail]]
> > > >Sent: Tuesday, December 05, 2006 4:17 PM
> > > >To: [e-mail]
> > > >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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP