Paul Kyzivat writes:
> Note that you shouldn't be using page mode (MESSAGE) for IM *sessions*.
> It is really intended for occasional messages. If you are establishing a
> dialog (via INVITE) specifically for text messaging then you are abusing
> the mechanism.
>
> For IM *sessions* (text as we
On 9/14/16 12:00 PM, Harrison, Jason, Vodafone UK wrote:
Hi Dale and others who have responded,
Thanks for the response; the UPDATE does not contain any SDP as it is just for
a display update as the call is picked up on another phone
What do you mean by "display update"? Are you changing the
Hi Dale and others who have responded,
Thanks for the response; the UPDATE does not contain any SDP as it is just for
a display update as the call is picked up on another phone
As this behaviour is not covered by the RFCs we are between a rock and a hard
place, however I can get the customer PB
When looking at a race condition, it is always worth looking at RFC 5407
("Example Call Flows of Race Conditions in SIP", often abbreviated to
"Race Conditions in SIP" or even "Hasebe" in honor of the author). That
is the best collection of carefully analyzed race conditions.
I've added to your e
On 9/14/16 7:05 AM, Harrison, Jason, Vodafone UK wrote:
Hi,
I have an issue and I can't identify if the behaviour is wrong:
Here is a working call
Provider Customer
SBCSBC
INVITE (SDP offer)-->
<--100 Trying
<--180 Ringing (SDP answer)
PRACK -->
<-- 200OK (
> In the failed call I am being told by the provider
> that their SBC sent a BYE because the 200OK for the
> INVITE was received before it managed to send the
> 200OK for the UPDATE, I have checked the RFCs and
> can't find if the customer SBC is breaking any rules
> by sending an 200OK for the INV
Hi,
I have an issue and I can't identify if the behaviour is wrong:
Here is a working call
Provider Customer
SBCSBC
INVITE (SDP offer)-->
<--100 Trying
<--180 Ringing (SDP answer)
PRACK -->
<-- 200OK (PRACK)
<-- UPDATE
200OK UPDATE -->
<--200OK (INVITE)
ACK -
