[Home]

Summary:ASTERISK-16307: Unable to transfer to Microsoft OCS
Reporter:Andrew Parisio (parisioa)Labels:
Date Opened:2010-07-01 02:32:17Date Closed:2010-07-07 19:36:00
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) extensions.conf
( 1) myDebugLog
( 2) sip.conf
Description:I am able to receive a call from Qwest to any of my desk phones.  I am able to receive a call from flowroute or bandwidth.com and transfer it to microsoft OCS, but i am NOT able to receive a call and transfer it from Qwest to OCS.  The call fails.  I am attaching 4 files.  The good call examples are calls from flowroute, the bad are from qwest.  I've tested this against 1.6.1.18, 1.6.2.9, and the SVN  SVN-branch-1.6.2-r273271.  

****** ADDITIONAL INFORMATION ******

I sent this to a member of the OCS team, here is what he said:

Looking closer at the Invite, I believe I see the issue.  The SIP Provider is sending a multipart MIME body and Asterisk does not support multipart SDP.  There is a bug on multipart SDP that was supposed to be fixed in 1.2 Branch and Trunk.  

Here is the bug.
https://issues.asterisk.org/view.php?id=7124

The SIP Provider call that is failing is sending this in the SDP.
Content-Disposition: session; handling=required
Content-Type: application/sdp

The Content-Disposition: session; handling=required ? this means that the terminating end needs to support SDP.  Which Asterisk does, but since you are running Asterisk 1.6.1.18, it is not handling the multipart sdp headers.

Hope this helps,
Comments:By: Andrew Parisio (parisioa) 2010-07-01 02:34:39

Could somebody please remove the attached files after looking at them and possibly identifying the problem?  They probably have information in them that i do not want posted on here permanently.  Thank you!
By: Paul Belanger (pabelanger) 2010-07-01 07:53:24

Deleted files, please upload debug logs (see below) of the failed call.  Also attach you sip.conf.
---
We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt


By: Andrew Parisio (parisioa) 2010-07-01 12:01:18

Okay, I will do this tonight when the system is idle, otherwise the logs will be pretty big.
By: Andrew Parisio (parisioa) 2010-07-01 16:02:42

look at this ticket: https://issues.asterisk.org/view.php?id=17179

they mention setting the limit to 256.  my content-length is 261 in the failed call example, and content-length is 228 in the good call.  

Content-Length: 261
Content-Disposition: session; handling=required
Content-Type: application/sdp

Is it possible these are the same problem?  I'll post additional debug info tonight when my system is quiet.
By: Andrew Parisio (parisioa) 2010-07-02 00:54:55

Okay, i uploaded the debug log.  Could you please remove it when done?  Thanks!

I made a phone call from 44444444 to 6845, and then redirected that call to 15555555555 @ OCS_TRUNK_R2.  If i make a call to the real 555 number and redirect it to the same 155555555 @ OCS_TRUNK_R2 the call does work.
By: Paul Belanger (pabelanger) 2010-07-02 06:23:54

we'll need a copy of your dialplan and sip.conf
By: David Woolley (davidw) 2010-07-02 07:12:00

There are no multipart attachments in the trace, and Asterisk isn't offering to accept them.

The only failed call I can see so far is one that was cancelled by the caller before the callee had sent any call progress (only a 100 Trying)


By: Paul Belanger (pabelanger) 2010-07-02 07:33:03

I agree with davidw, I don't see anything in that trace pointing to a problem with Asterisk.
By: Andrew Parisio (parisioa) 2010-07-02 10:13:16

Hmm, does anything look wrong with the invite maybe?  I am able to receive calls from this provider and send them to Aastra desk phones / meetme / another * box, but I just can't transfer to OCS.  This happens.
By: Paul Belanger (pabelanger) 2010-07-02 10:27:16

The invite looks good, infact we get 100 Trying and then the channel hangs up.

<--- SIP read from TCP://192.168.11.76:5060 --->
SIP/2.0 100 Trying
FROM: "4444444444"<sip:4444444444@192.168.51.15>;tag=as39261ff0
TO: <sip:+15555555555@192.168.11.76:5060>
CSEQ: 102 INVITE
CALL-ID: 67cca41821eee84b0679a7792ae94123@192.168.51.15
VIA: SIP/2.0/TCP 192.168.51.15:5060;branch=z9hG4bK18f0a607;rport
CONTENT-LENGTH: 0
By: Andrew Parisio (parisioa) 2010-07-05 13:20:26

I'm waiting for qwest to reply back with their side of the call and why it failed. They are super slow.
By: Andrew Parisio (parisioa) 2010-07-07 16:55:36

It works.  qwest did something: "ESs indicates that this has been repaired by extending a timer"

it only took them a couple weeks to figure it out.

Please close the ticket, thanks for the help!
By: Andrew Parisio (parisioa) 2010-07-07 16:56:13

here's the technical answer

Well, we found that the calls to the Microsoft OCS application were not receiving a provisional 1xx, after the initial 100 Trying message, within the configured 2000ms inter-message timer. As a result,the Qwest SBC would cancel the call 2000ms after receipt of the 100 Trying message.

The calls that completed to your extension, were doing so because the PBX was sending the 180 message back to the Qwest SBC within the allotted 2000ms inter-message timer.

To remedy this, Tier III bumped up the inter-message timer to it's max value (10000ms) and the calls to the Microsoft OCS application are now completing.