CUBE SIP DO-EO issue (with supplementary services)

[lexxa7777]

Hi 

preface:

  I will try  to setup CUBE to work with SIP ITSP  

  CUCM_6.1(old) ->CUBE(sip-to-sip)->ITSP

      I doesn't want to use MTP required on SIP trunk !!!

   ITSP requires EO ( INVITE w/SDP ) .

   ITSP doesn't answer with 100/Trying   in  INVITE doesn't contain SDP ( after some Invites sessoin expires)

   CUBE=2911 IOS=c2900-universalk9-mz.SPA.154-2.T.bin  (latest)

________________

Initial call setup works fine

 CUCM send DO then CUBE convert it to EO  by the 

dial-peer voice X voip

  voice-class sip early-offer forced 

external user answers the call

after i press hold on the  IP phone,  CUCM send REINVITE  w/SDP IP 0.0.0.0 ( it indicates that call on hold) and I can fix by sip profile if I need it.

not all ITSP correctly process if IP = 0.0.0.0

after i press unhold CUCM send REINVITE  without/SDP  Deleyed Offer and CUBE doesn't fix it to EarlyOffer :(

CUBE also send REINVITE to ITSP in DO, and ITSP doesn't reply with 100/Trying :(

I found that 15.4(2)T has a new feature 

 dial-peer voice X voip

  voice-class sip early-offer forced re-negotiate always 

but it doesn't fix REINVITE DO to EO :(

The question is 

1) Is possible CUBE to fix REINVITE DO to EO as well as INVITE ?

2) Is it possible to change CUCM behavior on unhold event ?

( note: dont use MTP required on SIP trunk :)

[Kirill Glushenkov]

Hello!

What problem do u have with this DO ReInvite? One-way audio, call doesn't come back?

Sorry, if I missed something.

Regards,

Kirill

[Kirill Glushenkov]

Probably, there is no such possibilty for your version...

Accordinf to this: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/accm-861-cm/a08sip.html#pgfId-1319946

Mid-Call Setup

Cisco Unified Communications Manager also enhances interoperability with third-party devices during mid-call operations, such as basic hold/resume operations, and during supplementary services, such as transfer and conference. In previous releases, Cisco Unified Communications Manager sent an INVITE with an inactive SDP (a=inactive attribute) to indicate a break in media path, sent a delayed offer INVITE to insert music on hold or to resume the media stream, and expected a send-recv offer SDP in the 200 OK. Because third-party devices often provide an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to drop.

Cisco Unified Communications Manager allows you to configure a parameter for an early offer SIP trunk so that Cisco Unified Communications Manager suppresses the sending of inactive or sendonly SDP in mid-call INVITEs. When this parameter gets enabled, Cisco Unified Communications Manager connects the SIP trunk device directly to the MOH or annunciator device without breaking the existing media stream during call hold or during other feature invocation. Similarly, Cisco Unified Communications Manager connects the SIP trunk device to a line-side device directly during call resume without breaking the MOH or annunciator stream. By preventing the far-end media stream from getting set to inactive, Cisco Unified Communications Manager should always be able to resume the media path.

But I can't find same thing for 6.1...

[lexxa7777]

Hi, Kirill 

Thanks for you reply

>> What problem do u have with this DO ReInvite? 

Yes, call doesn't come back . Because ITSP doesn't reply with 100/Trying.

So CUBE  retrys to send REINVITEs and after timer expires CUCM send BYE.

The real question why the latest version of CUBE fix INVITE but doesn't fix REINVITE  

[Kirill Glushenkov]

Can't find the answer on this question right now.

Did u try to play with 'request reiNVITE sdp-header session-info add' ?

Regards,

Kirill

[lexxa7777]

I didn't try to do 'request reiNVITE sdp-header session-info add'

because the detination/call controlled by one dial-peer and sip profile

1) INVITE w/SDP

2) REINVITE w/SDP ( fixed by sip profile)  - HOLD

3) REINVITE without/SDP ( fixed by sip profile)  - UDHOLD

so I need conditional sip profile to fix only 3) REINVITE and construct fake SDP 

P.S.

I've just found "Conditional Header Manipulation of SIP Headers" 

so I will try to play this, thanks 

[Ayodeji Okanlawon]

Lexa,

There is no way CUBE will send a RE-INVITE with SDP when it receives a RE_INVITE with inactive media from cucm. In this scenario and especially on the version of CUCM, you cant avoid using an MTP.

[lexxa7777]

Hi Ayodeji

When call puts on hold CUCM sends  REINVITE with IP=0.0.0.0 & a=inactive which can be fixed by "voice-class sip profile"

When call unhold  CUCM sends  REINVITE without SDP and CUBE also sends REINVITE without SDP to ITSP 

this is the key I think.

I see debug from ITSP which supports DO. The only thing that I need Is to fix

IP: 0.0.0.0 => IP: CUBE_IP

a=inactive to a=sendrecv

and hold, transfer,  etc works!

example of ITSP that support DO is SkypeConnect ( aka Skype for sip)

so CUBE does corvertion DO-EO for the first INVITE in the session only ( but not for RE-INVITES)

May be in the future versions Cisco will implement it 8-)