Difference between revisions of "MOR does not send Contact header"
(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 | This can happen if the ACK message from the client for MOR 401 Unauthorized reaches MOR '''after second''' Invite. | ||
[[File: | [[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: | [[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 | 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: | [[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.
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.
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.
