On 10/30/14 5:23 PM, Dale R. Worley wrote:
From: Paul Kyzivat
I disagree here. UA B would be irresponsible if it created an INVITE
including a header field that it doesn't understand.
Why would it be irresponsible?
It's not UA B that's deciding to produce the INVITE, it's the element
that
> From: Paul Kyzivat
> I disagree here. UA B would be irresponsible if it created an INVITE
> including a header field that it doesn't understand.
Why would it be irresponsible?
It's not UA B that's deciding to produce the INVITE, it's the element
that sends the REFER to UA B that is deciding
On 10/28/14 11:54 AM, Dale R. Worley wrote:
From: Sourav Dhar Chaudhuri
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 existi
> From: Sourav Dhar Chaudhuri
>
> 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
Sourav,
As Brett has mentioned previously and in your case, user agent B doesn't
need to support replaces. Here I assume user agent B still supports
Refer-To and hence can generate INVITE message. Further, transfer target
must support replaces (received inside INVITE) to successfully get
transferr
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
> Is this mandatory to have support for replaces parameter to support
> REFER request?
No; RFC 3515 does not madate support for Replaces. And RFC 3861 section 2
indicates the following.
"Although the Replaces header is
frequently used in combination with the REFER [8] method as used in a
hi Sourav,
As far i mine understanding , Refer with replaces is not a mandatory.
Regards
Abhishek
On Tue, Oct 28, 2014 at 5:25 PM, Vikas Dhiman
wrote:
> Hi Sourav,
>
> Are you talking about Replace-to or Refer-To?
>
> In Refer-To replaces is not a mandatory parameter.
>
> Cheers,
> Vikas
>
> On
Hi Sourav,
Are you talking about Replace-to or Refer-To?
In Refer-To replaces is not a mandatory parameter.
Cheers,
Vikas
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
>
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 suppor
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 th
11 matches
Mail list logo
