SIP Register/Invite without SDP/XML

[bmgante]

Hi,

I´ve just noticed that for some SIP messages, the XML/SDP field is not available. Using latest versions of heplify-server + homer-app.

In the example below there are 2 registers, left side without XML and right side with XML. These 2 registers are indeed from the same transaction but between different network elements (left side is public part and right side is private).

Any idea on what could be the reason of such change?

Thanks

[lmangani]

This would suggest the message being malformed and somehow breaking the client-side parser

Check the browser console for errors, or you can try run the affected SIP message manually using runkit

var parsip = require("parsip")
console.log(parsip.getSIP(sip_message));

[bmgante]

Hi @lmangani Indeed seems that it only happens when sip port is 4060. Is there any configuration on homer-app or heplify-server for sip ports config?

[lmangani]

The message is captured, so I guess the configuration is right and this comes from a built-in HEP agent in a proxy or similar. The issue is with the content, the parsing tab you're referring to is client-side, performed by the UI, not any of the backend parts.

Try to paste the SIP message body in the link I shared and check if it gets parsed and/or what error it returns.

[bmgante]

when i export pcap from homer for a sip message with missing xml for example, we can see the following error on wireshark Indeed seems there´s some formatting issue. The message body it´s not here.

[lmangani]

Indeed, that's the root cause right there - since Wireshark agrees with our parser, this is just a badly formatted message header and HOMER seems right not to parse it. I guess the endpoints are more lenient about this aspect but its still a case malformation.

As you can also appreciate, we are storing this anyhow, allowing us to detect and troubleshoot the issue regardless.

[bmgante]

Does it mean that in postgres database, the full message body is there (even if not well formatted) and homer UI is just not able to parse it?

[lmangani]

HOMER doesn't parse like user-agents or servers. It's only purpose is to store the data for troubleshooting, good or bad and it does. The way we extract headers is resilient to this factor. The UI client-side parser (tab) only works on valid formatted messages - part of its role is to confirm they are, and if this was not the case, you wouldn't know this message malformed. If anything, we should add the error somewhere, just like in wireshark.

[bmgante]

The raw field on database has the following content:

"REGISTER sip:ims.xxx.net SIP/2.0 To: <sip:+xxx@ims.xxx.net> From: <sip:+xxx@ims.xxx.net>;tag=1VXWF9mFwz Expires: 600000 Require: sec-agree Proxy-Require: sec-agree Security-Client: ipsec-3gpp;alg=hmac-md5-96;ealg=aes-cbc;mod=trans;port-c=60565;port-s=52246;prot=esp;spi-c=250937743;spi-s=119347246,ipsec-3gpp;alg=hmac-md5-96;ealg=null;mod=trans;port-c=60565;port-s=52246;prot=esp;spi-c=250937743;spi-s=119347246,ipsec-3gpp;alg=hmac-sha-1-96;ealg=aes-cbc;mod=trans;port-c=60565;port-s=52246;prot=esp;spi-c=250937743;spi-s=119347246,ipsec-3gpp;alg=hmac-sha-1-96;ealg=null;mod=trans;port-c=60565;port-s=52246;prot=esp;spi-c=250937743;spi-s=119347246 Call-ID: n2QskiF8V3ScgWZdUVjMrpyd Session-ID: 837dfbb9d079c237c301b0e5b8616d79 Geolocation: <sip:+447408815496@ims.xxx.net> Geolocation-Routing: yes Contact: <sip:xxx@xxx:5060>;+g.3gpp.icsi-ref=""urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"";+g.3gpp.smsip;+sip.instance=""<urn:gsma:imei:35931006-378032-0>"" Authorization: Digest nonce="""",uri=""sip:ims.xxx.net"",realm=""ims.xxx.net"",username=""xxx@ims.xxx.net"",response="""" CSeq: 30 REGISTER Via: SIP/2.0/TCP 10.177.211.32:5060;branch=z9hG4bKs3VtaKVVCaScYap;rport "

[lmangani]

This printout is skipping the newlines so its not very helpful - anyhow we already know the root cause. No fix is needed here. Any other question?

[bmgante]

I guess this is due to sip udp fragmented messages which are not reassembled by horaclifix agent.