Amarnath,
Take a look at RFC6337 for an in-depth treatment of offer/answer issues
and best practices. More below, consistent with what is in that rfc.
On 12/19/18 12:28 AM, Amarnath Kanchivanam wrote:
Hi,
I have below call flow and would like to know the correct behavior.
UAC
> There are a lot of good reasons of not using STUN but there are no good
> reasons of not using STUN for UDP keep-alive. STUN keep-alive is extremely
> easy to implement. It is possible to verify packet validity and it can be
> used to detect local IP change.
Do you know any implementation
You can find an example for Call Hold in RFC5359 chapter 2.1.
To take a call off hold the UA has to send a message with attribute
a=sendrecv. In message F16 this attribute is omitted, so the default
value of sendrecv is assumed (RFC4566 chapter 6).
If the offer contains a=recvonly, as in your
Thanks All for your response.
I did try to send Ack with "sendrecv" attribute, but still it doesn't work.
Do we have any RFC describing call flow for various scenarios?
Regards,
Amarnath
On Wed, Dec 19, 2018 at 2:08 PM Olle E. Johansson wrote:
>
>
> > On 19 Dec 2018, at 09:28, Richard
> On 19 Dec 2018, at 09:28, Richard Phernambucq
> wrote:
>
> Hi Amarnath,
>
> A Re-Invite without SDP is called a late offer and isn't the same as resuming
> a call that was placed on hold.
>
> If 'UAS' wanted to resume the call it should have sent an SDP body with
> sendrecv attribute.
I
Hi Amarnath,
A Re-Invite without SDP is called a late offer and isn't the same as
resuming a call that was placed on hold.
If 'UAS' wanted to resume the call it should have sent an SDP body with
sendrecv attribute.
Best regards,
Richard
On 19-12-2018 06:28, Amarnath Kanchivanam wrote:
