hosted Posted October 14, 2009 Report Share Posted October 14, 2009 when I receive a REFER I send an INVITE that looks normal. however the terminating company is expecting "REFERRED-BY: sip:Exch10.j.net;msExchUMFaxRecipient=smtp:matt%40j.net;msExchUMContext=Q2FsbElkPWQblah" to be in the INVITE message that was relayed from Exchange 2010 during the REFER.. is this normal? (to pass the REFERRED-BY) Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted November 10, 2009 Report Share Posted November 10, 2009 when I receive a REFER I send an INVITE that looks normal. however the terminating company is expecting "REFERRED-BY: sip:Exch10.j.net;msExchUMFaxRecipient=smtp:matt%40j.net;msExchUMContext=Q2FsbElkPWQblah" to be in the INVITE message that was relayed from Exchange 2010 during the REFER.. is this normal? (to pass the REFERRED-BY) No, this is not normal. Well, I would call this "MS-SIP"... I guess we need to spend some time to make the PBX compatible with Exchange (again). Not sure why Exchange needs this kind of information. Other products work fine with without special blows and whistles. Quote Link to comment Share on other sites More sharing options...
hosted Posted November 11, 2009 Author Report Share Posted November 11, 2009 This was a problem with one of MS2010's beta fax providers MS now detects FAX and refer's it to a fax provider. however it worked just fine to faxback. Quote Link to comment Share on other sites More sharing options...
ShadowAnt Posted December 22, 2009 Report Share Posted December 22, 2009 Hello. I have the same problem with Exchange 2010. Can you help me? here is a log from PBXnSIP: [7] 2009/12/22 10:08:40: SIP Rx tcp:1.1.7.8:5065: REFER sip:673;phone-context=casedp.tp.ru@1.1.1.5:61271;transport=tcp SIP/2.0 FROM: <sip:100@1.1.7.8;user=phone>;epid=5087CA71E1;tag=166eca107e TO: <sip:673;phone-context=casedp.tp.ru@pbx.case.ru;user=phone>;tag=32467 CSEQ: 1 REFER CALL-ID: ae194e46@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 1.1.7.8:5065;branch=z9hG4bK32e7574e CONTACT: <sip:s-caseexch.case.ru:5065;transport=Tcp;maddr=1.1.7.8;ms-opaque=9d5b0df1193bf2f9>;automata CONTENT-LENGTH: 0 REFER-TO: <sip:s-casedc2.case.ru:5060;transport=tcp> REFERRED-BY: <sip:s-caseexch.case.ru;msExchUMFaxRecipient=smtp:administrator%40case.ru;msExchUMContext=Q2FsbElkPWFlMTk0ZTQ2JTQwcGJ4JkV4dGVuc2lvbj1BZG1pbmlzdH JhdG9yJTQwY2FzZS5ydSZDYWxsZXJJZD02NzMmUGhvbmVDb250ZXh0PXBieGNhc2UudHAucnU%3D> USER-AGENT: RTCC/3.1.0.0 [7] 2009/12/22 10:08:40: SIP Tx tcp:1.1.7.8:5065: SIP/2.0 202 Accepted Via: SIP/2.0/TCP 1.1.7.8:5065;branch=z9hG4bK32e7574e From: <sip:100@1.1.7.8;user=phone>;tag=166eca107e;epid=5087CA71E1 To: <sip:673;phone-context=casedp.tp.ru@pbx.case.ru;user=phone>;tag=32467 Call-ID: ae194e46@pbx CSeq: 1 REFER Contact: <sip:673;phone-context=casedp.tp.ru@1.1.1.5:61271;transport=tcp> User-Agent: pbxnsip-PBX/3.4.0.3201 Content-Length: 0 [7] 2009/12/22 10:08:40: SIP Tx tcp:1.1.7.8:5065: NOTIFY sip:s-caseexch.case.ru:5065;transport=Tcp;maddr=1.1.7.8 SIP/2.0 Via: SIP/2.0/TCP 1.1.1.5:61271;branch=z9hG4bK-0c632ae61b0dd0e8800d76b28c7bf6d2;rport From: <sip:673;phone-context=casedp.tp.ru@pbx.case.ru;user=phone>;tag=32467 To: <sip:100@1.1.7.8;user=phone>;tag=166eca107e Call-ID: ae194e46@pbx CSeq: 14864 NOTIFY Max-Forwards: 70 Contact: <sip:673;phone-context=casedp.tp.ru@1.1.1.5:61271;transport=tcp> Subscription-State: terminated;reason=noresource Event: refer P-Asserted-Identity: "OCS Transit" <sip:100@1.1.7.8;user=phone> Content-Type: message/sipfrag Content-Length: 16 SIP/2.0 200 Ok [5] 2009/12/22 10:08:40: Redirecting call to [5] 2009/12/22 10:08:40: Call ae194e46@pbx#32467: Last request not finished [7] 2009/12/22 10:08:40: SIP Tx tcp:1.1.7.8:5065: BYE sip:s-caseexch.case.ru:5065;transport=Tcp;maddr=1.1.7.8 SIP/2.0 Via: SIP/2.0/TCP 1.1.1.5:61271;branch=z9hG4bK-81c75aab007c2aab28936c51530e6051;rport From: <sip:673;phone-context=casedp.tp.ru@pbx.case.ru;user=phone>;tag=32467 To: <sip:100@1.1.7.8;user=phone>;tag=166eca107e Call-ID: ae194e46@pbx CSeq: 14865 BYE Max-Forwards: 70 Contact: <sip:673;phone-context=casedp.tp.ru@1.1.1.5:61271;transport=tcp> RTP-RxStat: Dur=8,Pkt=381,Oct=65532,Underun=0 RTP-TxStat: Dur=8,Pkt=399,Oct=68628 P-Asserted-Identity: "OCS Transit" <sip:100@1.1.7.8;user=phone> Content-Length: 0 [7] 2009/12/22 10:08:41: SIP Rx tcp:1.1.7.8:5065: SIP/2.0 200 OK FROM: <sip:673;phone-context=casedp.tp.ru@pbx.case.ru;user=phone>;tag=32467 TO: <sip:100@1.1.7.8;user=phone>;tag=166eca107e;epid=5087CA71E1 CSEQ: 14864 NOTIFY CALL-ID: ae194e46@pbx VIA: SIP/2.0/TCP 1.1.1.5:61271;branch=z9hG4bK-0c632ae61b0dd0e8800d76b28c7bf6d2;rport CONTENT-LENGTH: 0 SERVER: RTCC/3.1.0.0 [7] 2009/12/22 10:08:41: SIP Rx tcp:1.1.7.8:5065: SIP/2.0 200 OK FROM: <sip:673;phone-context=casedp.tp.ru@pbx.case.ru;user=phone>;tag=32467 TO: <sip:100@1.1.7.8;user=phone>;tag=166eca107e;epid=5087CA71E1 CSEQ: 14865 BYE CALL-ID: ae194e46@pbx VIA: SIP/2.0/TCP 1.1.1.5:61271;branch=z9hG4bK-81c75aab007c2aab28936c51530e6051;rport CONTENT-LENGTH: 0 SERVER: RTCC/3.1.0.0 [5] 2009/12/22 10:08:41: BYE Response: Terminate ae194e46@pbx [7] 2009/12/22 10:08:41: Other Ports: 3 [7] 2009/12/22 10:08:41: Call Port: 105693580522122009787@1.1.1.100#038c986298 [7] 2009/12/22 10:08:41: Call Port: 16fc88ce@pbx#51471 [7] 2009/12/22 10:08:41: Call Port: a51a32d6-5452-4664-8556-38b4ec755e20#140fba3514 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 22, 2009 Report Share Posted December 22, 2009 [...]REFER-TO: <sip:s-casedc2.case.ru:5060;transport=tcp> [...] [5] 2009/12/22 10:08:40: Redirecting call to Sometime I don't know what Exchange wants... Redirect a call to a DNS name, and no username? I guess that does not go through the dialplan and then PBX does not know what to do with it... Quote Link to comment Share on other sites More sharing options...
ShadowAnt Posted December 22, 2009 Report Share Posted December 22, 2009 Sometime I don't know what Exchange wants... Redirect a call to a DNS name, and no username? I guess that does not go through the dialplan and then PBX does not know what to do with it... Microsoft answers me: I double checked the network trace and I found that the IP PBX sent the SIP NOTIFY and SIP BYE within the same package. This behavior is abnormal. Actually, the correct process should: 1. The UM server sends SIP REFER to the IP PBX. 2. The IP PBX sends "202 Accepted" to the UM server. 3. The IP PBX sends SIP INVITE to the fax server to build the connection and the sends the fax to the fax server over T.38 protocol. 4. After the fax is sent, the IP PBX sends SIP NOTIFY to the UM server. 5. The UM server responds the IP PBX with "200 OK". 6. The UM server sends SIP BYE to the IP PBX. 7. The IP BPX responds the UM server with "200 OK". At this point, since the IP PBX sends SIP NOTIFY to the UM server, I suggest you check whether the IP PBX sends IP INVITE to the fax server to build the connection and the sends the fax to the fax server over T.38 protocol. You may collect the network trace from IP PBX send to verify the behavior of the IP PBX. If anything is unclear, please feel free to post back. I look forward to hearing from you. Best Regards, Ryan Ye, MCSE 2003 Quote Link to comment Share on other sites More sharing options...
ShadowAnt Posted December 23, 2009 Report Share Posted December 23, 2009 So... what you can advise to do with dial plan to force PBXnSIP send SIP INVITE to Fax Server? P.S. and one more from Microsoft: I understand that the IP PBX support said that the UM server did not include a user name in the SIP REFER. Actually, the UM server did include the e-mail address of the user who needs to receive the fax. See below screenshot: The msExchUMFaxRecipient attribute include the SMTP address of the user who needs to receive the fax. This information is included in the REFERRED-BY header. You may ask the IP PBX support to see whether it receive this information. If anything is unclear, please feel free to post back. I look forward to hearing from you. Best Regards, Ryan Ye, MCSE 2003 Microsoft Online Partner Support Quote Link to comment Share on other sites More sharing options...
ShadowAnt Posted January 11, 2010 Report Share Posted January 11, 2010 hello! any ideas? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 11, 2010 Report Share Posted January 11, 2010 hello! any ideas? Well, if I understand the Microsoft guy right, Exchange has a problem when the blind transfer first disconnects the referring call before it establishes the new call. The blind transfer has a long history of problems, that is why we implemented it this way. The biggest problem is that it is not clear who is responsible for hanging up. From today's perspective, it should be the best solution to move the referring call leg to an IVR saying something like "your call has been transferred", then hang up. It is up to the connected user-agent to hang up before the IVR plays back. Obviously that will take some time until we have that. Quote Link to comment Share on other sites More sharing options...
ShadowAnt Posted January 12, 2010 Report Share Posted January 12, 2010 Thank you! If I understand, I must wait for some changes in PBXnSIP for Exchange 2010 fax transfer? or I can use another FoIP solution... Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 12, 2010 Report Share Posted January 12, 2010 Thank you!If I understand, I must wait for some changes in PBXnSIP for Exchange 2010 fax transfer? or I can use another FoIP solution... Yes, we put that on the to-do list. If we clean this area up, we want to clean it up once and forever. Quote Link to comment Share on other sites More sharing options...
hosted Posted January 21, 2010 Author Report Share Posted January 21, 2010 faxback works just fine with exchange 2010 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.