Hi Vivek,
   Thanks for your response.

    Actually my scenario is attended call transfer using REFER method. So here 
I want to transfer an  attended call using  REFER method. But the  User agent B 
whom I want to send REFER request with the existing dialog information  does 
not having Support for replaces header. So in that case how does the User agent 
B will behave when it  will receive the REFER request which is having existing 
Dialog information in that Refer to header with replaces parameter?

Thanks

Sourav Dhar Chaudhuri


On Tuesday, 28 October 2014 5:23 PM, Vivek Batra <vivek.ba...@matrixcomsec.com> 
wrote:
 


Sourav,

Please check RFC3891;
This specification defines a new Require/Supported header option tag 
"replaces".  UAs which support the Replaces header MUST include the "replaces" 
option tag in a Supported header field.  UAs that want explicit failure 
notification if Replaces is not supported MAY include the "replaces" option in 
a Require header field.
About your question, both replaces and REFER can be implemented in different 
applications and together.
Replaces can be used without REFER during call pickup scenario where dialog 
information is passed to UA using subscribe/notify mechanism.
REFER can be used in blind transfer scenario where replaces header is not 
required.
Ps: Although you won't see a Replaces header inside a REFER message, REFER in 
context to Replaces header is involved in a replaces call flow which is 
actually carried by INVITE message.

Best Regards,
Vivek Batra




On Tue, Oct 28, 2014 at 4:35 PM, Sourav Dhar Chaudhuri 
<sourav_mi...@yahoo.co.in> wrote:

Hi,
>    Is this mandatory to have support for replaces parameter to support REFER 
> request?
>
>  Means If Supported: replaces is not present in the User Agent side . Then 
> that user will not support REFER request. The REFER request is containing 
> Replaces-to header having Replaces parameter. So in this case the Use Agent 
> will not support that REFER request?  is there any RFC reference.. I have not 
> got anything relevant in RFC 3515 for this.
>
>Thanks
>
>Sourav Dhar Chaudhuri
>_______________________________________________
>Sip-implementors mailing list
>Sip-implementors@lists.cs.columbia.edu
>https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to