Microsoft Teams integration possible?

Sorry, it was a long day trying to get this work. I recompiled everything AND ITS WORKING NOW! Thanks for your help!

For any others that have this problem. I did this before ./configure:

cd contrib/scripts
./install_prereq install
./install_prereq install-unpackaged

The install-unpackaged gave me some wired error messages, but it compiled poperly at the end.

The only thing i have problem with is DTMF. It is not working when calling someone with microsoft teams. I read some posts that it is only possible with alaw and ulaw (which i use) and that payload type need to be set to 101. But there are much discussions that payload on 101 isnt usal and correct. I think i could search in the source files of pjsip for the payload types and recompile everything. Did someone of you did DTMF get to work?

Payload 101 is used for telephony events, in which case the main codec doesn’t matter. You only need to use Mu-Law or A-law if you are sending the tones in band, rather than as events.

The type number for telephony events is not fixed. Each side tells the other which it intends to use. However 101 is the default preference for Asterisk.

This thread still lives ?

Did my own POC using chan_sip instead. Still trying to figure out how to REFER and OPTIONS ping. Hope this can help at some point.

https://www.otakudang.org/?p=969

Hmm chan_sip would maybee an option to try. I will maybee do it if there is no more options with PJSIP. I do not want to give up. Calling via teams is possible now without problems. But call someone in teams does not work. I always get Q.850;cause=95;text=“No SDP”. Which means something like “unspecific error”. Any suggestions what I could check? I was reading about not sending “REFER” in INVITE request.But i didnt found an option to turn it of. This is the trace:

-- Executing [4930863xxxxx@rya-incomming:2] Set("PJSIP/rya-incomming-00000000", "CALLERID(dnid)=+49017323xxxxx") in new stack
-- Executing [4930863xxxxx@rya-incomming:3] Set("PJSIP/rya-incomming-00000000", "CALLERID(num)=+49017323xxxxx") in new stack
-- Executing [4930863xxxxx@rya-incomming:14] Verbose("PJSIP/rya-incomming-00000000", "Route MSNs") in new stack
Route MSNs
-- Executing [4930863xxxxx@rya-incomming:15] Dial("PJSIP/rya-incomming-00000000", "PJSIP/+4930863xxxxx@msteams_trunk_from_teams") in new stack
-- Called PJSIP/+4930863xxxxx@msteams_trunk_from_teams

<--- Transmitting SIP request (730 bytes) to TLS:52.114.75.24:5061 --->
INVITE sip:+4930863xxxxx@sip.pstnhub.microsoft.com SIP/2.0
Via: SIP/2.0/TLS sipconnect.x.de:7489;rport;branch=z9hG4bKPjab0a5728-1715-4b24-acf6-116e6e2a02de;alias
From: <sip:+49017323xxxxx@sipconnect.x.de>;tag=10a4140c-d693-424a-9a09-1e3294642e8a
To: <sip:+4930863xxxxx@sip.pstnhub.microsoft.com>
Contact: <sip:asterisk@sipconnect.x.de:7489;transport=TLS>
Call-ID: efa61b05-fd5f-408e-ba5d-8287ee6effbe
CSeq: 7497 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 16.5.1
Content-Length:  0

<--- Received SIP response (474 bytes) from TLS:52.114.75.24:5061 --->
SIP/2.0 100 Trying
FROM: <sip:+49017323xxxxx@sipconnect.x.de>;tag=10a4140c-d693-424a-9a09-1e3294642e8a
TO: <sip:+4930863xxxxx@sip.pstnhub.microsoft.com>
CSEQ: 7497 INVITE
CALL-ID: efa61b05-fd5f-408e-ba5d-8287ee6effbe
VIA: SIP/2.0/TLS sipconnect.x.de:7489;branch=z9hG4bKPjab0a5728-1715-4b24-acf6-116e6e2a02de;rport;alias
CONTENT-LENGTH: 0
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SERVER: Microsoft.PSTNHub.SIPProxy v.2020.5.6.2 i.EUWE.5

<--- Received SIP response (548 bytes) from TLS:52.114.75.24:5061 --->
SIP/2.0 400 Bad Request
FROM: <sip:+49017323xxxxx@sipconnect.x.de>;tag=10a4140c-d693-424a-9a09-1e3294642e8a
TO: <sip:+4930863xxxxx@sip.pstnhub.microsoft.com>
CSEQ: 7497 INVITE
CALL-ID: efa61b05-fd5f-408e-ba5d-8287ee6effbe
VIA: SIP/2.0/TLS sipconnect.x.de:7489;branch=z9hG4bKPjab0a5728-1715-4b24-acf6-116e6e2a02de;rport
REASON: Q.850;cause=95;text="1c2462aa-cd47-453a-a718-15745b78087f;No SDP"
CONTENT-LENGTH: 0
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SERVER: Microsoft.PSTNHub.SIPProxy v.2020.5.6.2 i.EUWE.5

<--- Transmitting SIP request (458 bytes) to TLS:52.114.75.24:5061 --->
ACK sip:+4930863xxxxx@sip.pstnhub.microsoft.com SIP/2.0
Via: SIP/2.0/TLS sipconnect.x.de:7489;rport;branch=z9hG4bKPjab0a5728-1715-4b24-acf6-116e6e2a02de;alias
From: <sip:+49017323xxxxx@sipconnect.x.de>;tag=10a4140c-d693-424a-9a09-1e3294642e8a
To: <sip:+4930863xxxxx@sip.pstnhub.microsoft.com>
Call-ID: efa61b05-fd5f-408e-ba5d-8287ee6effbe
CSeq: 7497 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 16.5.1
Content-Length:  0

  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [4930863xxxxx@rya-incomming:16] Hangup("PJSIP/rya-incomming-00000000", "") in new stack
  == Spawn extension (rya-incomming, 4930863xxxxx, 16) exited non-zero on 'PJSIP/rya-incomming-00000000'

<--- Transmitting SIP response (439 bytes) to UDP:195.185.37.60:5060 --->
SIP/2.0 603 Decline
Via: SIP/2.0/UDP 195.185.37.60;rport=5060;received=195.185.37.60;branch=z9hG4bKCWh~DaamzHAk~
Call-ID: SBCd415e00009f5-5eb800e4-19152d91-2fca3508-93e0ab9-01_b2b-1
From: <sip:017323xxxxx5@sip.easybell.de>;tag=51D47450-5EB800E4000DFF68-A5D38700
To: <sip:4930863xxxxx@sip.easybell.de>;tag=8df2dcc2-a328-41e3-ad19-73acdc5721d9
CSeq: 10 INVITE
Server: Asterisk PBX 16.5.1
Reason: Q.850;cause=95
Content-Length:  0

<--- Received SIP request (397 bytes) from UDP:195.185.37.60:5060 --->
ACK sip:4930863xxxxx@sipconnect.x.de:7488 SIP/2.0
Via: SIP/2.0/UDP 195.185.37.60;branch=z9hG4bKCWh~DaamzHAk~;rport
From: <sip:017323xxxxx5@sip.easybell.de>;tag=51D47450-5EB800E4000DFF68-A5D38700
To: <sip:4930863xxxxx@sip.easybell.de>;tag=8df2dcc2-a328-41e3-ad19-73acdc5721d9
Call-ID: SBCd415e00009f5-5eb800e4-19152d91-2fca3508-93e0ab9-01_b2b-1
CSeq: 10 ACK
Content-Length: 0

It says “No SDP”, and that is true. I find that surprising, as I would expect early offer to be used, and can’t find anything to override that In any case, late offer is perfectly valid, so there is no valid reason for Teams to reject the call, at that point.

Solved it. I had silk16 in the allow option. Removed it an only left alaw and ulaw and now suprisingly it is working. I couldnt hear somethin on the called side but solved this with:

rtp_symmetric=no
force_rport=no
rewrite_contact=no

Hi all guys!

I did all on the tutorial but I have one question now, in pjsip history I can see 200ok from options bidirectionaly with my server and microsoft server (with TLS ok). But in the web i stil have this:

image

What could be the problem?

Thanks in advance!

I have the same question / problem.

I can make teams calls through asterisk. My problem is in receiving the calls in teams through asterisk.

Hello,

I can make teams calls through asterisk. My problem is in receiving the calls in teams through asterisk.

Could you share with me your trunk settings (msteams_trunk_from_teams).´cause whne I try make a call, show congestion…

tks

Hello… I have the same problem…

Did you found the solution?

Hi Gallego,

Im working with this pjsip.conf for incoming calls:

[msteams_trunk_in]
type = endpoint
transport=transport-tls
context = msteams_in
disallow = all
allow = ulaw, alaw, gsm
media_encryption=sdes

[ident_msteams_trunk_in]
type=identify
endpoint=msteams_trunk_in
match=sip-all.pstnhub.microsoft.com

Hi All,

Fairly new to the forum. Have a couple of asterisk servers connected to a bunch of different Teams tenants.

Only thing i am really struggling with at the moment is attended transfers.

I have the following rules in my config, but the external replaces line does not seem to be called when doing a attended transfer.

exten => external_replaces,1,NoOp()

exten => s,1,Dial(PJSIP/msteams_trunk_out/${SIPREFERTOHDR})

Looking for some help on how to configure this properly. At the moment the connection is broken and the user receiving the transfer gets a new call with the user that should be transferred in it.

Any help would be appreciated, if paying for it is necessary that will not be a problem.

I’ve not used this feature since it was introduced, but it seems to me that it is only invoked if the destination isn’t within the same instance of Asterisk.

The second line isn’t going to get executed, as it is in a completely different extension.