"v=0" displayed as "76 3D 30"

[solarmon]

Tested on Homer 7.10.18

When clicking the INVITE method on the results display, it shows the "v=0" line on the SDP packet as "76 3D 30". But clicking on the INVITE when in the Flow view, it correctly shows it as "v=0".

This display issue also seem to occur for 200 OK with SDP, but not for 180 or 183 with SDP.

[lmangani]

@solarmon I cannot replicate this. Could you provide an example? For context, could you also specify what is the HEP agent sending those messages?

[solarmon]

@lmangani

We are using opensips 2.4.x with the proto_hep module.

Please see an example of the issue:

I hope that helps.

[adubovikov]

ha, can you please check what do you have in the DB ? I guess this is how the data has been delivered and stored into this field because 76 3D 30 "v=0" in HEX

[solarmon]

If you mean to check the raw data in the SIP tab of the message, yes, it does appear as "76 3D 30".

However, when I view the same INVITE when in the Flow view display, I see it as "v=0", and the raw data shows it as "v=0" too.

[adubovikov]

@solarmon I mean to check the data in pgsql :-)

select * from hep_proto_1_call where callid='blabla'

[solarmon]

Sorry, I don't know how to check for that yet. This setup is part of the https://github.com/sipcapture/homer7-docker build and has its own db docker image.

I'm able to exec in to the docker image bash console, but I can't find the pqsql command.

[lmangani]

@solarmon postgres is in a separate container

[solarmon]

@lmangani

Yes, it is in the db docker container. I figured out that I needed to use the psql command. Also, there is no such callid column in the from hep_proto_1_call table, but it is the sid column that has the session ID of the call.

The 'raw' data column has:

v=0\r

in the SDP content, not the hex code.

[adubovikov]

can you paste all sdp body ?

[solarmon]

@adubovikov

I've sanitised the SDP content in the raw field with <REMOVED>:

\r                                                  
v=0\r                                               
o=<REMOVED> 11511 11511 IN IP4 <REMOVED>\r
s=-\r                                               
c=IN IP4 <REMOVED>\r                            
t=0 0\r                                             
m=audio 16388 RTP/AVP 8 0 101\r                     
a=rtpmap:8 PCMA/8000\r                              
a=ptime:30\r                                        
a=rtpmap:0 PCMU/8000\r                              
a=ptime:30\r                                        
a=rtpmap:101 telephone-event/8000\r                 
a=fmtp:101 0-15\r                                   
a=ptime:30\r   

[solarmon]

I can confirm that this raw SDP from the INVITE that is for the packet with ID 9199847, as per the screenshot above.

[lmangani]

Could you export the full SIP message? We cannot reproduce this issue so far.

[lmangani]

@solarmon could you confirm if this happens for ALL of your users, or just for your sessions?

[AlexeyOplachko]

Can you please find and paste here message which has this issue in response from backend? Press F12, follow tutorial on screenshot, After you find correct message Don't forget to edit out all privacy details from it.

[solarmon]

Hi,

I'm not sure whether this is the correct information you are looking for - I'm using Chrome, and the DevTools doesn't look like in your example.

"v=0" doesn't appear, since it is "76 3D 30" that appears.

This is in the "raw" header and appears as

Max-Forwards: 70\r\n\r\n76 3D 30\no=

However, what I have noticed is that, for the INVITE method when viewed in the display results page, part of the SDP body text appears inside the text block that is meant to be for the last header. This doesn't seem correct?

The rest of text for the SDP body appears in the next span block for when m=audio starts.

Although, in the correct INVITE display from flow view page, it is doing the same thing, but with the correct "v=0" text.

[solarmon]

Oh, and I can confirm this issue occurs for two different logins.

Also, just to be clear - this display issue only occurs when I view the INVITE when I click on it in the results display. This display issue does not occur when viewing the INVITE when I click on it in the flow view display.

[adubovikov]

so, you understand that your SDP is broken - you should have \r\n and not \r - looks like golang string conversion detect \ro as a HEX symbol and don't convert the line to ASCII and left it as HEX

[solarmon]

@adubovikov

Yes, you are correct - it. looks like "\n" only appears after "v=0". The rest of the SDP packet does have "\r\n". I will get our developers to investigate further.

Why is it displayed correctly when view in the flow view display? The raw text for that indicates that "\r\n" does appear after "v=0":

Max-Forwards: 70\r\n\r\nv=0\r\no=

[solarmon]

@adubovikov

I've just done a packet capture using sngrep and viewed it in notepad++ to show all characters/symbols, and it does suggest that both carriage return and line feed characters are present and correct:

With sngrep, I know that it will not display the packet if the packet is invalid in anyway - so I'm confident that the INVITE and SDP packets are correctly formatted.

[adubovikov]

ok, let me check on back end

[solarmon]

@adubovikov

Not sure if this makes a difference, but the INVITEs from a particular source has this specific display issue - when the Content-Length and Content-Type headers do not appear right at the end of the list of headers.

As you can see from the example above, we have Max-Forwards as the last header.

[adubovikov]

i am checking right now...

[adubovikov]

@solarmon can you please check if your message has string "/isup" inside ?

[solarmon]

@adubovikov

Yes, the INVITE has the following header:

Accept: application/isup

[adubovikov]

ok, this is the issue - let me fix it

[adubovikov]

@solarmon please take homer-app-1.4.35-amd64 and test it

[solarmon]

@adubovikov

I don't know how to check for the individual docker containers version, but I did a docker-compose pull and docker-compose up -d and it updated all the docker containers. (I could have probably just done it on the homer-webapp container).

The Homer web GUI tab shows that it is version 7.10.18 - and I can see the display issue seems to have been resolved! Thank you!

Could you explain what the issue was. How was it related to the the Accept: application/isup header?

[adubovikov]

Glad that it works now. it was SIP-I checks and decoding binary data of SDP body