Hold error when trying to transfer incoming call; transfer of outgoing call works

Asterisk Asterisk SIP
1

I’m making some progress in setting up my little Asterisk installation with pjsip.

Internal and external, incoming and outgoing calls work, even with TLS encryption enabled. :blush:

At the moment, I’m stuck at one problem:

I use a desk phone (Bintec IP630). If I make a call using the desk phone, I can transfer the active call (attended transfer) to a colleague’s phone using the transfer key on the phone (no manual #1/*2 input). Works like a charm. But if someone calls the desk phone and I pick up the call, I cannot transfer it to someone else. If I press the transfer key of the desk phone, the call is terminated immediately. It seems that the attempt to put the call on hold immediately cancels the call.

I also tried the Snom D385. The behavior different with this phone: It says “hold error” and that the call was just “muted”. But then I can transfer the call. The D385 also has a Hold key. If I press that, it says the same error message and mutes the call. If I try to get the call back instead of redirecting, a 488 error is show shortly.

Do you have some ideas what I could try or look for?

I have tT as Dial parameters and the endpoints (234 and 235) have allow_transfer=yes.

Thank you very much in advance!

3

Excerpt from the console output:

[2024-02-04 08:32:49.137]     -- PJSIP/234-00000003 answered PJSIP/mytrunk-00000002
[2024-02-04 08:32:49.138]  Unsupported crypto suite: AEAD_AES_256_GCM
[2024-02-04 08:32:49.138]  Unsupported crypto suite: AEAD_AES_256_GCM_8
[2024-02-04 08:32:49.138]  Unsupported crypto suite: AES_256_CM_HMAC_SHA1_80
[2024-02-04 08:32:49.138]  Unsupported crypto suite: AEAD_AES_128_GCM
[2024-02-04 08:32:49.138]  Unsupported crypto suite: AEAD_AES_128_GCM_8
[2024-02-04 08:32:49.139]        > 0x7fc8f42cfcb0 -- Strict RTP learning after remote address set to: 212.??.??.??:49202
[2024-02-04 08:32:49.140]     -- Channel PJSIP/234-00000003 joined 'simple_bridge' basic-bridge <b8ef4921-f57d-42a5-aef7-bc807a9bdc27>
[2024-02-04 08:32:49.141]     -- Channel PJSIP/mytrunk-00000002 joined 'simple_bridge' basic-bridge <b8ef4921-f57d-42a5-aef7-bc807a9bdc27>
[2024-02-04 08:32:49.512]        > 0x7fc8f435cff0 -- Strict RTP switching to RTP target address 10.25.12.14:8024 as source
[2024-02-04 08:32:49.532]        > 0x7fc8f42cfcb0 -- Strict RTP switching to RTP target address 212.??.??.??:49202 as source
[2024-02-04 08:32:51.401]     -- Started music on hold, class 'default', on channel 'PJSIP/mytrunk-00000002'
[2024-02-04 08:32:51.427]     -- Channel PJSIP/234-00000003 left 'simple_bridge' basic-bridge <b8ef4921-f57d-42a5-aef7-bc807a9bdc27>
[2024-02-04 08:32:51.428]     -- Channel PJSIP/mytrunk-00000002 left 'simple_bridge' basic-bridge <b8ef4921-f57d-42a5-aef7-bc807a9bdc27>
[2024-02-04 08:32:51.428]     -- Stopped music on hold on PJSIP/mytrunk-00000002
[2024-02-04 08:32:51.429]   == Spawn extension (mytrunk, 491000000234, 1) exited non-zero on 'PJSIP/mytrunk-00000002'

I thought it might be related to g722 wideband (allow g722,alaw,ulaw). So I set all endpoints to alaw only. But that didn’t change anything. Might the “simple bridge” be the problem?

I guess the “Unsupported crypto suite” messages are not related to the issue. I see them all the time in normal operations even when everything works. I haven’t set “cipher” to a custom value. So there should be some negotiation going on.

4

If I add more -v... to the command line, it shows an additional hint when I try to redirect the call / put it on hold:

[2024-02-05 00:06:01.399]     -- Started music on hold, class 'default', on channel 'PJSIP/mytrunk-00000000'
[2024-02-05 00:06:01.402]   == SRTCP unprotect failed on SSRC 1360689666 because of unsupported parameter
[2024-02-05 00:06:01.426]     -- Channel PJSIP/234-00000001 left 'simple_bridge' basic-bridge <39cd46fd-da66-4841-b376-2c42d2c08dd3>
[2024-02-05 00:06:01.426]     -- Channel PJSIP/mytrunk-00000000 left 'simple_bridge' basic-bridge <39cd46fd-da66-4841-b376-2c42d2c08dd3>
[2024-02-05 00:06:01.428]     -- Stopped music on hold on PJSIP/mytrunk-00000000
[2024-02-05 00:06:01.429]   == Spawn extension (mytrunk, 4910000000234, 1) exited non-zero on 'PJSIP/mytrunk-00000000'

This one:

SRTCP unprotect failed on SSRC 1360689666 because of unsupported parameter

The phone is Bintec IP 630 with the latest firmware available. But it doesn’t really work with the SNOM as well.

I have direct_media=no and media_encryption=sdes for all endpoints, including the trunk. As per their setup guide for encrypted SIP trunking.

5

This is what happens when I press the “transfer call”/Hold button on the phone from the SIP messages perspective, until the call is terminated:

[2024-02-05 00:24:50.353] <--- Received SIP request (1200 bytes) from TLS:10.25.12.14:52057 --->
[2024-02-05 00:24:50.353] INVITE sips:0100000000@10.24.12.58:5061;transport=TLS SIP/2.0
[2024-02-05 00:24:50.353] Via: SIP/2.0/TLS 10.25.12.14:52057;rport;branch=z9hG4bKPjf247e4b4-c462-47c1-929f-9448423951c5;alias
[2024-02-05 00:24:50.353] Max-Forwards: 70
[2024-02-05 00:24:50.353] From: <sips:234@10.25.12.14>;tag=1eeefad2-d4c3-4453-9687-823549430280
[2024-02-05 00:24:50.353] To: <sip:012345678901@10.24.12.58>;tag=c39995b5-df11-42bd-9f04-e84e0dbc0fd4
[2024-02-05 00:24:50.353] Contact: <sips:234@10.25.12.14:5061;transport=tls>
[2024-02-05 00:24:50.353] Call-ID: 331bfab4-44b5-4625-a33b-33b5d72cb5da
[2024-02-05 00:24:50.353] CSeq: 32611 INVITE
[2024-02-05 00:24:50.353] Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, OPTIONS, PRACK, REFER, MESSAGE
[2024-02-05 00:24:50.353] Supported: 100rel, replaces, timer, eventlist
[2024-02-05 00:24:50.353] Session-Expires: 1800;refresher=uas
[2024-02-05 00:24:50.353] Min-SE: 90
[2024-02-05 00:24:50.353] User-Agent: elmeg IP630/82.3.19.1-release;589EC66BDF2D
[2024-02-05 00:24:50.353] Allow-Events: hold,talk
[2024-02-05 00:24:50.353] Content-Type: application/sdp
[2024-02-05 00:24:50.353] Content-Length:   419
[2024-02-05 00:24:50.353]
[2024-02-05 00:24:50.353] v=0
[2024-02-05 00:24:50.353] o=- 3916077851 3916077853 IN IP4 10.25.12.14
[2024-02-05 00:24:50.353] s=elmeg IP630/82.3.19.1-release;589EC66BDF2D
[2024-02-05 00:24:50.353] t=0 0
[2024-02-05 00:24:50.353] m=audio 8046 RTP/SAVP 9 8 0 101
[2024-02-05 00:24:50.354] c=IN IP4 10.25.12.14
[2024-02-05 00:24:50.354] b=TIAS:64000
[2024-02-05 00:24:50.354] a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3jAXcQNdabSJSWB/kRGbATfPEa/jHIAD9fPJQihH
[2024-02-05 00:24:50.354] a=rtcp:8047 IN IP4 10.25.12.14
[2024-02-05 00:24:50.354] a=rtpmap:9 G722/8000
[2024-02-05 00:24:50.354] a=rtpmap:8 PCMA/8000
[2024-02-05 00:24:50.354] a=rtpmap:0 PCMU/8000
[2024-02-05 00:24:50.354] a=rtpmap:101 telephone-event/8000
[2024-02-05 00:24:50.354] a=fmtp:101 0-16
[2024-02-05 00:24:50.354] a=sendonly
[2024-02-05 00:24:50.354]
[2024-02-05 00:24:50.355] <--- Transmitting SIP response (1064 bytes) to TLS:10.25.12.14:52057 --->
[2024-02-05 00:24:50.355] SIP/2.0 200 OK
[2024-02-05 00:24:50.355] Via: SIP/2.0/TLS 10.25.12.14:52057;rport=52057;received=10.25.12.14;branch=z9hG4bKPjf247e4b4-c462-47c1-929f-9448423951c5;alias
[2024-02-05 00:24:50.355] Call-ID: 331bfab4-44b5-4625-a33b-33b5d72cb5da
[2024-02-05 00:24:50.355] From: <sips:234@10.25.12.14>;tag=1eeefad2-d4c3-4453-9687-823549430280
[2024-02-05 00:24:50.355] To: <sip:012345678901@10.24.12.58>;tag=c39995b5-df11-42bd-9f04-e84e0dbc0fd4
[2024-02-05 00:24:50.355] CSeq: 32611 INVITE
[2024-02-05 00:24:50.355] Session-Expires: 1800;refresher=uas
[2024-02-05 00:24:50.356] Contact: <sip:0100000000@10.24.12.58:5061;transport=TLS>
[2024-02-05 00:24:50.356] Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, INFO, REFER
[2024-02-05 00:24:50.356] Supported: 100rel, timer, replaces, norefersub
[2024-02-05 00:24:50.356] Server: Asterisk PBX
[2024-02-05 00:24:50.356] Content-Type: application/sdp
[2024-02-05 00:24:50.356] Content-Length:   366
[2024-02-05 00:24:50.356]
[2024-02-05 00:24:50.356] v=0
[2024-02-05 00:24:50.356] o=- 511053411 511053412 IN IP4 10.24.12.58
[2024-02-05 00:24:50.356] s=Asterisk
[2024-02-05 00:24:50.356] c=IN IP4 10.24.12.58
[2024-02-05 00:24:50.357] t=0 0
[2024-02-05 00:24:50.357] m=audio 15248 RTP/SAVP 9 8 0 101
[2024-02-05 00:24:50.357] a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:YTvDRwsfUxy9tljBWO2EHacLr+23NowN1G+gzMK2
[2024-02-05 00:24:50.357] a=rtpmap:9 G722/8000
[2024-02-05 00:24:50.357] a=rtpmap:8 PCMA/8000
[2024-02-05 00:24:50.357] a=rtpmap:0 PCMU/8000
[2024-02-05 00:24:50.357] a=rtpmap:101 telephone-event/8000
[2024-02-05 00:24:50.357] a=fmtp:101 0-16
[2024-02-05 00:24:50.357] a=ptime:20
[2024-02-05 00:24:50.357] a=maxptime:140
[2024-02-05 00:24:50.357] a=recvonly
[2024-02-05 00:24:50.358]
[2024-02-05 00:24:50.358]     -- Started music on hold, class 'default', on channel 'PJSIP/mytrunk-00000002'
[2024-02-05 00:24:50.393] <--- Received SIP request (449 bytes) from TLS:10.25.12.14:52057 --->
[2024-02-05 00:24:50.393] BYE sip:0100000000@10.24.12.58:5061;transport=TLS SIP/2.0
[2024-02-05 00:24:50.394] Via: SIP/2.0/TLS 10.25.12.14:52057;rport;branch=z9hG4bKPj98d61745-61c7-4bfe-a62a-375b7b9ed121;alias
[2024-02-05 00:24:50.394] Max-Forwards: 70
[2024-02-05 00:24:50.394] From: <sips:234@10.25.12.14>;tag=1eeefad2-d4c3-4453-9687-823549430280
[2024-02-05 00:24:50.394] To: <sip:012345678901@10.24.12.58>;tag=c39995b5-df11-42bd-9f04-e84e0dbc0fd4
[2024-02-05 00:24:50.394] Call-ID: 331bfab4-44b5-4625-a33b-33b5d72cb5da
[2024-02-05 00:24:50.395] CSeq: 32612 BYE
[2024-02-05 00:24:50.395] Warning: 381 max3b "SIPS Required"
[2024-02-05 00:24:50.395] Content-Length:  0
[2024-02-05 00:24:50.395]
[2024-02-05 00:24:50.395]
[2024-02-05 00:24:50.395] <--- Transmitting SIP response (400 bytes) to TLS:10.25.12.14:52057 --->
[2024-02-05 00:24:50.396] SIP/2.0 200 OK
[2024-02-05 00:24:50.396] Via: SIP/2.0/TLS 10.25.12.14:52057;rport=52057;received=10.25.12.14;branch=z9hG4bKPj98d61745-61c7-4bfe-a62a-375b7b9ed121;alias
[2024-02-05 00:24:50.396] Call-ID: 331bfab4-44b5-4625-a33b-33b5d72cb5da
[2024-02-05 00:24:50.396] From: <sips:234@10.25.12.14>;tag=1eeefad2-d4c3-4453-9687-823549430280
[2024-02-05 00:24:50.396] To: <sip:012345678901@10.24.12.58>;tag=c39995b5-df11-42bd-9f04-e84e0dbc0fd4
[2024-02-05 00:24:50.396] CSeq: 32612 BYE
[2024-02-05 00:24:50.396] Server: Asterisk PBX
[2024-02-05 00:24:50.396] Content-Length:  0
[2024-02-05 00:24:50.397]
[2024-02-05 00:24:50.397]
[2024-02-05 00:24:50.397]     -- Channel PJSIP/234-00000003 left 'simple_bridge' basic-bridge <17df271c-5bcc-4b89-8a65-802e7bad0661>
[2024-02-05 00:24:50.397]     -- Channel PJSIP/mytrunk-00000002 left 'simple_bridge' basic-bridge <17df271c-5bcc-4b89-8a65-802e7bad0661>
[2024-02-05 00:24:50.398]     -- Stopped music on hold on PJSIP/mytrunk-00000002
[2024-02-05 00:24:50.398]   == Spawn extension (mytrunk, 4910000000234, 1) exited non-zero on 'PJSIP/mytrunk-00000002'

Any ideas about

Warning: 381 max3b "SIPS Required"

in the phone’s message?

It seems the phone (10.25.12.14) says BYE, maybe because it didn’t like Asterisk’s (10.24.12.58) response? Everything wents on so quick that I cannot hear any music on hold before the hangup.

In the traces, 012345678901 is the national number of an external caller whose call I tried to redirect to a colleague’s phone.

6

This “Warning” led me to RFC 5630, chapter 4.1:

This specification mandates that when a proxy is forwarding a request, a resource described by a SIPS Request-URI cannot be “downgraded” to a SIP URI by changing the scheme, or by sending the associated request over a nonsecure link. If a request needs to be rejected because otherwise it would be a “downgrade”, the request would be rejected with a 480 (Temporarily Unavailable) response (potentially with a Warning header with warn-code 380 “SIPS Not Allowed”). Similarly, this specification mandates that when a proxy is forwarding a request, a resource described by a SIP Request-URI cannot be “upgraded” to a SIPS URI by changing the scheme (otherwise it would be an “upgrade” only for that hop onwards rather than on all hops, and would therefore mislead the UAS). If a request needs to be rejected because otherwise it would be a misleading “upgrade”, the request would be rejected with a 480 (Temporarily Unavailable) response (potentially with a Warning header field with warn-code 381 “SIPS Required”). See Section 5.3 for more details.

(Emphasis is mine.)
But what can I do about that?

7

The reasons given in the RFC would be things that would have to be fixed in the proxy, but there is no proxy in your described configuration!

It seems more likely that it is objecting to the contact header scheme, but I’m not sure whether or not that is a bug, and I’d expect any failure only to happen if the TLS connection was lost and had to be re-established from the phone end.

I’d also want to see the response from the original INVITE.

8

David, thank you for looking at my issue! :blush:

I’ve uploaded the full log here: https://pastebin.com/p0Fb4qu9

Still didn’t manage to solve the problem. :worried:

9

I think you’ve overridden the default construction of the Contact header.

Is there a reason for doing this?

If yes, what did you put in your configuration to achieve this.

10

I think you’ve overridden the default construction of the Contact header.

Uhm, I wasn’t aware of that! :face_with_open_eyes_and_hand_over_mouth: Can you point me to a file / place where I should look for that?

The only thing that comes to my mind: The SIP trunk provider wrote in their setup guide to put “sip:004910000...@secure.sip.mytrunk.example.org” into the contact field of the “mytrunk” AOR. In which 004910000... is the external base phone number of the trunk in international format. For other AORs the contact field is not given.

11

I would have thought that should have been sips: , but it has been sent as sips:.

I’m talking about the address you are sending to contact you, which needs to be overridden to get a phone number in it. chan_sip used to use the extension number, but I believe that is not the default for chan_pjsip, so I assume you have overridden the default behaviour.

I’m assuming you have set something like contact_user or user_callerid_contact

12

You’re right! contact_user is set for the registration in pjsip.conf because the SIP trunk provider wrote that in their setup guide (German unfortunately):

[easybell]
    type=registration
    transport=transport-tls
    outbound_auth=easybell_auth
    server_uri=sip:secure.sip.easybell.de
    client_uri=sip:0049123456789@secure.sip.easybell.de
    contact_user=491234567890
    retry_interval=60
    forbidden_retry_interval=600
    expiration=1800
    line=yes
    endpoint=easybell

For contact_user they say it’s your “central number”, usually -0 or -00: “Der Contact-User ist in der Regel Ihre Zentrale.”

root@asterisk /etc/asterisk # grep -Rnw '/etc/asterisk/' -e 'user_callerid_contact'
root@asterisk /etc/asterisk # grep -Rnw '/etc/asterisk/' -e 'contact_user'
/etc/asterisk/pjsip.conf:36:    contact_user=491234567890
13

They are broken, as they have no right to make any assumptions about the meaning of the user part; that is only for the system sending the Contact header. However, it is possible that there is a bug in implementing that which always results in a SIP: URI (although I haven’t checked that the default isn’t also SIP:). If there is a bug of sort, its probably the case that almost no-one uses that option with TLS, and that most TLS implementations don’t care, because it is unlikely they will have to create a reverse connection.

14

Might be the case! I found a lot of postings like “disabled encryption and used transport-udp, now it works”.
Could you reach out to the developers to ask them to check whether there might be a bug?

15

You’d need to do that yourself, on the github issue tracker. I think I’d want to check the rules for TLS, and also try without the option, to see whether it sends a sips: URI by default, even if it gets failed because the provider reads too much into the contact user.

16

I have signed up an account and created an issue:

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.