Home

MS Teams Direct Routing - Internal call transfer failure

%3CLINGO-SUB%20id%3D%22lingo-sub-754902%22%20slang%3D%22en-US%22%3EMS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-754902%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20all%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMy%20organisation%20is%20planning%20a%20move%20to%20direct%20routing.%20We%20have%20an%20AudioCodes%20VE%20SBC.%20I've%20been%20working%20on%20this%20for%20awhile%20and%20got%20everything%20to%20a%20pretty%20decent%20state.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20come%20across%20an%20issue%20which%20is%20fairly%20new%20as%20I%20remember%20testing%20this%20months%20ago%2C%20when%20I%20was%20still%20trying%20to%20figure%20out%20how%20to%20deal%20with%20REFERs%20coming%20from%20MS%20Teams%20on%20call%20transfers.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20the%20call%20flow%20is%20as%20follows%3A%3C%2FP%3E%3CP%3EIncoming%20call%20from%20SBC%20to%20MS%20Teams%20-%26gt%3B%20MS%20Teams%20user%20transfers%20the%20call%20to%20internal%20user%20-%26gt%3B%20Call%20fails%20as%20MS%20Teams%20generates%20a%20REFER%20back%20to%20the%20SBC%20rather%20than%20route%20the%20call%20internally%20to%20MS%20Teams%20user%20target.%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20issue%20I'm%20observing%20aside%20from%20MS%20Teams%20routing%20the%20transfer%20leg%20of%20the%20call%20is%20that%20the%20REFER-TO%20user%20part%20of%20the%20URI%20is%20blank.%20Please%20see%20the%20attached%20screenshot.%3CBR%20%2F%3E%3CBR%20%2F%3EIts%20as%20if%20MS%20Teams%20is%20treating%20this%20as%20an%20external%20transfer%20and%20does%20not%20know%20how%20to%20populate%20the%20user%20part%20of%20the%20REFER-TO%20header.%20I've%20tested%20this%20with%20both%20users%20set%20up%20with%20Phone%20system%20and%20DDIs%20assigned%20to%20the%20user%20and%20users%20which%20have%20no%20phone%20system%20add-on%20or%20assigned%20DDI.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EPlease%20note%20that%20if%20you%20tried%20to%20transfer%20the%20call%20to%20a%20PSTN%20number%2C%20that%20works%20fine.%20I'm%20unsure%20if%20this%20would%20be%20something%20config%20related%20within%20our%20Teams%20tenancy%20or%20a%20genuine%20bug.%20I'm%20more%20inclined%20that%20this%20is%20the%20former%20rather%20than%20the%20latter%20as%20it%20does%20seem%20like%20fairly%20basic%20functionality%20and%20I'm%20confident%20this%20used%20to%20work%20a%20few%20months%20ago.%3CBR%20%2F%3E%3CBR%20%2F%3EAny%20advice%20would%20be%20appreciated.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EKind%20Regards%2C%3C%2FP%3E%3CP%3ESim%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-754902%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EMicrosoft%20Teams%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-756217%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-756217%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Sim%2C%3C%2FP%3E%3CP%3EWe've%20got%20exactly%20the%20same%20behaviour%20when%20trying%20to%20transfer%20calls%20that%20came%20from%20PSTN%20network%20and%20got%20answered%20by%20one%20of%20our%20Teams%20users%20and%20when%20they%20try%20to%20transfer%20to%20another%20Teams%20user.%20REFER-TO%20doesn't%20contain%20any%20LineURI%20or%20telephone%20number%20to%20complete%20the%20transfer.%20Did%20you%20have%20any%20luck%20fixing%20this%20issue%3F%20Also%2C%20I'm%20not%20sure%20if%20this%20was%20working%20before%20or%20not.%20But%20you%20seem%20to%20be%20correct%20in%20regards%20to%20Teams%20treating%20internal%20transfer%20as%20external%20one%20and%20sending%20SIP%20REFER%20back%20to%20SBC%20without%20providing%20any%20additional%20details%20in%20regards%20where%20the%20call%20should%20be%20actually%20connected%20or%20transferred%20to.%20When%20transferring%20to%20external%20number%20this%20works%20perfectly%20fine%2C%20REFER-TO%20contains%20an%20external%20number%20and%20can%20be%20processed%20by%20our%20SBC.%20BTW%2C%20can%20you%20tell%20what%20SBC%20are%20you%20using%3F%20Is%20it%20AudioCodes%20or%20Ribbon%20one%3F%20Or%20something%20not%20currently%20certified%20by%20Microsoft%3F%20Thanks!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-756503%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-756503%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3BWe're%20using%20AudioCodes%2C%20and%20config%20wise%20its%20fine.%20It%20handles%20REFERs%20just%20fine.%20The%20issue%20here%20is%20that%20MS%20Teams%20should%20never%20had%20sent%20this%20REFER%20out%20the%20SBC%2C%20it%20should%20have%20handled%20it%20within%20the%20Teams%20environment%20as%20its%20a%20transfer%20from%20one%20Teams%20user%20to%20another.%20This%20only%20thing%20I%20suspect%20config%20wise%20is%20voice%20route%20regex%20I'm%20using%2C%20as%20its%20pretty%20much%20a%20catch%20all%20e.g.%20%22%3CSPAN%20class%3D%22s1%22%3E.*%22%26nbsp%3B%3CBR%20%2F%3EI've%20now%20made%20it%20more%20strict%20to%20capture%20digit%20patterns%20rather%20than%20all%20chars%20to%20see%20if%20the%20issue%20persists.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22s1%22%3EIt%20makes%20no%20sense%20as%20I%20can%20call%20users%20internally%2C%20it%20only%20happens%20when%20PSTN%20call%20comes%20in%20from%20the%20direct%20Routing%20SBC%2C%20so%20Teams%20appears%20to%20be%20applying%20a%20different%20call%20routing%20logic%20when%20applying%20the%20transfer.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22s1%22%3EOut%20of%20curiosity%20can%20you%20let%20me%20know%20what%20your%20voice%20route%20pattern%20looks%20like%3F%20Was%20it%20a%20catch%20all%20like%20mine%20or%20is%20it%20more%20strict%3F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22s1%22%3EThanks%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22s1%22%3ESim%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-756562%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-756562%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EYes%2C%20I'm%20using%20the%20same%20voice%20pattern%2C%20%22.*%22%20to%20send%20all%20digits%20without%20any%20normalization%20to%20our%20SIP%20trunk.%20You're%20right%2C%20maybe%20the%20issue%20is%20because%20of%20that%2C%20I%20will%20update%20voice%20rules%20tomorrow%20to%20make%20it%20strictly%20country-based%2C%20like%20'%5E%2B44.*'%20to%20see%20if%20that%20helps!%20Good%20point%2C%20mate!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAlso%2C%20yes%2C%20SIP%20REFER%20shouldn't%20be%20coming%20back%20to%20PBX%20when%20we're%20doing%20an%20internal%20transfer%20from%20one%20Teams%20User%20to%20another%20one%2C%20but%20it%20does%20for%20some%20reason%2C%20that's%20the%20problem.%3CBR%20%2F%3E%3CBR%20%2F%3EI'll%20let%20you%20know%20here%20how%20it%20goes%20and%20thanks%20for%20your%20reply!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-760045%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-760045%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20Sims%2C%3C%2FP%3E%3CP%3EI've%20removed%20the%20%22.*%22%20rule%20from%20my%20installation%20and%20created%20all%20specific%20rules%20for%20DIDs%20and%20still%20no%20luck%2C%20I%20can%20see%20SIP%20REFER%20coming%20back%20to%20PBX%20when%20I'm%20trying%20to%20transfer%20call%20that%20came%20from%20PSTN%20to%20Teams%20user.%20No%20luck%20here%2C%20unfortunately.%20Did%20you%20have%20any%20luck%20with%20this%3F%20Thanks.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-772977%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-772977%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3BI%20had%20no%20luck%20with%20changing%20the%20voice%20route%2C%20so%20ended%20up%20raising%20it%20with%20MS%20support.%3C%2FP%3E%3CP%3EApparently%20if%20you%20disable%20REFER%20as%20an%20allowed%20method%20within%20your%20SBC's%20signalling%20messages%2C%20then%20MS%20Teams%20does%20not%20use%20REFER%20for%20transfers%20and%20just%20re-INVITEs%20to%20the%20SBC.%20That%20way%20the%20internal%20transfers%20work%20perfectly%20fine.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-773103%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-773103%22%20slang%3D%22en-US%22%3EHow%20did%20you%20disable%20REFER%3F%20I%20mean%20-%20does%20your%20SBC%20sends%20some%204xx%20code%20when%20MS%20sends%20a%20SIP%20REFER%20message%3F%20Or%20somehow%20different%3F%20Thanks!%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-773127%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-773127%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENo%2C%20not%20by%20rejecting%20the%20REFER%20with%20a%20response%20code.%20I%20basically%20did%20a%20message%20manipulation%20rule%20to%20re-build%20the%20Allow%20header%20for%20calls%20to%20MS%20Teams%20without%20including%20REFER.%20Which%20vendor%20are%20you%20using%3F%20If%20you%20have%20an%20AudioCodes%20as%20well%2C%20I%20can%20give%20you%20the%20rule%20syntax.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-773167%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-773167%22%20slang%3D%22en-US%22%3ENo%2C%20we're%20using%20a%20custom%20SBC%2C%20but%20yes%2C%20that%20was%20my%20second%20guess%20-%20to%20strip%20REFERs%20from%20packets.%20Thanks%20a%20lot%2C%20I'll%20give%20it%20a%20go%20and%20let%20you%20know%20if%20it%20works%20for%20me!%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-773659%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-773659%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3Byou%20seem%20to%20be%20correct!%20I've%20just%20edited%20all%20messages%20that%20were%20coming%20from%20PSTN%20side%20of%20our%20SBC%20and%20stripped%20'REFER'%20on%20SBC%20in%20'Allow'%20field%20-%20and%20yes%2C%20Microsoft%20started%20to%20transfer%20calls%20correctly!%20Thanks%20a%20lot%2C%20mate%2C%20I've%20already%20read%20that%20disabling%20SIP%20REFER%20method%20helped%20some%20people%2C%20but%20I%20was%20trying%20to%20reply%20with%204xx%20or%205xx%20when%20receiving%20REFER%20from%20MS%20side%2C%20while%20I%20should%20have%20just%20removed%20that%20REFER%20method%20from%20SIP%20'Allow'%20list!%20By%20the%20way%2C%20looking%20at%20the%20packets%20coming%20from%20Microsoft%20side%20I%20can%20see%20that%20they%20don't%20send%20REFER%20in%20allowed%20method%20list!%20Here's%20an%20example%3A%3CBR%20%2F%3E%3CBR%20%2F%3ECONTENT-LENGTH%3A%20685%3CBR%20%2F%3EMIN-SE%3A%2090%3CBR%20%2F%3ESUPPORTED%3A%20timer%3CBR%20%2F%3EUSER-AGENT%3A%20Microsoft.PSTNHub.SIPProxy%20v.2019.7.4.9%20i.USWE2.4%3CBR%20%2F%3ECONTENT-TYPE%3A%20application%2Fsdp%3CBR%20%2F%3EALLOW%3A%20INVITE%3CBR%20%2F%3EALLOW%3A%20ACK%3CBR%20%2F%3EALLOW%3A%20OPTIONS%3CBR%20%2F%3EALLOW%3A%20CANCEL%3CBR%20%2F%3EALLOW%3A%20BYE%3CBR%20%2F%3EALLOW%3A%20NOTIFY%3CBR%20%2F%3ESESSION-EXPIRES%3A%201800%3Brefresher%3Duas%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EThanks%20again%20for%20your%20help%20and%20I'm%20glad%20everything%20is%20working%20fine%20for%20you%20too%20now!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-783634%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-783634%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20confirm%20this%20behavior%2C%20just%20that%20REFER%20triggered%20transfer%20is%20most%20common%20way%20for%20it%20and%20only%20fully%20standardized%20one.%20If%20your%20SBC%20is%20capable%20to%20terminate%20REFER%20note%20that%20MS%20still%20clearly%20indicates%20in%20Refer-To%20where%20to%20send%20INVITE%20back%3A%26nbsp%3B%3C%2FP%3E%3CP%3EREFER-TO%3A%20%26lt%3B5061%26gt%3B%26lt%3B5061%26gt%3Bsip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3Afce2158f-0e99-4ff7-a0b3-5b6b87d16689%3C%2FP%3E%3C%2FLINGO-BODY%3E%26lt%3B5061%26gt%3B%3CBR%20%2F%3E%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%20and%20making%20sure%20you%20fill%20RURI%20with%20Refer-To%20and%20Contact%20uri-host%20correctly%20you%20will%20see%20MS%20does%20rest%20of%20the%20job%20nicely%20for%20REFER%20case%20too.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-783723%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-783723%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F380677%22%20target%3D%22_blank%22%3E%40Matej_Maric%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20shows%20where%20to%20send%20INVITE%20to%2C%20but%20it%20doesn't%20have%20a%20DID%20or%20username%20in%20SIP%20R-URI%20so%20SBC%20can't%20figure%20out%20where%20to%20dial%20to.%20SBC%20uses%20PSTN-type%20dialing%2C%20so%20it%20needs%20some%20LineURI%20or%20DID%20to%20send%20INVITE%20to%2C%20like%20%2B44XXXXXXXX%40sip.pstnhub.microsoft.com.%20Otherwise%20it%20can't%20decide%20what%20to%20put%20in%20SIP%20INVITE%20method%20as%20'To'%20field.%20I've%20tried%20to%20update%20SIP%20INVITE%20to%20whatever%20is%20in%20REFER-TO%20header%20and%20send%20it%20back%20to%20Microsoft%2C%20but%20I%20was%20getting%20a%20400%20Bad%20Request%20back.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EREFER-TO%3A%20%26lt%3B5061%26gt%3B%26lt%3B5061%26gt%3Bsip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3Afce2158f-0e99-4ff7-a0b3-5b6b87d16689%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%26lt%3B5061%26gt%3B%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EThere's%20no%20user%20part%20in%20this%20SIP%20RURI%2C%20only%20host.%20What%20should%20be%20put%20in%20To%20header%3F%20Contact%20header%20is%20obvious%2C%20it's%20our%20SBC%20Contact.%3C%2FSPAN%3E%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-783753%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-783753%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ethe%20thing%20is%20that%20SBC%20should%20only%20respect%20Refer-to%20header%20by%20means%20of%20SIP.%20REFER%20comes%20without%20user%20part%20but%20it's%20still%20fair%20enough%20and%20legal.%20So%20what%20my%20SBC%20does%20as%20last%20resort%20to%20send%20INVITE%20out%20is%20DNS%20query%20for%20hostname%20in%20Refer-To%20and%20fills%20RURI%20and%20To%20in%20same%20fashion%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EINVITE%20sip%3Asip.pstnhub.microsoft.com%3A5061%3Bx-m%3D8%3Aorgid%3Afce2158f-0e99-4ff7-a0b3-5b6b87d16689%3Btransport%3Dtls%20SIP%2F2.0%3CBR%20%2F%3EVia%3A%20SIP%2F2.0%2FTLS%20192.168.65.100%3A5061%3Bbranch%3Dz9hG4bKvahihb0040adpr8tb320.1%3CBR%20%2F%3ECSeq%3A%201%20INVITE%3CBR%20%2F%3EContact%3A%20%26lt%3B5061%26gt%3B%3Bsip.ice%3CBR%20%2F%3EFrom%3A%20%26lt%3B%26gt%3B%3Btag%3D11241SIPpTag011%3CBR%20%2F%3ETo%3A%20%26lt%3B5061%26gt%3B%3CBR%20%2F%3EContent-Type%3A%20application%2Fsdp%3CBR%20%2F%3EContent-Length%3A%20425%3CBR%20%2F%3EReferred-By%3A%20%26lt%3B5061%26gt%3B%3CBR%20%2F%3ECall-ID%3A%208f09e11d9183f754c525a0d4ce2aea46%3CBR%20%2F%3ESupported%3A%20replaces%3CBR%20%2F%3EMax-Forwards%3A%2070%3C%2FP%3E%3C%2FLINGO-BODY%3E%26nbsp%3B%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eand%20that's%20just%20enough...%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-783755%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-783755%22%20slang%3D%22en-US%22%3E%3CP%3Eobviously%20we%20dont%20use%20same%20vendor%20SBC%20but%20standard%20wise%20logic%20should%20remain%20the%20same%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-784350%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-784350%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F380677%22%20target%3D%22_blank%22%3E%40Matej_Maric%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20for%20detailed%20description%2C%20I%20will%20try%20to%20reproduce%20this%20behaviour%20on%20my%20SBC%2C%20but%20it%20looks%20really%20strange%20to%20me%20that%20MS%20sends%20a%20SIP%20REFER%20packet%20back%20to%20SBC%20that%20connects%20calls%20to%20PSTN%20and%20uses%20LineURI%20telephone%20numbers%20for%20that.%20According%20to%20RFC%20it%20should%20provide%20a%20proper%20username%20or%20DID%20in%20such%20case.%20From%20what%20I%20can%20see%20now%20it's%20much%20simpler%20to%20just%20disallow%20REFER%20method%20and%20let%20Microsoft%20Teams%20handle%20internal%20call%20transfers%20on%20their%20side%2C%20which%20is%20more%20logical%2C%20rather%20than%20implementing%20such%20call%20forking.%20Anyway%2C%20your%20help%20is%20much%20appreciated%20and%20SIP%20INVITE%20packet%20is%20a%20perfect%20example%20on%20what%20I%20should%20try%20to%20achieve.%20Thanks!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-785272%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-785272%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F380677%22%20target%3D%22_blank%22%3E%40Matej_Maric%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUnfortunately%2C%20something%20is%20not%20working%20for%20me%2C%20I've%20got%20an%20INVITE%20sent%20same%20way%20as%20you're%20doing%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EINVITE%20sip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3A7709b36f-1f10-4b1c-8a0f-9c0e5390c86c%20SIP%2F2.0%3CBR%20%2F%3EVia%3A%20SIP%2F2.0%2FTLS%20X.X.X.X%3A5061%3Bbranch%3Dz9hG4bKf26f.503bdc4.0%3Bi%3D54849946%3CBR%20%2F%3EFrom%3A%20%22XXXXXXXXXXXX%22%20%26lt%3B0421273494%26gt%3B%3Btag%3Da1d8a1ca-d330-4251-811d-35fa1a797c64%3CBR%20%2F%3ETo%3A%20%26lt%3B%26lt%3B5061%26gt%3Bsip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3A7709b36f-1f10-4b1c-8a0f-9c0e5390c86c%26gt%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%26lt%3B5061%26gt%3B%3CBR%20%2F%3ECall-ID%3A%201fa2f0d0-ba41-4e4d-83be-fbef9d0739c6%3CBR%20%2F%3ECSeq%3A%2010432%20INVITE%3CBR%20%2F%3EAllow%3A%20OPTIONS%2C%20REGISTER%2C%20SUBSCRIBE%2C%20NOTIFY%2C%20PUBLISH%2C%20INVITE%2C%20ACK%2C%20BYE%2C%20CANCEL%2C%20UPDATE%2C%20PRACK%2C%20REFER%3CBR%20%2F%3ESupported%3A%20100rel%2C%20timer%2C%20replaces%2C%20norefersub%3CBR%20%2F%3ESession-Expires%3A%201800%3CBR%20%2F%3EMin-SE%3A%2090%3CBR%20%2F%3EMax-Forwards%3A%2069%3CBR%20%2F%3EContent-Type%3A%20application%2Fsdp%3CBR%20%2F%3EContent-Length%3A%20346%3CBR%20%2F%3EContact%3A%20%3CGATEWAY%3E%3CGATEWAY%3E%3C%2FGATEWAY%3E%3C%2FGATEWAY%3E%3CP%3E%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20I'm%20getting%20following%20reply%20back%20from%20Microsoft%3A%3CBR%20%2F%3E%3CBR%20%2F%3ESIP%2F2.0%20400%20Bad%20Request%3CBR%20%2F%3EFROM%3A%20%22XXXXXXXXX%22%26lt%3B0421273494%26gt%3B%3Btag%3Da1d8a1ca-d330-4251-811d-35fa1a797c64%3CBR%20%2F%3ETO%3A%20%26lt%3B5061%26gt%3B%26lt%3B5061%26gt%3B%26nbsp%3B%3CBR%20%2F%3ECSEQ%3A%2010432%20INVITE%3CBR%20%2F%3ECALL-ID%3A%201fa2f0d0-ba41-4e4d-83be-fbef9d0739c6%3CBR%20%2F%3EVIA%3A%20SIP%2F2.0%2FTLS%20X.X.X.X%3A5061%3Bbranch%3Dz9hG4bKf26f.503bdc4.0%3Bi%3D54849946%3CBR%20%2F%3EREASON%3A%20Q.850%3Bcause%3D111%3Btext%3D%22a5d458f9-14c0-4cc4-8c10-202277af11e9%3BUnable%20to%20parse%20RURI.%22%3CBR%20%2F%3ECONTENT-LENGTH%3A%200%3CBR%20%2F%3EALLOW%3A%20INVITE%3CBR%20%2F%3EALLOW%3A%20ACK%3CBR%20%2F%3EALLOW%3A%20OPTIONS%3CBR%20%2F%3EALLOW%3A%20CANCEL%3CBR%20%2F%3EALLOW%3A%20BYE%3CBR%20%2F%3EALLOW%3A%20NOTIFY%3CBR%20%2F%3ESERVER%3A%20Microsoft.PSTNHub.SIPProxy%20v.2019.7.4.9%20i.USWE2.3%20%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI'm%20not%20sure%20what%20I'm%20doing%20wrong%2C%20any%20ideas%3F%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-785275%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-785275%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F380677%22%20target%3D%22_blank%22%3E%40Matej_Maric%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3EUnfortunately%2C%20that%20doesn't%20work%20for%20me%2C%20I'm%20sending%20same%20INVITE%20packet%20as%20you%20do%20but%20I'm%20getting%20back%20a%20'400%20Bad%20Request'%20with%20a%20REASON%3A%3CBR%20%2F%3E%3CBR%20%2F%3EREASON%3A%20Q.850%3Bcause%3D111%3Btext%3D%22a5d458f9-14c0-4cc4-8c10-202277af11e9%3BUnable%20to%20parse%20RURI.%22%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CP%3E%3C%2FP%3E%3CP%3ETo%3A%26nbsp%3Bsip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3A7709b36f-1f10-4b1c-8a0f-9c0e5390c86c%3C%2FP%3E%3CP%3ECall-ID%3A%201fa2f0d0-ba41-4e4d-83be-fbef9d0739c6%3C%2FP%3E%3CP%3ECSeq%3A%2010432%20INVITE%3C%2FP%3E%3CP%3EAllow%3A%20OPTIONS%2C%20REGISTER%2C%20SUBSCRIBE%2C%20NOTIFY%2C%20PUBLISH%2C%20INVITE%2C%20ACK%2C%20BYE%2C%20CANCEL%2C%20UPDATE%2C%20PRACK%2C%20REFER%3C%2FP%3E%3CP%3ESupported%3A%20100rel%2C%20timer%2C%20replaces%2C%20norefersub%3C%2FP%3E%3CP%3ESession-Expires%3A%201800%3C%2FP%3E%3CP%3EMin-SE%3A%2090%3C%2FP%3E%3CP%3EMax-Forwards%3A%2069%3C%2FP%3E%3CP%3EContent-Type%3A%20application%2Fsdp%3C%2FP%3E%3CP%3EContent-Length%3A%20346%3C%2FP%3E%3CP%3EContact%3A%20sip%3Agateway%40sbc.xxx.xxx.com%3A5061%3Btransport%3DTLS%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-785284%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-785284%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F380677%22%20target%3D%22_blank%22%3E%40Matej_Maric%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHere's%20my%20INVITE%20packet%2C%20I%20had%20to%20remove%20triangle%20brackets%20to%20make%20post%20clear%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EINVITE%20sip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3A7709b36f-1f10-4b1c-8a0f-9c0e5390c86c%20SIP%2F2.0%3C%2FP%3E%3CP%3EVia%3A%20SIP%2F2.0%2FTLS%20X.X.X.X%3A5061%3Bbranch%3Dz9hG4bKf26f.503bdc4.0%3Bi%3D54849946%3C%2FP%3E%3CP%3EFrom%3A%20%22XXXXXXX%22%3Btag%3Da1d8a1ca-d330-4251-811d-35fa1a797c64%26amp%3B%3B%3C%2FP%3E%3CP%3ETo%3A%26nbsp%3Bsip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Aorgid%3A7709b36f-1f10-4b1c-8a0f-9c0e5390c86c%3C%2FP%3E%3CP%3ECall-ID%3A%201fa2f0d0-ba41-4e4d-83be-fbef9d0739c6%3C%2FP%3E%3CP%3ECSeq%3A%2010432%20INVITE%3C%2FP%3E%3CP%3EAllow%3A%20OPTIONS%2C%20REGISTER%2C%20SUBSCRIBE%2C%20NOTIFY%2C%20PUBLISH%2C%20INVITE%2C%20ACK%2C%20BYE%2C%20CANCEL%2C%20UPDATE%2C%20PRACK%2C%20REFER%3C%2FP%3E%3CP%3ESupported%3A%20100rel%2C%20timer%2C%20replaces%2C%20norefersub%3C%2FP%3E%3CP%3ESession-Expires%3A%201800%3C%2FP%3E%3CP%3EMin-SE%3A%2090%3C%2FP%3E%3CP%3EMax-Forwards%3A%2069%3C%2FP%3E%3CP%3EContent-Type%3A%20application%2Fsdp%3C%2FP%3E%3CP%3EContent-Length%3A%20346%3C%2FP%3E%3CP%3EContact%3A%20sip%3Agateway%40sbc.xxx.xxx.com%3A5061%3Btransport%3DTLS%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-785329%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-785329%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F380677%22%20target%3D%22_blank%22%3E%40Matej_Maric%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAll%20right%2C%20just%20to%20clarify%2C%20I've%20got%20this%20sorta%20working%2C%20I%20was%20removing%20REFERRED-BY%20header%20when%20placing%20a%20new%20INVITE%20and%20that's%20why%20it%20couldn't%20connect%20the%20call%2C%20after%20leaving%20that%20header%20intact%20the%20call%20can%20be%20transferred.%20But%20this%20far%20for%20us%20it's%20much%20easier%20just%20to%20remove%20REFER%20method%20from%20the%20list%20of%20allowed%20methods%2C%20otherwise%20it's%20quite%20a%20complex%20setup%20with%20our%20SBC.%20Thanks%20everyone%20for%20replies%2C%20now%20we%20have%20two%20working%20methods%20that%20allow%20call%20to%20be%20transferred%20to%20internal%20MS%20Teams%20users!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-785524%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-785524%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eyep%2C%20tend%20to%20be%20with%20you%20on%20conclusions.%20being%20forced%20to%20implement%20both%20in%20real%20life%20felt%20like%20sharing%20things%20people%20find%20useful%20%3A)Most%20important%20is%20we%20understand%20now%20how%20to%20implement%20both%20methods%20and%20logic%20MS%20uses%20to%20trigger%20each.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Echeers!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDoes%20anybody%20have%20an%20idea%2C%20why%203pip%20Phones%20or%20SfB%20Client%20for%20that%20matter%20(i%20know%20it's%20not%20supported%20but%20if%203pip%20should%20work%2C%20the%20SfB%20Client%20should%20also%20work)%20does%20not%20send%20a%20Refer%20to%20number%20to%20our%20SBC%3F%20Or%20is%20there%20anyone%20around%20who%20can%20test%20it%20and%20tell%20me%20if%20it's%20working%20with%20their%20SBC%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3Emozzie%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-785753%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-785753%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20for%20us%20it's%20the%20other%20way%20around.%20Internal%20calls%20transfer%20perfectly%20fine%20and%20transfer%20to%20PSTN%20only%20works%20via%20the%20Teams%20Client.%20We%20do%20use%20some%203PIP%20Phones%20from%20AudioCodes%2C%20Yealink%20and%20Poly%20and%20if%20we%20try%20to%20transfer%20a%20call%20to%20an%20external%20Number%2C%20our%20SBC%20does%20not%20receive%20a%20refer-to%20number%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENow%20i%20have%20heard%20from%20someone%2C%20that%20their%20AudioCodes%20SBC%20receives%20this%20from%20Number%20even%20when%20it's%20coming%20from%20a%203PIP%20Phone.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHad%20to%20put%20%26lt%3B%20and%20%26gt%3B%20into%20%22%26lt%3B%22%20in%20order%20to%20paste%20it%20here...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26lt%3B443%26gt%3B%26lt%3B%26gt%3B%26lt%3B5061%26gt%3B%26lt%3B5061%26gt%3B%26lt%3B%26gt%3B%26lt%3B443%26gt%3B%26lt%3B%26gt%3B%26lt%3B5061%26gt%3B%26lt%3B5061%26gt%3B%26lt%3B%26gt%3BREFER%20sip%3Asbc.*hiddendomain*.ch%3A5999%3Btransport%3Dtls%3Bmaddr%3D172.16.1.12%20SIP%2F2.0%3CBR%20%2F%3EAllow%3A%20INVITE%3CBR%20%2F%3EAllow%3A%20ACK%3CBR%20%2F%3EAllow%3A%20OPTIONS%3CBR%20%2F%3EAllow%3A%20CANCEL%3CBR%20%2F%3EAllow%3A%20BYE%3CBR%20%2F%3EAllow%3A%20NOTIFY%3CBR%20%2F%3ECall-Id%3A%20dfeb9b46-4de2-4cbd-a6ec-fee2d527c833%3CBR%20%2F%3EContact%3A%20%22%26lt%3B%22sip%3Aapi-du-b-euwe.pstnhub.microsoft.com%3A443%3Btransport%3Dtls%3Bx-i%3D07055b65-a904-4768-9aa8-cc862e28b518%3Bx-c%3D%2Fv1%2Fngc%2Fcall%2Fd620b0a22008514389800e30823e21d7%2Fs%2F1%2F0be3272839bd4aa0944084e9a0ad45a4%22%26gt%3B%22%3CBR%20%2F%3EContent-Length%3A%200%3CBR%20%2F%3ECseq%3A%203%20REFER%3CBR%20%2F%3EFrom%3A%20%22%26lt%3B%22sip%3A%2B41445203631%40sip.pstnhub.microsoft.com%22%26gt%3B%22%3Btag%3D4b85270aa7b246e388c532f96fb6662c%3CBR%20%2F%3EMax-Forwards%3A%2070%3CBR%20%2F%3ERefer-To%3A%20%22%26lt%3B%22sip%3Asip.pstnhub.microsoft.com%3A5061%3Btransport%3Dtls%3Bx-m%3D8%3Asfb%3A9de069dc-faac-54d5-26e4-2615f37bda97%22%26gt%3B%22%3CBR%20%2F%3EReferred-By%3A%20%22%26lt%3B%22sip%3Asip.pstnhub.microsoft.com%3A5061%3Bx-m%3D8%3Aorgid%3A76606d0b-4d28-4246-9c08-2a0f95f96141%3Bx-t%3D4bffbf87-53a0-4fce-b58b-4179cb3a3b7d%3Bx-ti%3D07055b65-a904-4768-9aa8-cc862e28b518%3Bx-tt%3DaHR0cHM6Ly9hcGktZHUtYi1ldXdlLnBzdG5odWIubWljcm9zb2Z0LmNvbS92MS9uZ2MvY2FsbG5vdGlmaWNhdGlvbj9kY2k9ODVjMTRiYzNhNTZjNGRhZjkxY2Y2MDg1NDdlYzY5YzA%253D%22%26gt%3B%22%3CBR%20%2F%3ETo%3A%20%22%26lt%3B%22sip%3A%2B41788578660%40sbc.mozzism.ch%3A5999%3Btransport%3Dtls%3Bmaddr%3D172.16.1.12%22%26gt%3B%22%3Btag%3D884f0b5e-37b4-4d90-924f-b9e73f645362%3CBR%20%2F%3EUser-Agent%3A%20Microsoft.PSTNHub.SIPProxy%20v.2019.7.4.9%20i.EUWE.1%3CBR%20%2F%3EVia%3A%20SIP%2F2.0%2FTLS%2052.114.75.24%3A5061%3Breceived%3D52.114.75.24%3Bbranch%3Dz9hG4bK8164e79b%3CBR%20%2F%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDoes%20anybody%20have%20an%20idea%2C%20why%203pip%20Phones%20or%20SfB%20Client%20for%20that%20matter%20(i%20know%20it's%20not%20supported%20but%20if%203pip%20should%20work%2C%20the%20SfB%20Client%20should%20also%20work)%20does%20not%20send%20a%20Refer%20to%20number%20to%20our%20SBC%3F%20Or%20is%20there%20anyone%20around%20who%20can%20test%20it%20and%20tell%20me%20if%20it's%20working%20with%20their%20SBC%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3Emozzie%3C%2FP%3E%3CLINGO-SUB%20id%3D%22lingo-sub-786749%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-786749%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F386416%22%20target%3D%22_blank%22%3E%40mozziemozz%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAre%20you%20typing%20in%20full%20E.164%20external%20number%3F%20I%20have%20an%20issue%20with%20SFB%20where%20it's%20not%20sending%20calls%20to%20SBC%20unless%20I%20type%20in%20full%20'%2B44XXXXX'%20number%20even%20though%20Teams%20works%20fine%20with%20local%20numbers%20starting%20with%20'0'%20or%20any%20other%20number%20because%20we%20have%20'.*'%20VoiceRoute%20configured.%20Can't%20figure%20out%20why%20it's%20doing%20so%2C%20cooperation%20mode%20is%20set%20to%20Islands%20and%20SFB%20can%20send%20and%20receive%20calls%20but%20only%20when%20using%20full%20E.164%20numbers.%20Some%20MS%20built-in%20normalization%20rules%20for%20the%20country%20are%20kicking%20in%20by%20the%20looks%20of%20it.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-786756%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-786756%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F386416%22%20target%3D%22_blank%22%3E%40mozziemozz%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAlso%2C%20maybe%20your%20SBC%20has%20a%20rule%20to%20remove%20Refer-To%20header%20and%20sometimes%20that%20rule%20is%20applied%20by%20incorrectly%20configured%20Match%20policy%3F%20Have%20you%20tried%20sniffing%20traffic%20and%20decoding%20TLS%20to%20see%20the%20actual%20SIP%20packet%20coming%20from%20MS%20before%20it's%20handled%20by%20SBC%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-786770%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-786770%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3Bfor%20me%20it%20doesn't%20make%20a%20difference%20if%20the%20number%20starts%20with%20%2B4144%20or%20044.%20from%20the%20looks%20of%20it%2C%20the%20normalization%2Ftranslation%20of%20the%20number%20works%20fine%20with%20the%20SfB%20Client%20too.%20Also%20works%20when%20just%20dialing%20044%20(national%20format)%20instead%20of%20transferring.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDoes%20it%20work%20for%20you%20when%20you%20enter%20full%20E.164%20with%20the%20SfB%20Client%20or%203PIP%20Phone%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-786783%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-786783%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3BI%20don't%20think%20that%20the%20SBC%20removes%20the%20refer%2C%20because%20when%20I%20do%20it%20via%20the%20Teams%20Client%2C%20everything%20works%20fine.%20If%20I%20disable%20Referred-By%20on%20the%20SBC%20transfers%20stop%20working%2C%20even%20internal%20Teams%20Transfers.%20I'm%20not%20sure%20who%20to%20do%20TLS%20sniffing%20and%20decoding.%20What%20do%20I%20need%20to%20do%3F%20Run%20wireshark%20while%20i%20transfer%20and%20filter%20for%20TLS%2FTCP%20packets%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-786784%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-786784%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F386416%22%20target%3D%22_blank%22%3E%40mozziemozz%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt's%20not%20that%20easy%2C%20you%20will%20need%20your%20SSL%20certificate%20and%20private%20key%20in%20order%20to%20decrypt%20the%20traffic%2C%20you%20need%20to%20google%20about%20that.%20But%20maybe%20you%20just%20disable%20REFER%20support%20like%20we%20did%3F%20That's%20much%20simpler%20and%20works%20much%20better%20and%20requires%20less%20rules%20on%20SBC%20to%20make%20calls%20work.%20Just%20strip%20'REFER'%20from%20any%20'Allow%3A'%20header%20coming%20from%20SBC%20on%20requests%20and%20responses.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-812905%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-812905%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376841%22%20target%3D%22_blank%22%3E%40Lt_Flash%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20turned%20out%2C%20that%20there%20was%20in%20fact%20something%20wrong%20with%20how%20Microsoft%20%2F%203PIP%20SfB%20Phones%20sent%20the%20refer%20to%20our%20SBC.%20(Our%20SBC%20did%20not%20receive%20a%20refer-to%20number)%20Microsoft%20has%20now%20fixed%20the%20issue%20and%20we%20can%20correctly%20transfer%20calls%20to%20external%20numbers%20via%20the%20Teams%20Desktop%20Client%20and%203PIP%20Modes%20with%20users%20in%20TeamsOnly%20mode.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-816342%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-816342%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F386416%22%20target%3D%22_blank%22%3E%40mozziemozz%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20mate%2C%3C%2FP%3E%3CP%3EGood%20to%20know%20it's%20all%20fixed!%20Yes%2C%20the%20biggest%20problem%20when%20dealing%20with%20Microsoft%20is%20that%20you%20never%20know%20if%20that's%20an%20issue%20with%20your%20phone%20or%20software%20or%20with%20their%20end.%20I%20was%20speaking%20to%20their%20official%20support%20as%20we%20are%20an%20official%20partner%20and%20all%20I%20got%20in%20the%20end%20was%20'Please%20post%20into%20our%20techcommunity'.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-847075%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-847075%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECan%20you%20post%20how%20to%20do%20message%20manipulation%20to%20re-build%20the%20allow%20header%20for%20this%20on%20AudioCodes%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-848127%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-848127%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F30375%22%20target%3D%22_blank%22%3E%40Jason%20Turpin%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESure%20-%20here%20it%20is%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EAction%20Subject%20-%26nbsp%3BHeader.Allow%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EAction%20Type%20-%20Modify%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EAction%20Value%20-%26nbsp%3B'PUBLISH%2CMESSAGE%2CUPDATE%2CPRACK%2CSUBSCRIBE%2CINFO%2CNOTIFY%2CREGISTER%2COPTIONS%2CBYE%2CINVITE%2CACK%2CCANCEL'%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EYou%20can%20strip%20out%20any%20method%20you%20like%20or%20match%20what%20Microsoft%20send%20in%20their%20messages%20if%20you'd%20like.%20Its%20working%20fine%20for%20me%20with%20these.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3ERegards%2C%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ESim%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-848140%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-848140%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EYep%2C%20works%20pretty%20much%20same%20way%20for%20me%2C%20even%20though%20right%20now%20I'm%20not%20using%20AudioCodes%20any%20more.%20And%20I'm%20analyzing%20each%20Allow%20string%20to%20strip%20only%20REFER%20from%20it%20instead%20of%20replacing%20Allow%20with%20generic%20one%20that%20allows%20everything.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-851396%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-851396%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EJust%20from%20curiosity%2C%20do%20you%20use%20mediabypass%20already%3F%3C%2FP%3E%3CP%3EI%20have%20encountered%20interesting%20issue%20which%20is%20causing%20on%20PSTN%20calls%20to%20Teams%20user%20over%20SBC%20and%20transferred%20to%20my%20internal%20PBX%20extension%20or%20external%20number%20simply%20No%20Audio.%26nbsp%3B%3C%2FP%3E%3CP%3EHere%20is%20the%20call%20flow%20-%20PSTN%20-%20myPBX%20-%20SBC%20-%20Teams%20user%20REFER-%20SBC%20-%20myPBX%20-%20phone%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOnce%20I%20manipulated%20my%20SBC%20that%20Microsoft%20takes%20care%20about%20sending%20re-Invite%20instead%20of%20REFER%20it%20sends%20new%20Invite%20as%20you%20observe%20BUT%20obviously%20as%20media%20source%20it%20uses%20the%20public%20IP%20of%20my%20SBC%20in%20the%20initial%20offer%20(it%20simply%20takes%20the%20info%20from%20original%20session%20leg).%3C%2FP%3E%3CP%3EMy%20SBC%20is%20behind%20NAT.%20Properly%20configured.%26nbsp%3B%20And%20it%20does%20not%20recognize%20that%20this%20new%20Invite%20is%20dedicated%20to%20media%20channel%20reserved%20already%20on%20the%20SBC%20%3A)%3C%2Fimg%3E%26nbsp%3B%20so%20it%20attempts%20to%20establish%20new%20channel%20between%20private%20IP%20and%20public%20IP%20of%20its%20own%20interface%20-sending%20the%20media%20out%20to%20its%20own%20public%20IP%20-%20which%20is%20then%20visible%20on%20our%20firewall%20as%20traffic%20that%20is%20dropped.%20Even%20if%20I%20allow%20this%20traffic%20between%20private%20IP%20to%20public%20IP%20of%20the%20same%20interface%20it%20would%20cause%20flow%20which%20does%20not%20make%20sense%20at%20all.%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20mediabypass%20is%20not%20used%20then%20it%20is%20fine%2C%20also%20for%20Teams%20caller%20transferred%20to%20myPBX.%20Just%20in%20case%20it%20is%20PSTN%20caller%20transfered%20back%20to%20SBC.%20(same%20problem%20occures%20also%20once%20the%20Teams%20user%20set%20Forwarding%20to%20his%20mobile%20for%20example...call%20connected%20but%20no%20audio)%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-851551%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-851551%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F263389%22%20target%3D%22_blank%22%3E%40DaveChomi%3C%2FA%3E%26nbsp%3B-%20Not%20I'm%20not%20using%20media%20bypass.%20If%20I%20have%20to%20be%20honest%2C%20I%20fail%20to%20see%20the%20benefits%20of%20media%20bypass.%20High%20bandwidth%20data%20line%20prices%20have%20dramatically%20decreased%20over%20the%20last%20couple%20of%20years%2C%20so%20by%20using%20media%20bypass%20you%20just%20save%20Microsoft%20a%20tone%20of%20bandwidth%20and%20infrastructure%20within%20their%20DCs%2C%20which%20I'm%20more%20than%20sure%20they%20have%20the%20money%20to%20pay%20for%20and%20maintain%20anyway.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMedia%20bypass%20would%20probably%20work%20in%20your%20model%20for%20a%20simple%20Teams%20-%26gt%3B%20SBC%20-%26gt%3B%20PSTN%20or%20other%20way%20around%20model%2C%20when%20you%20start%20hair-pinning%20both%20legs%20of%20the%20call%20(existing%20and%20transfer)%20through%20existing%20infrastructure%20like%20your%20SBC%20and%20PBX%20you're%20just%20asking%20for%20trouble.%20I'd%20just%20disable%20media%20bypass%20if%20I%20were%20you%2C%20unless%20you're%20really%20struggling%20for%20bandwidth.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards%2C%3C%2FP%3E%3CP%3ESim%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-853422%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-853422%22%20slang%3D%22en-US%22%3EI%20got%20your%20point.%20%3A)%3C%2Fimg%3E%20It's%20just%20about%20reasonable%20routing%20of%20calls%20also%20to%20internal%20infrastructure%20and%20trying%20to%20keep%20media%20path%20short%20from%20central%20sip%20services%20towards%20clients.%20So%20far%20it%20really%20brings%20headaches%20to%20me%20but%20also%20it%20brought%20better%20quality%20of%20calls%20so%20I%20have%20seen%20benefit%20in%20get%20over%20the%20pain%20to%20make%20proper%20setup.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-857266%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-857266%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F263389%22%20target%3D%22_blank%22%3E%40DaveChomi%3C%2FA%3E%26nbsp%3BThat's%20very%20interesting%20I%20guess%20it%20really%20depends%20on%20what%20your%20deployment%20looks%20like.%26nbsp%3B%20We%20do%20more%20of%20a%20multi-tenanted%20carrier%20deployment%20in%20which%20RTP%20would%20never%20leave%20the%20customer%20LAN%20for%20internal%20calls%20and%20for%20external%20calls%20it%20would%20always%20go%20from%20the%20Customer%20LAN%20%26lt%3B-%26gt%3B%20MS%20%26lt%3B-%26gt%3B%20us.%20If%20you've%20deployed%20an%20enterprise%20model%2C%20where%20your%20SBC%20is%20deployed%20within%20your%20LAN%20there%20really%20is%20no%20point%20in%20flinging%20media%20packets%20all%20the%20way%20to%20MS%20just%20to%20receive%20them%20back%20to%20your%20LAN%20and%20then%20send%20them%20out%20again%20via%20your%20SBC.%20I%20can%20see%20how%20that%20can%20have%20an%20impact%20on%20quality.%26nbsp%3B%3C%2FP%3E%3CP%3ECan%20you%20share%20the%20syslog%20for%20a%20call%20like%20that%20from%20the%20AudioCodes%20SBC%3F%20I'd%20be%20very%20interested%20to%20see%20what%20its%20doing%20hone%20its%20trying%20to%20negotiate%20the%20call%20transfer%20leg.%3CBR%20%2F%3E%3CBR%20%2F%3ERegards%2C%3C%2FP%3E%3CP%3ESim%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-866943%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-866943%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20provide%20later%20the%20syslog%2C%20just%20do%20not%20want%20to%20publish%20all%20our%20IP%20addresses%20etc.%20on%20forum%3C%2FP%3E%3CP%3ECurrently%20if%20I%20set%20our%20SBC%20to%20handle%20all%20REFERs%20locally%20it%20simply%20takes%20REFER%20from%20Teams%2C%20SBC%20accept%20and%20sends%20new%20Invite%20to%20Teams.%20Teams%20takes%20that%20and%20create%20new%20SIP%20call%20where%20as%20source%20IP%20for%20media%20presents%20public%20IP%20of%20our%20SBC.%20This%20call%20will%20come%20as%20new%20SIP%20call%20to%20our%20SBC%20and%20SBC%20simply%20tries%20to%20connect%20media%20between%20private%20IP%20and%20public%20IP%20of%20our%20WAN%20interface.%20And%20this%20is%20failing%20basically%20because%20SBC%20sends%20the%20traffic%20to%20its%20own%20public%20IP%20through%20WAN%20interface%20out%20of%20the%20SBC.%20There%20is%20then%20firewall%20which%20is%20dropping%20that%20from%20obvious%20reason.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-866948%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-866948%22%20slang%3D%22en-US%22%3E%3CP%3EScreenshots%20are%20basically%20refering%20to%20call%20from%20%2B420702XXXXXX%20to%20Teams%20user%20on%20number%20%2B420544137XXX%20which%20was%20transffered%20to%20%2B420723XXXXXX.%3C%2FP%3E%3CP%3ENew%20call%20is%20visible%20on%20SBC.%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20on%20that%20second%20call%20the%20SBC%20refers%20to%20Teams%20hey%20the%20media%20are%20on%20my%20public%20IP%20and%20Teams%20refers%20hey%20and%20I%20have%20media%20on%20your%20public%20IP.%20%3A)%3C%2Fimg%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-921219%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-921219%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%2C%26nbsp%3B%20We%20are%20having%20a%20similar%20transfer%20issue%20and%20I%20see%20you%20have%20the%20Audiocodes%20syntax%20to%20remove%20this%20in%20the%20ALLOW%20header.%26nbsp%3B%20Any%20chance%20you%20could%20send%20this%20across%20so%20I%20can%20try%20this%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3E'No%2C%20not%20by%20rejecting%20the%20REFER%20with%20a%20response%20code.%20I%20basically%20did%20a%20message%20manipulation%20rule%20to%20re-build%20the%20Allow%20header%20for%20calls%20to%20MS%20Teams%20without%20including%20REFER.%20Which%20vendor%20are%20you%20using%3F%20If%20you%20have%20an%20AudioCodes%20as%20well%2C%20I%20can%20give%20you%20the%20rule%20syntax.'%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3ECheers%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EDarren%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-961653%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-961653%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F166350%22%20target%3D%22_blank%22%3E%40Darren%20Ellis%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHave%20you%20setup%20on%20the%20opposite%20trunk%20(IP%20Profile%20for%20provider%20SIP%20trunk%20or%20your%20internal%20PBX%20not%20Teams%20side)%20Handle%20Locally%20of%20the%20REFER%20messages%3F%3C%2FP%3E%3CP%3EThis%20will%20do%20the%20same%20job%20basically%20and%20you%20do%20not%20need%20this%20special%20manipulation%20which%20I%20personally%20consider%20as%20too%20much%20because%20it%20does%20not%20give%20you%20any%20chance%20then%20manipulate%20REFER%20messages.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20for%20IP%20profile%20of%20the%20SIP%20trunk%20towards%20your%20provider%2Fon-prem%20PBX%3C%2FP%3E%3CP%3EI%20would%20setup%20these%20parameters%20on%20Audiocodes%20SBC%3C%2FP%3E%3CTABLE%3E%3CTBODY%3E%3CTR%3E%3CTD%3ERemote%20REFER%20Mode%3C%2FTD%3E%3CTD%3EHandle%20Locally%3C%2FTD%3E%3CTD%3E%26nbsp%3B%3C%2FTD%3E%3C%2FTR%3E%3CTR%3E%3CTD%3ERemote%20Replaces%20Mode%3C%2FTD%3E%3CTD%3EHandle%20Locally%3C%2FTD%3E%3CTD%3E%26nbsp%3B%3C%2FTD%3E%3C%2FTR%3E%3CTR%3E%3CTD%3EPlay%20RBT%20To%20Transferee%3C%2FTD%3E%3CTD%3EYes%3C%2FTD%3E%3CTD%3E%26nbsp%3B%3C%2FTD%3E%3C%2FTR%3E%3CTR%3E%3CTD%3ERemote%203xx%20Mode%3C%2FTD%3E%3CTD%3EHandle%20Locally%3C%2FTD%3E%3C%2FTR%3E%3C%2FTBODY%3E%3C%2FTABLE%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-961727%22%20slang%3D%22en-US%22%3ERe%3A%20MS%20Teams%20Direct%20Routing%20-%20Internal%20call%20transfer%20failure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-961727%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F376486%22%20target%3D%22_blank%22%3E%40Sims_Krastev%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%2C%20in%20meantime%20I%20got%20this%20resolved.%26nbsp%3B%3C%2FP%3E%3CP%3EIt's%20basically%20correct%20behavior%20that%20Microsoft%20sends%20public%20IP%20of%20my%20SBC%20as%20source%20of%20media%20on%20new%20call%20leg%20for%20that%20transferred%20call%2C%20while%20mediabypass%20is%20enabled.%20It%20just%20really%20require%20that%20you%20will%20setup%20enterprise%20firewall%20to%20communicate%20from%20NATed%20private%20IP%20to%20its%20own%20public%20IP%20and%20loopback%20this%20communication.%20This%20is%20what%20basically%20SBC%20does%2C%20Sends%20the%20media%20stream%20from%20its%20own%20private%20IP%20to%20its%20own%20public%20IP%20and%20expects%20the%20media%20back%20%3A)%3C%2Fimg%3E%26nbsp%3B%20So%20it%20is%20very%20ugly%20hairpin%20on%20firewall%20even%20not%20documented%20in%20firewall%20prerequisites.%20I%20would%20say%20SBC%20should%20have%20some%20logic%20to%20handle%20this%20by%20itself%20by%20as%20long%20as%20this%20is%20the%20only%20way%20we%20need%20to%20make%20security%20guys%20believe%20this%20is%20absolutely%20normal%20request%20%3A)%3C%2Fimg%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Sims_Krastev
Occasional Contributor

Hi all,

 

My organisation is planning a move to direct routing. We have an AudioCodes VE SBC. I've been working on this for awhile and got everything to a pretty decent state.

 

I've come across an issue which is fairly new as I remember testing this months ago, when I was still trying to figure out how to deal with REFERs coming from MS Teams on call transfers.

 

So the call flow is as follows:

Incoming call from SBC to MS Teams -> MS Teams user transfers the call to internal user -> Call fails as MS Teams generates a REFER back to the SBC rather than route the call internally to MS Teams user target.

The issue I'm observing aside from MS Teams routing the transfer leg of the call is that the REFER-TO user part of the URI is blank. Please see the attached screenshot.

Its as if MS Teams is treating this as an external transfer and does not know how to populate the user part of the REFER-TO header. I've tested this with both users set up with Phone system and DDIs assigned to the user and users which have no phone system add-on or assigned DDI.

Please note that if you tried to transfer the call to a PSTN number, that works fine. I'm unsure if this would be something config related within our Teams tenancy or a genuine bug. I'm more inclined that this is the former rather than the latter as it does seem like fairly basic functionality and I'm confident this used to work a few months ago.

Any advice would be appreciated.

Kind Regards,

Sim

38 Replies

Hi Sim,

We've got exactly the same behaviour when trying to transfer calls that came from PSTN network and got answered by one of our Teams users and when they try to transfer to another Teams user. REFER-TO doesn't contain any LineURI or telephone number to complete the transfer. Did you have any luck fixing this issue? Also, I'm not sure if this was working before or not. But you seem to be correct in regards to Teams treating internal transfer as external one and sending SIP REFER back to SBC without providing any additional details in regards where the call should be actually connected or transferred to. When transferring to external number this works perfectly fine, REFER-TO contains an external number and can be processed by our SBC. BTW, can you tell what SBC are you using? Is it AudioCodes or Ribbon one? Or something not currently certified by Microsoft? Thanks!

@Lt_Flash We're using AudioCodes, and config wise its fine. It handles REFERs just fine. The issue here is that MS Teams should never had sent this REFER out the SBC, it should have handled it within the Teams environment as its a transfer from one Teams user to another. This only thing I suspect config wise is voice route regex I'm using, as its pretty much a catch all e.g. ".*" 
I've now made it more strict to capture digit patterns rather than all chars to see if the issue persists.

It makes no sense as I can call users internally, it only happens when PSTN call comes in from the direct Routing SBC, so Teams appears to be applying a different call routing logic when applying the transfer.

 

Out of curiosity can you let me know what your voice route pattern looks like? Was it a catch all like mine or is it more strict?

 

Thanks,

Sim

@Sims_Krastev 

Yes, I'm using the same voice pattern, ".*" to send all digits without any normalization to our SIP trunk. You're right, maybe the issue is because of that, I will update voice rules tomorrow to make it strictly country-based, like '^+44.*' to see if that helps! Good point, mate!

 

Also, yes, SIP REFER shouldn't be coming back to PBX when we're doing an internal transfer from one Teams User to another one, but it does for some reason, that's the problem.

I'll let you know here how it goes and thanks for your reply!

@Sims_Krastev 

Hi Sims,

I've removed the ".*" rule from my installation and created all specific rules for DIDs and still no luck, I can see SIP REFER coming back to PBX when I'm trying to transfer call that came from PSTN to Teams user. No luck here, unfortunately. Did you have any luck with this? Thanks.

@Lt_Flash I had no luck with changing the voice route, so ended up raising it with MS support.

Apparently if you disable REFER as an allowed method within your SBC's signalling messages, then MS Teams does not use REFER for transfers and just re-INVITEs to the SBC. That way the internal transfers work perfectly fine.

 

How did you disable REFER? I mean - does your SBC sends some 4xx code when MS sends a SIP REFER message? Or somehow different? Thanks!

@Lt_Flash 

No, not by rejecting the REFER with a response code. I basically did a message manipulation rule to re-build the Allow header for calls to MS Teams without including REFER. Which vendor are you using? If you have an AudioCodes as well, I can give you the rule syntax.

 

 

No, we're using a custom SBC, but yes, that was my second guess - to strip REFERs from packets. Thanks a lot, I'll give it a go and let you know if it works for me!

@Sims_Krastev you seem to be correct! I've just edited all messages that were coming from PSTN side of our SBC and stripped 'REFER' on SBC in 'Allow' field - and yes, Microsoft started to transfer calls correctly! Thanks a lot, mate, I've already read that disabling SIP REFER method helped some people, but I was trying to reply with 4xx or 5xx when receiving REFER from MS side, while I should have just removed that REFER method from SIP 'Allow' list! By the way, looking at the packets coming from Microsoft side I can see that they don't send REFER in allowed method list! Here's an example:

CONTENT-LENGTH: 685
MIN-SE: 90
SUPPORTED: timer
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2019.7.4.9 i.USWE2.4
CONTENT-TYPE: application/sdp
ALLOW: INVITE
ALLOW: ACK
ALLOW: OPTIONS
ALLOW: CANCEL
ALLOW: BYE
ALLOW: NOTIFY
SESSION-EXPIRES: 1800;refresher=uas

Thanks again for your help and I'm glad everything is working fine for you too now!

@Lt_Flash 

 

I can confirm this behavior, just that REFER triggered transfer is most common way for it and only fully standardized one. If your SBC is capable to terminate REFER note that MS still clearly indicates in Refer-To where to send INVITE back: 

REFER-TO: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689</sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>
</sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>

 

  and making sure you fill RURI with Refer-To and Contact uri-host correctly you will see MS does rest of the job nicely for REFER case too.  

@Matej_Maric 

 

It shows where to send INVITE to, but it doesn't have a DID or username in SIP R-URI so SBC can't figure out where to dial to. SBC uses PSTN-type dialing, so it needs some LineURI or DID to send INVITE to, like +44XXXXXXXX@sip.pstnhub.microsoft.com. Otherwise it can't decide what to put in SIP INVITE method as 'To' field. I've tried to update SIP INVITE to whatever is in REFER-TO header and send it back to Microsoft, but I was getting a 400 Bad Request back.

 

REFER-TO: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689</sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>

 

There's no user part in this SIP RURI, only host. What should be put in To header? Contact header is obvious, it's our SBC Contact.

@Lt_Flash 

 

the thing is that SBC should only respect Refer-to header by means of SIP. REFER comes without user part but it's still fair enough and legal. So what my SBC does as last resort to send INVITE out is DNS query for hostname in Refer-To and fills RURI and To in same fashion:

 

INVITE sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.65.100:5061;branch=z9hG4bKvahihb0040adpr8tb320.1
CSeq: 1 INVITE
Contact: <sip:sbc.customers.matejandfriends.com:5061;transport=tls>;sip.ice
From: <sip:+18572996345@sip.pstnhub.microsoft.com:5060;user=phone>;tag=11241SIPpTag011
To: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>
Content-Type: application/sdp
Content-Length: 425
Referred-By: <sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:bdc0511a-4a8d-48aa-bf1d-5ea6ef316e2a;x-t=2d88cb42-f810-417a-a0fc-80244a7fdd61;x-ti=9cfa2ad6-c73e-402d-b621-90d9af6ffea2;x-tt=ahr0chm6ly9hcgktzhutys1ldxdllnbzdg5odwiubwljcm9zb2z0lmnvbs92ms9uz2mvy2fsbg5vdglmawnhdglvbj9ky2k9yje2odmxntuwyjuwndg3mzk4nja4ndhlmgflyznimwq%3d>
Call-ID: 8f09e11d9183f754c525a0d4ce2aea46
Supported: replaces
Max-Forwards: 70</sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:bdc0511a-4a8d-48aa-bf1d-5ea6ef316e2a;x-t=2d88cb42-f810-417a-a0fc-80244a7fdd61;x-ti=9cfa2ad6-c73e-402d-b621-90d9af6ffea2;x-tt=ahr0chm6ly9hcgktzhutys1ldxdllnbzdg5odwiubwljcm9zb2z0lmnvbs92ms9uz2mvy2fsbg5vdglmawnhdglvbj9ky2k9yje2odmxntuwyjuwndg3mzk4nja4ndhlmgflyznimwq%3d></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:+18572996345@sip.pstnhub.microsoft.com:5060;user=phone></sip:sbc.customers.matejandfriends.com:5061;transport=tls> 

 

and that's just enough...

obviously we dont use same vendor SBC but standard wise logic should remain the same

@Matej_Maric 

Thanks for detailed description, I will try to reproduce this behaviour on my SBC, but it looks really strange to me that MS sends a SIP REFER packet back to SBC that connects calls to PSTN and uses LineURI telephone numbers for that. According to RFC it should provide a proper username or DID in such case. From what I can see now it's much simpler to just disallow REFER method and let Microsoft Teams handle internal call transfers on their side, which is more logical, rather than implementing such call forking. Anyway, your help is much appreciated and SIP INVITE packet is a perfect example on what I should try to achieve. Thanks!

@Matej_Maric 

Hi,

Unfortunately, that doesn't work for me, I'm sending same INVITE packet as you do but I'm getting back a '400 Bad Request' with a REASON:

REASON: Q.850;cause=111;text="a5d458f9-14c0-4cc4-8c10-202277af11e9;Unable to parse RURI."

@Matej_Maric 

 

Here's my INVITE packet, I had to remove triangle brackets to make post clear:

 

INVITE sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:7709b36f-1f10-4b1c-8a0f-9c0e5390c86c SIP/2.0

Via: SIP/2.0/TLS X.X.X.X:5061;branch=z9hG4bKf26f.503bdc4.0;i=54849946

From: "XXXXXXX";tag=a1d8a1ca-d330-4251-811d-35fa1a797c64&;

To: sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:7709b36f-1f10-4b1c-8a0f-9c0e5390c86c

Call-ID: 1fa2f0d0-ba41-4e4d-83be-fbef9d0739c6

CSeq: 10432 INVITE

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER

Supported: 100rel, timer, replaces, norefersub

Session-Expires: 1800

Min-SE: 90

Max-Forwards: 69

Content-Type: application/sdp

Content-Length: 346

Contact: sip:gateway@sbc.xxx.xxx.com:5061;transport=TLS

 

@Matej_Maric 

All right, just to clarify, I've got this sorta working, I was removing REFERRED-BY header when placing a new INVITE and that's why it couldn't connect the call, after leaving that header intact the call can be transferred. But this far for us it's much easier just to remove REFER method from the list of allowed methods, otherwise it's quite a complex setup with our SBC. Thanks everyone for replies, now we have two working methods that allow call to be transferred to internal MS Teams users!

@Lt_Flash 

 

yep, tend to be with you on conclusions. being forced to implement both in real life felt like sharing things people find useful :) Most important is we understand now how to implement both methods and logic MS uses to trigger each.

 

cheers!

@Sims_Krastev 

 

Hi for us it's the other way around. Internal calls transfer perfectly fine and transfer to PSTN only works via the Teams Client. We do use some 3PIP Phones from AudioCodes, Yealink and Poly and if we try to transfer a call to an external Number, our SBC does not receive a refer-to number.

 

Now i have heard from someone, that their AudioCodes SBC receives this from Number even when it's coming from a 3PIP Phone.

 

Does anybody have an idea, why 3pip Phones or SfB Client for that matter (i know it's not supported but if 3pip should work, the SfB Client should also work) does not send a Refer to number to our SBC? Or is there anyone around who can test it and tell me if it's working with their SBC?

 

Thanks,

mozzie

@mozziemozz 

Are you typing in full E.164 external number? I have an issue with SFB where it's not sending calls to SBC unless I type in full '+44XXXXX' number even though Teams works fine with local numbers starting with '0' or any other number because we have '.*' VoiceRoute configured. Can't figure out why it's doing so, cooperation mode is set to Islands and SFB can send and receive calls but only when using full E.164 numbers. Some MS built-in normalization rules for the country are kicking in by the looks of it.

@mozziemozz 

Also, maybe your SBC has a rule to remove Refer-To header and sometimes that rule is applied by incorrectly configured Match policy? Have you tried sniffing traffic and decoding TLS to see the actual SIP packet coming from MS before it's handled by SBC?

@Lt_Flash for me it doesn't make a difference if the number starts with +4144 or 044. from the looks of it, the normalization/translation of the number works fine with the SfB Client too. Also works when just dialing 044 (national format) instead of transferring.

 

Does it work for you when you enter full E.164 with the SfB Client or 3PIP Phone?

@Lt_Flash I don't think that the SBC removes the refer, because when I do it via the Teams Client, everything works fine. If I disable Referred-By on the SBC transfers stop working, even internal Teams Transfers. I'm not sure who to do TLS sniffing and decoding. What do I need to do? Run wireshark while i transfer and filter for TLS/TCP packets?

@mozziemozz 

It's not that easy, you will need your SSL certificate and private key in order to decrypt the traffic, you need to google about that. But maybe you just disable REFER support like we did? That's much simpler and works much better and requires less rules on SBC to make calls work. Just strip 'REFER' from any 'Allow:' header coming from SBC on requests and responses.

@Lt_Flash 

It turned out, that there was in fact something wrong with how Microsoft / 3PIP SfB Phones sent the refer to our SBC. (Our SBC did not receive a refer-to number) Microsoft has now fixed the issue and we can correctly transfer calls to external numbers via the Teams Desktop Client and 3PIP Modes with users in TeamsOnly mode.

@mozziemozz 

Hi mate,

Good to know it's all fixed! Yes, the biggest problem when dealing with Microsoft is that you never know if that's an issue with your phone or software or with their end. I was speaking to their official support as we are an official partner and all I got in the end was 'Please post into our techcommunity'.

@Sims_Krastev 

Can you post how to do message manipulation to re-build the allow header for this on AudioCodes?

@Jason Turpin 

Sure - here it is:

 

Action Subject - Header.Allow

Action Type - Modify

Action Value - 'PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL'

 

You can strip out any method you like or match what Microsoft send in their messages if you'd like. Its working fine for me with these.

 

Regards,

Sim

@Sims_Krastev 

Yep, works pretty much same way for me, even though right now I'm not using AudioCodes any more. And I'm analyzing each Allow string to strip only REFER from it instead of replacing Allow with generic one that allows everything.

Hi, @Sims_Krastev 

Just from curiosity, do you use mediabypass already?

I have encountered interesting issue which is causing on PSTN calls to Teams user over SBC and transferred to my internal PBX extension or external number simply No Audio. 

Here is the call flow - PSTN - myPBX - SBC - Teams user REFER- SBC - myPBX - phone

 

Once I manipulated my SBC that Microsoft takes care about sending re-Invite instead of REFER it sends new Invite as you observe BUT obviously as media source it uses the public IP of my SBC in the initial offer (it simply takes the info from original session leg).

My SBC is behind NAT. Properly configured.  And it does not recognize that this new Invite is dedicated to media channel reserved already on the SBC :)  so it attempts to establish new channel between private IP and public IP of its own interface -sending the media out to its own public IP - which is then visible on our firewall as traffic that is dropped. Even if I allow this traffic between private IP to public IP of the same interface it would cause flow which does not make sense at all. 

If mediabypass is not used then it is fine, also for Teams caller transferred to myPBX. Just in case it is PSTN caller transfered back to SBC. (same problem occures also once the Teams user set Forwarding to his mobile for example...call connected but no audio)

@DaveChomi - Not I'm not using media bypass. If I have to be honest, I fail to see the benefits of media bypass. High bandwidth data line prices have dramatically decreased over the last couple of years, so by using media bypass you just save Microsoft a tone of bandwidth and infrastructure within their DCs, which I'm more than sure they have the money to pay for and maintain anyway.

 

Media bypass would probably work in your model for a simple Teams -> SBC -> PSTN or other way around model, when you start hair-pinning both legs of the call (existing and transfer) through existing infrastructure like your SBC and PBX you're just asking for trouble. I'd just disable media bypass if I were you, unless you're really struggling for bandwidth.

 

Regards,

Sim

I got your point. :) It's just about reasonable routing of calls also to internal infrastructure and trying to keep media path short from central sip services towards clients. So far it really brings headaches to me but also it brought better quality of calls so I have seen benefit in get over the pain to make proper setup.

@DaveChomi That's very interesting I guess it really depends on what your deployment looks like.  We do more of a multi-tenanted carrier deployment in which RTP would never leave the customer LAN for internal calls and for external calls it would always go from the Customer LAN <-> MS <-> us. If you've deployed an enterprise model, where your SBC is deployed within your LAN there really is no point in flinging media packets all the way to MS just to receive them back to your LAN and then send them out again via your SBC. I can see how that can have an impact on quality. 

Can you share the syslog for a call like that from the AudioCodes SBC? I'd be very interested to see what its doing hone its trying to negotiate the call transfer leg.

Regards,

Sim

@Sims_Krastev 

I can provide later the syslog, just do not want to publish all our IP addresses etc. on forum

Currently if I set our SBC to handle all REFERs locally it simply takes REFER from Teams, SBC accept and sends new Invite to Teams. Teams takes that and create new SIP call where as source IP for media presents public IP of our SBC. This call will come as new SIP call to our SBC and SBC simply tries to connect media between private IP and public IP of our WAN interface. And this is failing basically because SBC sends the traffic to its own public IP through WAN interface out of the SBC. There is then firewall which is dropping that from obvious reason. 

Screenshots are basically refering to call from +420702XXXXXX to Teams user on number +420544137XXX which was transffered to +420723XXXXXX.

New call is visible on SBC. 

And on that second call the SBC refers to Teams hey the media are on my public IP and Teams refers hey and I have media on your public IP. :) 

 

@Sims_Krastev 

 

Hi,  We are having a similar transfer issue and I see you have the Audiocodes syntax to remove this in the ALLOW header.  Any chance you could send this across so I can try this?

 

'No, not by rejecting the REFER with a response code. I basically did a message manipulation rule to re-build the Allow header for calls to MS Teams without including REFER. Which vendor are you using? If you have an AudioCodes as well, I can give you the rule syntax.'

 

Cheers

Darren

@Darren Ellis 

Have you setup on the opposite trunk (IP Profile for provider SIP trunk or your internal PBX not Teams side) Handle Locally of the REFER messages?

This will do the same job basically and you do not need this special manipulation which I personally consider as too much because it does not give you any chance then manipulate REFER messages.

 

So for IP profile of the SIP trunk towards your provider/on-prem PBX

I would setup these parameters on Audiocodes SBC

Remote REFER ModeHandle Locally 
Remote Replaces ModeHandle Locally 
Play RBT To TransfereeYes 
Remote 3xx ModeHandle Locally

@Sims_Krastev 

Hi, in meantime I got this resolved. 

It's basically correct behavior that Microsoft sends public IP of my SBC as source of media on new call leg for that transferred call, while mediabypass is enabled. It just really require that you will setup enterprise firewall to communicate from NATed private IP to its own public IP and loopback this communication. This is what basically SBC does, Sends the media stream from its own private IP to its own public IP and expects the media back :)  So it is very ugly hairpin on firewall even not documented in firewall prerequisites. I would say SBC should have some logic to handle this by itself by as long as this is the only way we need to make security guys believe this is absolutely normal request :) 

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
46 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies
How to Prevent Teams from Auto-Launch
chenrylee in Microsoft Teams on
30 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
13 Replies