Dear List
Hope this email finds you all well.
I have followed the below tutorial on how to integrate Kamailio with MS Teams
https://skalatan.de/en/blog/kamailio-sbc-teams
However i have been facing an issue with MS Teams with direct routing where MS Teams does not send back an ACK after a 200 OK.
The current inbound call flow is the following:
*MS Teams ==> Kamailio==>Asterisk*
Once Asterisk answers with 200 OK we send this 200 OK back to MS Teams however, MS Teams just doesn't answer back with ACK and call drops.
The below trace shows the INVITE coming from MS Teams and the 200 OK we send back.
|||||||||||||||||||| ==================== tag: rcv pid: 26135 process: 23 time: 1613025911.983278 date: Thu Feb 11 08:45:11 2021 proto: tls ipv4 srcip: 52.114.132.46 srcport: 4352 dstip: SBC_IP_ADDR dstport: 5061 ~~~~~~~~~~~~~~~~~~~~ INVITE sip:+357XXXXXXXX@SBC-FQDN:5061;user=phone;transport=tls SIP/2.0 FROM: Phillip Kyriacousip:+357XXXXXXXX@sip.pstnhub.microsoft.com:5061 ;user=phone;tag=c3da9477e05d45fca31c24a155af3318 TO: sip:+357XXXXXXXX@SBC-FQDN:5061;user=phone CSEQ: 1 INVITE CALL-ID: 9cb9a2f3144e594c87bccda76791c28e MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 52.114.132.46:5061;branch=z9hG4bK0cf2c45 RECORD-ROUTE: sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr CONTACT: sip:api-du-b-euwe.pstnhub.microsoft.com:443 ;x-i=6e5254d9-79c2-4657-b54b-68791aa8e81f;x-c=9cb9a2f3144e594c87bccda76791c28e/d/10/e21a 6ff7125e4cbd91e75ec687fd4c5d CONTENT-LENGTH: 1097 MIN-SE: 300 SUPPORTED: timer USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2021.2.9.1 i.USEA.7 CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY SESSION-EXPIRES: 3600
v=0 o=- 170239 0 IN IP4 127.0.0.1 s=session c=IN IP4 52.113.40.94 b=CT:10000000 t=0 0 m=audio 51414 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118 c=IN IP4 52.113.40.94 a=rtcp:51415 a=ice-ufrag:BwFs a=ice-pwd:sFyvnfQ9iH101E80ZKjCxi9+ a=rtcp-mux a=candidate:1 1 UDP 2130706431 52.113.40.94 51414 typ srflx raddr 10.0.137.19 rport 51414 a=candidate:1 2 UDP 2130705918 52.113.40.94 51415 typ srflx raddr 10.0.137.19 rport 51415 a=candidate:2 1 tcp-act 2121006078 52.113.40.94 49152 typ srflx raddr 10.0.137.19 rport 49152 a=candidate:2 2 tcp-act 2121006078 52.113.40.94 49152 typ srflx raddr 10.0.137.19 rport 49152 a=label:main-audio a=mid:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Igc2LVM9FH5kQtkRpHw99H5SB7Rd7eKzJy4gdWJg|2^31 a=sendrecv a=rtpmap:104 SILK/16000 a=rtpmap:9 G722/8000 a=rtpmap:103 SILK/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 RED/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=ptime:20
|||||||||||||||||||| ==================== tag: snd pid: 26086 process: 6 time: 1613025917.726664 date: Thu Feb 11 08:45:17 2021 proto: tls ipv4 srcip: SBC_IP_ADDR srcport: 5061 dstip: 52.114.132.46 dstport: 5061 ~~~~~~~~~~~~~~~~~~~~ SIP/2.0 200 OK Via: SIP/2.0/TLS 52.114.132.46:5061;branch=z9hG4bK0cf2c45 Record-Route: sip:SBC-IP-ADDR:5060;ftag=c3da9477e05d45fca31c24a155af3318;lr=on Record-Route: sip:SBC-FQDN:5061;transport=tls;ftag=c3da9477e05d45fca31c24a155af3318;lr=on Record-Route: sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr From: Phillip Kyriacousip:+357XXXXXXX@sip.pstnhub.microsoft.com:5061 ;user=phone;tag=c3da9477e05d45fca31c24a155af3318 To: sip:+357XXXXXXXX@SBC-FQDN:5061;user=phone;tag=as659924a4 Call-ID: 9cb9a2f3144e594c87bccda76791c28e CSeq: 1 INVITE Server: MediaGW V1.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: sip:357XXXXXXXX@ASTERISK_PUBLIC_IP:5060 Content-Type: application/sdp Require: timer Content-Length: 339
v=0 o=root 411266324 411266324 IN IP4 ASTERISK_PUBLIC_IP s=ASTERISK c=IN IP4 ASTERISK_PUBLIC_IP t=0 0 m=audio 14416 RTP/SAVP 0 8 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9PcaAGjbemJKTERlFTcVwmLRQoDSEQPxX0L1a6RF a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=maxptime:150 a=sendrecv ||||||||||||||||||||
Am I doing anything wrong here that MS Teams wont respond to my 200 OK? The Kamailio SBC is showing active on MS Teams and Kamailio dispatcher shows all the MS Team hubs as AP. I also can't see any errors in the log file
My TLS cfg has the following: ======================
*[server:default]method = TLSv1.2+verify_certificate = yesrequire_certificate = yesprivate_key = /etc/letsencrypt/live/sbc.intelligentsupport.eu/privkey.pem http://sbc.intelligentsupport.eu/privkey.pemcertificate = /etc/letsencrypt/live/sbc.intelligentsupport.eu/fullchain.pem http://sbc.intelligentsupport.eu/fullchain.pemca_list = /etc/ssl/certs/ca-certificates.crt*
*[client:default]method = TLSv1.2+verify_certificate = yesrequire_certificate = yesprivate_key = /etc/letsencrypt/live/sbc.intelligentsupport.eu/privkey.pem http://sbc.intelligentsupport.eu/privkey.pemcertificate = /etc/letsencrypt/live/sbc.intelligentsupport.eu/fullchain.pem http://sbc.intelligentsupport.eu/fullchain.pemca_list = /etc/ssl/certs/ca-certificates.crt*
Thanks very much in advance!
Phillip
Try to put SBC-FQDN instead of SBC-IP-ADDR in the Record-Route:
Record-Route: sip:*SBC-FQDN* :5060;ftag=c3da9477e05d45fca31c24a155af3318;lr=on
On Thu, 11 Feb 2021 at 08:32, Phillman25 Kyriacou phillman25@gmail.com wrote:
Dear List
Hope this email finds you all well.
I have followed the below tutorial on how to integrate Kamailio with MS Teams
https://skalatan.de/en/blog/kamailio-sbc-teams
However i have been facing an issue with MS Teams with direct routing where MS Teams does not send back an ACK after a 200 OK.
The current inbound call flow is the following:
*MS Teams ==> Kamailio==>Asterisk*
Once Asterisk answers with 200 OK we send this 200 OK back to MS Teams however, MS Teams just doesn't answer back with ACK and call drops.
The below trace shows the INVITE coming from MS Teams and the 200 OK we send back.
||||||||||||||||||||
tag: rcv pid: 26135 process: 23 time: 1613025911.983278 date: Thu Feb 11 08:45:11 2021 proto: tls ipv4 srcip: 52.114.132.46 srcport: 4352 dstip: SBC_IP_ADDR dstport: 5061
INVITE sip:+357XXXXXXXX@SBC-FQDN:5061;user=phone;transport=tls SIP/2.0 FROM: Phillip Kyriacou<sip:+357XXXXXXXX@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c3da9477e05d45fca31c24a155af3318 TO: <sip:+357XXXXXXXX@SBC-FQDN:5061;user=phone> CSEQ: 1 INVITE CALL-ID: 9cb9a2f3144e594c87bccda76791c28e MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 52.114.132.46:5061;branch=z9hG4bK0cf2c45 RECORD-ROUTE: <sip:sip-du-a-us.pstnhub.microsoft.com:5061 ;transport=tls;lr> CONTACT: <sip:api-du-b-euwe.pstnhub.microsoft.com:443 ;x-i=6e5254d9-79c2-4657-b54b-68791aa8e81f;x-c=9cb9a2f3144e594c87bccda76791c28e/d/10/e21a 6ff7125e4cbd91e75ec687fd4c5d> CONTENT-LENGTH: 1097 MIN-SE: 300 SUPPORTED: timer USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2021.2.9.1 i.USEA.7 CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY SESSION-EXPIRES: 3600 v=0 o=- 170239 0 IN IP4 127.0.0.1 s=session c=IN IP4 52.113.40.94 b=CT:10000000 t=0 0 m=audio 51414 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118 c=IN IP4 52.113.40.94 a=rtcp:51415 a=ice-ufrag:BwFs a=ice-pwd:sFyvnfQ9iH101E80ZKjCxi9+ a=rtcp-mux a=candidate:1 1 UDP 2130706431 52.113.40.94 51414 typ srflx raddr 10.0.137.19 rport 51414 a=candidate:1 2 UDP 2130705918 52.113.40.94 51415 typ srflx raddr 10.0.137.19 rport 51415 a=candidate:2 1 tcp-act 2121006078 52.113.40.94 49152 typ srflx raddr 10.0.137.19 rport 49152 a=candidate:2 2 tcp-act 2121006078 52.113.40.94 49152 typ srflx raddr 10.0.137.19 rport 49152 a=label:main-audio a=mid:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Igc2LVM9FH5kQtkRpHw99H5SB7Rd7eKzJy4gdWJg|2^31 a=sendrecv a=rtpmap:104 SILK/16000 a=rtpmap:9 G722/8000 a=rtpmap:103 SILK/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 RED/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=ptime:20 |||||||||||||||||||| ==================== tag: snd pid: 26086 process: 6 time: 1613025917.726664 date: Thu Feb 11 08:45:17 2021 proto: tls ipv4 srcip: SBC_IP_ADDR srcport: 5061 dstip: 52.114.132.46 dstport: 5061SIP/2.0 200 OK Via: SIP/2.0/TLS 52.114.132.46:5061;branch=z9hG4bK0cf2c45 Record-Route: sip:SBC-IP-ADDR:5060;ftag=c3da9477e05d45fca31c24a155af3318;lr=on Record-Route: sip:SBC-FQDN:5061;transport=tls;ftag=c3da9477e05d45fca31c24a155af3318;lr=on Record-Route: sip:sip-du-a-us.pstnhub.microsoft.com:5061 ;transport=tls;lr From: Phillip Kyriacousip:+357XXXXXXX@sip.pstnhub.microsoft.com:5061 ;user=phone;tag=c3da9477e05d45fca31c24a155af3318 To: sip:+357XXXXXXXX@SBC-FQDN:5061;user=phone;tag=as659924a4 Call-ID: 9cb9a2f3144e594c87bccda76791c28e CSeq: 1 INVITE Server: MediaGW V1.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: sip:357XXXXXXXX@ASTERISK_PUBLIC_IP:5060 Content-Type: application/sdp Require: timer Content-Length: 339
v=0 o=root 411266324 411266324 IN IP4 ASTERISK_PUBLIC_IP s=ASTERISK c=IN IP4 ASTERISK_PUBLIC_IP t=0 0 m=audio 14416 RTP/SAVP 0 8 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9PcaAGjbemJKTERlFTcVwmLRQoDSEQPxX0L1a6RF a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=maxptime:150 a=sendrecv ||||||||||||||||||||
Am I doing anything wrong here that MS Teams wont respond to my 200 OK? The Kamailio SBC is showing active on MS Teams and Kamailio dispatcher shows all the MS Team hubs as AP. I also can't see any errors in the log file
My TLS cfg has the following:
*[server:default]method = TLSv1.2+verify_certificate = yesrequire_certificate = yesprivate_key = /etc/letsencrypt/live/sbc.intelligentsupport.eu/privkey.pem http://sbc.intelligentsupport.eu/privkey.pemcertificate = /etc/letsencrypt/live/sbc.intelligentsupport.eu/fullchain.pem http://sbc.intelligentsupport.eu/fullchain.pemca_list = /etc/ssl/certs/ca-certificates.crt*
*[client:default]method = TLSv1.2+verify_certificate = yesrequire_certificate = yesprivate_key = /etc/letsencrypt/live/sbc.intelligentsupport.eu/privkey.pem http://sbc.intelligentsupport.eu/privkey.pemcertificate = /etc/letsencrypt/live/sbc.intelligentsupport.eu/fullchain.pem http://sbc.intelligentsupport.eu/fullchain.pemca_list = /etc/ssl/certs/ca-certificates.crt*
Thanks very much in advance!
Phillip
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Pepelux writes:
Try to put SBC-FQDN instead of SBC-IP-ADDR in the Record-Route:
Record-Route: sip:*SBC-FQDN* :5060;ftag=c3da9477e05d45fca31c24a155af3318;lr=on
Also, it better to follow OpenSIPS tips on the matter
https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/
since it also mentions how to handle R-R in replies. Author of the Kamailio one has not bothered to update his.
-- Juha
On 11.02.21 09:34, Juha Heinanen wrote:
Pepelux writes:
Try to put SBC-FQDN instead of SBC-IP-ADDR in the Record-Route:
Record-Route: sip:*SBC-FQDN* :5060;ftag=c3da9477e05d45fca31c24a155af3318;lr=on
Also, it better to follow OpenSIPS tips on the matter
https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/
since it also mentions how to handle R-R in replies. Author of the Kamailio one has not bothered to update his.
What exactly do you need to do for R-R in replies?
The R-R headers are mirrored in replies, so if you add R-R for requests using the right order of parameters based on the direction, there is nothing to be done for replies, or at least I haven't had to do it for my Kamailio interconnect proxy for MS Teams.
Cheers, Daniel
Daniel-Constantin Mierla writes:
What exactly do you need to do for R-R in replies?
The R-R headers are mirrored in replies, so if you add R-R for requests using the right order of parameters based on the direction, there is nothing to be done for replies, or at least I haven't had to do it for my Kamailio interconnect proxy for MS Teams.
Sorry, I was not clear.
When INVITE goes from K to Teams, the *top* R-R header (assuming there is two) added by K needs to have K's FQDN.
But when INVITE comes from Teams to K, the *bottom* R-R header (assuming there is two) added by K needs to have K's FQDN.
-- Juha
Hello Juha,
not 100% sure what the other blog post is suggesting - but in my setups there is no need for a special record_route(..) in reply handling (like reply route).
So I saw no need to update it.
Cheers,
Henning
Henning Westerholt writes:
not 100% sure what the other blog post is suggesting - but in my setups there is no need for a special record_route(..) in reply handling (like reply route).
Its is not question about reply handling, but direction of INVITE. See my earlier message.
-- Juha
-
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen -
Pepelux -
Phillman25 Kyriacou