Community

Page tree

Good afternoon;

I received purchased my first Snom, a D758, and immediately updated it to the latest firmware, v 10.1.101.11. I have discovered that when the phone is using the TLS transport it rejects all BYEs sent to it from the UAS. If the transport is UDP or TCP then everything works as expected.

When the D785 receives a BYE it will reject it with a 400 Bad Request, which of course, breaks the tear down of the call. The logged error (even at maximum DEBUG level) is only:

[ ERROR ] SIP: Bad Request: method and cseq operation mismatch

Is it possible this is a bug or am I missing something? My thanks for your time,

 – JP

An example of a BYE and the response:

BYE sip:2125551212@snom.client.com:39918;transport=Tls;line=116dwhwy SIP/2.0
Via: SIP/2.0/UDP sbc.server.com:5060;branch=z9hG4bKa6c4.b0b7e712.0
f: <sip:+19496611234@tlstesting.client.com>;tag=gK02d3c3c8
t: "Test" <sip:2125551212@tlstesting.client.com;transport=tls>;tag=v9o3uccff8
i: f1c1286282d1-45lrtxntx1v9
CSeq: 547490 BYE
Max-Forwards: 68
Route: <sip:proxy.server.com:5060;r2=on;lr;ftag=v9o3uccff8;nat=yes;edge=52f.eb410c13>
Route: <sip:proxy.server.com:5061;transport=tls;r2=on;lr;ftag=v9o3uccff8;nat=yes;edge=52f.eb410c13>
l: 0


SIP/2.0 400 Bad Request
Via: SIP/2.0/TLS proxy.server.com:5061;branch=z9hG4bKa6c4.1bf7e2a1.0
Via: SIP/2.0/UDP sbc.server.com:5060;rport=5060;received=sbc.server.com;branch=z9hG4bKa6c4.b0b7e712.0
From: <sip:+19496611234@tlstesting.client.com;user=phone>;tag=gK02d3c3c8
To: "Test" <sip:212555121@tlstesting.client.com;transport=tls>;tag=v9o3uccff8
Call-ID: f1c1286282d1-45lrtxntx1v9
CSeq: 547490 BYE
User-Agent: snomD785/10.1.101.11
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Content-Length: 0

profilePicture

JP Hindin

End user

Joined: 09.03.2022

3 Comments

  1. Snom Federico Rossi

    Hi, could you please post the entire SIP trace taken from the phone after a bad call?

    Thanks

  2. End user JP Hindin

    Please accept my apologies for the delay;


    I have discovered, after having nothing but '400 Bad Request' responses, and periodically '505 Version Not Supported' also, from the D785 for three days of testing, that I am now unable to replicate this issue... some considerable time investigating this today has identified that it appears the OpenSIPS I have been using to talk to the D785 has a bug in it (it's a slightly older release) relating to TCP segmentation of TLS packets. Or, possibly, libssl, but more likely it's OpenSIPS.

    OpenSIPS is sending TCP keep alives to keep the TCP connection up for the duration of the call. In my tests last week the keep alives were being encapsulated in the TLS stream (not intentionally) and each keep alive packet is being marked as a segment rather than a single, whole packet. When an actual SIP packet is transmitted, via TLS, it is marked as the final packet in the segmented series, which is getting reassembled into a single malformed packet. The D785 is apparently choking on this packet - hardly unreasonable. The long delay between when the initial packets are sent (INVITE, PRACK, 200 OK to INVITE, etc) and the BYE means there are many Keepalives in the segment series, where there are none prior to the earlier messages, so they are transmitted whole and unmolested. This produced a call that worked fine up until the BYE, which resulted in the 400 Bad Request from the D785.

    On some calls where the phone rang for a long period of time prior to being answered there would be a single keep alive packet sent resulting in a 200 OK that had the invalid leading nonsense. When this was sent to the D785 the phone responded with a 505 Version Not Supported. OpenSIPS would then promptly retransmit the 200 OK, which would come through whole as there was no time for a keep alive to have struck, and so the call appeared to be working as expected.

    Some changes were made to the configuration of the proxy last week which appears to have had the side effect of sending the TCP keep alives outside of the TLS stream and so the issue has vanished.


    Anyway, this is a long and detailed response to something that is, by all appearances, not the D785's fault at all, but on the off chance, some how, someone else runs into it some day, I wanted to provide what appears to be the explanation for this behaviour.

    Thank you for your willingness to help, either way, and have a fine week;

     - JP

  3. Snom Federico Rossi

    Hi, thanks for your detailed explanation, this is very useful information.