> From: Adam Frankel (afrankel) [afran...@cisco.com]
>
> I am seeing a scenario for an established call in which an outbound
> reINVITE is being done, the far end is sending a TRYING and then a REFER
> immediately. We are rejecting this REFER with a 400 Bad Request because
> the INVITE transactio
Hi,
On Nov 24, 2011, at 2:48 AM, Brandon W. Yuille wrote:
> I thought he said the REFER was in response to his reINVITE, not the
> other way around:
>
> "I am seeing a scenario for an established call in which an outbound
> reINVITE is being done, the far end is sending a TRYING and then a REFE
I thought he said the REFER was in response to his reINVITE, not the
other way around:
"I am seeing a scenario for an established call in which an outbound
reINVITE is being done, the far end is sending a TRYING and then a REFER
immediately."
As I said before this seems to be wrong, especially s
Hi,
> Therefore, the UAS should not issue the REFER in the first place, but
> rather complete that re-INVITE, and when no INVITE/re-INVITE are in
> progress - send the REFER.
I'd say it's perfectly valid. Nobody forces you to generate an INVITE in
response to a REFER immediately. So I'd reply wi
On 11/23/2011 07:31 AM, Brez Borland wrote:
> On Tue, Nov 22, 2011 at 11:27 PM, Brez Borland wrote:
>
>> Hi Mark,
>>
>> I think that INVITE has to be answered. This is what "RFC3261, Section
>> 14.1 UAC Behavior" says:
>>
>> Note that a UAC MUST NOT initiate a new INVITE transaction within a
>
On Tue, Nov 22, 2011 at 11:27 PM, Brez Borland wrote:
> Hi Mark,
>
> I think that INVITE has to be answered. This is what "RFC3261, Section
> 14.1 UAC Behavior" says:
>
>Note that a UAC MUST NOT initiate a new INVITE transaction within a
>dialog while another INVITE transaction is in prog
Hi Mark,
I think that INVITE has to be answered. This is what "RFC3261, Section 14.1
UAC Behavior" says:
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in
either direction.
>From here I deduct that in Adam's case h
On 11/22/2011 03:42 AM, Brez Borland wrote:
> Hi Adam,
>
>
> On Tue, Nov 22, 2011 at 3:40 AM, Adam Frankel (afrankel)> wrote:
>> Hi All,
>>
>> I am seeing a scenario for an established call in which an outbound
>> reINVITE is being done, the far end is sending a TRYING and then a REFER
>> immediate
Hi Adam,
On Tue, Nov 22, 2011 at 3:40 AM, Adam Frankel (afrankel) wrote:
> Hi All,
>
> I am seeing a scenario for an established call in which an outbound
> reINVITE is being done, the far end is sending a TRYING and then a REFER
> immediately. We are rejecting this REFER with a 400 Bad Reques
On 11/22/11 11:40 AM, Adam Frankel (afrankel) wrote:
> Hi All,
>
> I am seeing a scenario for an established call in which an outbound
> reINVITE is being done, the far end is sending a TRYING and then a REFER
> immediately. We are rejecting this REFER with a 400 Bad Request because
> the INVITE t
That doesn't seem reasonable to me. That's like sending an initial
INVITE and receiving a CANCEL request in response instead of a final
response. Ie: you don't respond to a request with another request... If
you did I can see a scenario where the requests would never end.
Brandon
Adam Frankel
Hi All,
I am seeing a scenario for an established call in which an outbound
reINVITE is being done, the far end is sending a TRYING and then a REFER
immediately. We are rejecting this REFER with a 400 Bad Request because
the INVITE transaction has not been completed.
I am not clear whether RE
12 matches
Mail list logo
