Difference between revisions of "MOR does not send Contact header"

From Kolmisoft Wiki
Jump to navigationJump to search
(Created page with "= Problem Description= MOR does not include a Contact header in 180/183/200 OK SIP messages sent back to the originating device. The device drops the call immediately after the call was answered. == Possible reasons == This can happen if the ACK message from the client for MOR 401 Unauthorized from MOR reaches '''after second''' Invite. File:ack_after_invite.png<br> As can be seen in the image, packets arrived in MOR out of the order, the second Invite reached MOR...")
 
 
(3 intermediate revisions by the same user not shown)
Line 4: Line 4:


== Possible reasons ==
== Possible reasons ==
This can happen if the ACK message from the client for MOR 401 Unauthorized from MOR reaches '''after second''' Invite.
This can happen if the ACK message from the client for MOR 401 Unauthorized reaches MOR '''after second''' Invite.


[[File:ack_after_invite.png]]<br>
[[File:Ack_after_invite.png]]<br>


As can be seen in the image, packets arrived in MOR out of the order, the second Invite reached MOR before the ACK.
As can be seen in the image, packets arrived in MOR out of the order, the second Invite reached MOR before the ACK.
Line 19: Line 19:
With only needed codecs in INVITE, packets will be smaller and not fragmented, and this should prevent the IP stack from reordering them.
With only needed codecs in INVITE, packets will be smaller and not fragmented, and this should prevent the IP stack from reordering them.


[[File:ack_before_invite.png]]<br>
[[File:Ack_before_invite.png]]<br>


== Note about Wireshark and GUI pcaps ==
== Note about Wireshark and GUI pcaps ==


If packets are fragmented, PCAPS in GUI will not show such packets at all.
If packets are fragmented, PCAPS in GUI will not show such packets at all.
To see such packets, raw pcap must be downloaded and option Wireshark option '''Reassemble fragmented IPv4 datagrams''' disabled in Edit->Preferences->Protocls->IPv4 before doing any filtering on a raw pcap.
To see such packets, raw pcap must be downloaded and Wireshark option '''Reassemble fragmented IPv4 datagrams''' must be '''disabled''' (not checked) in Edit->Preferences->Protocls->IPv4 before doing any filtering on a raw pcap.


[[File:wireshark_reassemble.png]]<br>
[[File:Wireshark_reassemble.png]]<br>

Latest revision as of 09:04, 8 June 2022

Problem Description

MOR does not include a Contact header in 180/183/200 OK SIP messages sent back to the originating device. The device drops the call immediately after the call was answered.

Possible reasons

This can happen if the ACK message from the client for MOR 401 Unauthorized reaches MOR after second Invite.

Ack after invite.png

As can be seen in the image, packets arrived in MOR out of the order, the second Invite reached MOR before the ACK. This can happen if the INVITE packet is too big and is fragmented by the IP stack.

Possible solutions

As mentioned, the INVITE packet can be fragmented by the IP stack if it is too big. INVITE packet is usually too big when there are a lot of codecs in SDP, so one solution to make sure that packet is not fragmented is to ask the client to send only codes which are actually needed. For example, if in MOR Device settings, only G729 and G711 codecs are enabled, the client should send only these codecs, as all others will not be used by MOR in any case.

With only needed codecs in INVITE, packets will be smaller and not fragmented, and this should prevent the IP stack from reordering them.

Ack before invite.png

Note about Wireshark and GUI pcaps

If packets are fragmented, PCAPS in GUI will not show such packets at all. To see such packets, raw pcap must be downloaded and Wireshark option Reassemble fragmented IPv4 datagrams must be disabled (not checked) in Edit->Preferences->Protocls->IPv4 before doing any filtering on a raw pcap.

Wireshark reassemble.png