EARLY OFFER VS. LATE OFFER about sipsorcery HOT 8 CLOSED

Hi Ralf,

I've created a new branch acksdp which has a tiny change to show how I'd go
about setting the body on an ACK request. The other class that would most
likely need to be changed is ClientUserAgent but it depends how you were
thinking of triggering the SDP to be set on the ACK instead of the INVITE.
The two possibilities I can think of a re a flag in the CallDescriptor
class or a flag set on the ClientUserAgent constructor.

Regards,
Aaron

On Tue, Jun 28, 2016 at 2:43 AM, Ralf Jänike [email protected]
wrote:

As I'm understanding the code right now, i don't see a possibility for the
"Late" or "Delayed" offer scenario,
Early = SDP in INVITE
Late = INVITE without SDP, SDP in ACK

I'd like to discuss a way to implement it, without breaking the allready
working sipsorcery framework.

Ralf

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5, or mute the thread
https://github.com/notifications/unsubscribe/AAMEHPLCig3JGXzszKGMD3xZp3xcEmNNks5qP_2kgaJpZM4I_SM2
.

from sipsorcery.

Hi Aaron,

allthough setting the SDP in constructor is possible it is not practical for B2B scenario.
The ACK/SDP request for OK/SDP response should not be sent before the ACK/SDP from other party is received.
current (early offer) implementation
regular flow: INVITE/SDP -> trying -> ringing -> ok/SDP -> ACK
B2B regular flow: (a)INVITE/SDP -> (b)INVITE/SDP -> (b)trying -> (a)trying -> (b)ringing -> (a)ringing -> (b)ok/SDP -> (b)ACK -> (a)ok/SDP -> (a)ACK

late offer mplementation
late offer flow: INVITE -> trying -> ringing -> ok/SDP -> ACK/SDP
B2B late offer flow: (a)INVITE -> (b)INVITE -> (b)trying -> (a)trying -> (b)ringing -> (a)ringing -> (b)ok/SDP -> (a)ok/SDP -> (a)ACK/SDP -> (b)ACK/SDP

when i come to think of it, B2B flow should always be: ok -> ok -> ACK -> ACK

I propose a code change, that allows to change the automated ACK request in an eventhandler (or at least a public method to set the body for ACK) and that UACInviteTransactionFinalResponseReceived event is always called before ACK Request is generated and sent.

Ralf

from sipsorcery.

Hi Aaron

I committed my proposed code changes to branch acksdp in my fork.
They work for me and my purposes.

Can you review them?

Regards
Ralf

from sipsorcery.

Hi Ralf,

I've had a look at your changes. What's the purpose
of _waitSendNewTransactionACKRequest? And why do you want to hold off
sending the ACK request once the 200 Ok response has been received?

Regards,
Aaron

On Wed, Jun 29, 2016 at 3:41 AM, Ralf Jänike [email protected]
wrote:

Hi Aaron

I committed my proposed code changes to branch acksdp in my fork.
They work for me and my purposes.

Can you review them?

Regards
Ralf

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAMEHAIz_w3ASLfLSKIkOX0l_xZh6AfUks5qQVzTgaJpZM4I_SM2
.

from sipsorcery.

Hi Aaron,

I'm still working with Back2Back Scenario
i'm needing the _wait since I have to copy and manipulate the final SDP from ACK of client B to ACK for client A.
_wait isn't needed in a normal call flow where INVITE offers SDP and is accepted in OK. But in Late Offer SDP is offered in OK by the invitee (client B) and accepted in ACK by the inviter (client A)

Regards,
Ralf

from sipsorcery.

I've changed the UACInviteTransaction class to fit in with your B2B scenario, new change committed to my acksdp branch. Take a look and see if that suits your needs.

from sipsorcery.

Thank you Aaron,

this works for me, too.
i just added the sendOkAckManually parameter for convenience to SipTransport.CreateUACTransaction

Regards Ralf

from sipsorcery.

Merged changes for for this issue into master,

from sipsorcery.