CUBE SIP early media problem

[friskopart]

CUBE is not transparently sending in incoming ringing(180) with SDP to an outgoing ringing(180) with SDP but it converts it to session in progress message (183) which causes problems, we are using IOS version adventerprisek9-mz.151-4.M3 on cisco ISR 3825.

If some one has a soloution to this problem please help.

thanks

[Ayodeji Okanlawon]

What CUCM version are you using?

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[friskopart]

not using CUCM, we are using 3rd party sip server and IOS CUBE to interface ITSPs so CUBE has 2 sip trunks on to sip server and another to ITSPs and the problem is when CUBE receives sip 180 with SDP it converts to 183 with SDP instead of  forwarding  the 180 to ITSP, how can we get rid of this behavior and maintain early media at the same time ?

many thanks

[Ayodeji Okanlawon]

May I ask what exactly is the problem..

Here is a sample policy from RFC 3960 (this doesn't exactly talk about 180
w/ SDP but suggests what a UAC can do when it receives early-media packets
in conjunction w/ a 180 response):

   With this in mind, a UAC should develop its local policy regarding
   local ringing generation.  For example, a POTS ("Plain Old Telephone
   Service")-like SIP User Agent (UA) could implement the following
   local policy:

      1. Unless a 180 (Ringing) response is received, never generate
         local ringing.

      2. If a 180 (Ringing) has been received but there are no incoming
         media packets, generate local ringing.

      3. If a 180 (Ringing) has been received and there are incoming
         media packets, play them and do not generate local ringing.

         Note that a 180 (Ringing) response means that the callee is
         being alerted, and a UAS should send such a response if the
         callee is being alerted, regardless of the status of the early
         media session.

As far as I know, SDP and 18x handling is implementation dependant, though a
common use - that seems widely accepted - would be to have the SDP in 183
for ring back tone, when PSTN gateway is involved.

So if ur swicth provides 180 with SDP it should provide ringback tone or 183 with SDP.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[friskopart]

the problem is that sip 183 gets mapped to ISDN PROGRESS  and in order to get an ISDN ALERT a SIP 180 should be received by some PSTN Gateways, so we need to forward sip 180 messages

[Ayodeji Okanlawon]

Have you tried the command voice call send-alert ? Can you please do a test call send debug isdn q931..

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[friskopart]

our setup is like this:

SIPserver------(sip)------CUBE--------(sip)-------provider----PSTN

as you can see that we don't have direct interface to the PSTN so do you think that "voice call send-alert" is still

applicable?.

we would like to send sip 180 to provider so thier PSTN callers can get ALERT message.

thank you for your help