Jump to content
Vodia PBX forum
hosted

REFER

Recommended Posts

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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
[...]

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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...