SIP packet flow during Call Setup (some questions)

Hi everyone, I am a student from IT course and having practical exercise at home.

From what I learned, the call setup is established as below:

S=Server
A —INVITE----> S
A <—TRYING— S ----INVITE—> B
S <–RINGING-- B
A <—RINGING-- S
S <----OK------ B
A <----OK------ S
A -----ACK----> S
S -----ACK—> B

A <---------------MEDIA STREAMS-------------> B

However, when I try the asterisk server with 2 computers and 1 virtual machine as asterisk server.
The establishment became like this
A —INVITE----> S
A <—TRYING— S ----INVITE—> B
S <–RINGING-- B
A <—RINGING-- S
S <----OK------ B
A <----OK------ S
A -----ACK----> S
S -----ACK—> B
[color=#BF0000]
A <—INVITE----- S —INVITE----> B
A -------OK------> S <-----OK------- B
A <-----ACK------- S ------ACK-----> B [/color]

A<---------------MEDIA STREAMS------------->B

So is it true that the server is trying to invite both user A and B into a call session during the red font traffic?

And also when the A hang up the call, something happened as below:

A ----BYE-----> S
[color=#BF0000]
S —INVITE—> B
S <-----OK----- B
S ----ACK-----> B
[/color]
S ----BYE-----> B
S <-----OK---- B
A <-----OK---- S

So I guess that it is because the server is already disconnected with the user B, it needs to reconnect with B before it can sends a SIP BYE to user B. Am I correct? Correct me if I am not.

These sequences are possible sequences, but they depend on the dialplan and the party B phone and have fixed the order of operations more strongly than the protocol requires.

The operation that is going on in your red text is described in the main SIP RFC. However, you seem to have overlooked some of the SDP. This depends on the setting of an option in sip.conf, so reading sip.conf.sample should give you a clue.

The server could issue the BYE without the second red sequence. Your example is a degenerate case.

Also, you haven’t understood the use of the term “server” in SIP and I think you may not have understood the two types of intermediate node. Asterisk is not the type described in most detail in the RFC.

[quote=“david55”]These sequences are possible sequences, but they depend on the dialplan and the party B phone and have fixed the order of operations more strongly than the protocol requires.

The operation that is going on in your red text is described in the main SIP RFC. However, you seem to have overlooked some of the SDP. This depends on the setting of an option in sip.conf, so reading sip.conf.sample should give you a clue.

The server could issue the BYE without the second red sequence. Your example is a degenerate case.[/quote]

I found out that the media formats in INVITE’s SDP are not same as the media formats in OK’s SDP before the red text, is this means that the both users were not agreed on the media stream initialization parameters, and that’s why the server need to act as middle man and send a same SIP INVITE to both users. Allowing both users to be agree on a same set of initialization paramenters. Correct me if I’m wrong.

You are wrong.

The SDP should differ, but the media formats need not.

I’ll also repeat that you have a degenerate example and Asterisk is doing things to anticipate more general cases (and, in part, because the special case code is broken!).

I’ll also repeat that this behaviour can be turned off.

[quote=“david55”]You are wrong.

The SDP should differ, but the media formats need not.

I’ll also repeat that you have a degenerate example and Asterisk is doing things to anticipate more general cases (and, in part, because the special case code is broken!).

I’ll also repeat that this behaviour can be turned off.[/quote]

It is because the asterisk tried to remove itself from the media path? I found out that if i set canreinvite=no. Then everything mapped to what I learned in lecture classes.

It actually succeeded, not just tried!

Now try and think of what you could do in the dialplan to achieve a similar effect.

Also have a look through some of my other hints as to why Asterisk is not like the classroom example.

[quote=“david55”]It actually succeeded, not just tried!

Now try and think of what you could do in the dialplan to achieve a similar effect.

Also have a look through some of my other hints as to why Asterisk is not like the classroom example.[/quote]

Got it, thank you david55. I hope that I can continue playing with the dialplan but time does not allow me to do so. It is already 3am and I have a class at 8am. Time to sleep. Anywhere, thank you very much.