<DIV>Hi Bryan,</DIV>
<DIV> </DIV>
<DIV>Yes the progress indicator contains the value of 8 and is actually being<BR>sent in the progress message. As you said there is not much one can do.<BR>Answering the call would ruin my accounitng and I don't want to do that. I<BR>have to tackle it from the Central Office end. I tested with a two PRAs; one<BR>from Ericsson switch and another from a Siemens EWSD switch and they both<BR>behave in the same manner, ie they do not cut-thorugh the early media when<BR>this is coming from the subscriber side. Maybe some sort of security measure not to allow users playing announcements to their callers for free!!!!!!!!<BR><BR>Thanks again,<BR><BR>Carmelo<BR><BR><BR>----- Original Message -----<BR>From: "Bryan Deaver" <<A href="mailto:bdeaver@cisco.com">bdeaver@cisco.com</A>><BR>To: "Karl Smith" <<A href="mailto:sipware@yahoo.co.uk">sipware@yahoo.co.uk</A>><BR>Sent: Wednesday, April 13, 2005 5:11 PM<BR>Subject: Re: [cisco-voip] Early media<BR><BR><BR>> The last thing to
check is that the isdn progress/alert being sent from<BR>the<BR>> GW does contain a PI of 8; it should if the audio is being cut through by<BR>> the GW. If this all checks out, then there is not much you can do on the<BR>> GW. You could try something like doing a 2-step dialing at the GW so that<BR>> the call actually connects on the ISDN side, then sends out the SIP<BR>invite.<BR>> I simple tcl script could force this but it ends up screwing up any<BR>> accounting you may have and could lead to other potential issues.<BR>><BR>> Bryan<BR>><BR>><BR>><BR>><BR>><BR>> From: Karl Smith <<A href="mailto:sipware@yahoo.co.uk">sipware@yahoo.co.uk</A>><BR>> Date: Wed, 13 Apr 2005 09:17:29 +0100 (BST)<BR>> To: <<A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>> Subject: [cisco-voip] Early media<BR>><BR>> Hi Bryan,<BR>><BR>> thanks for your suggestions. This morning I was just
thinking exactly on<BR>the<BR>> same lines. I have in fact performed the suggested debugs and confirmed<BR>that<BR>> the gateway is infact cutting through the early media; it is the central<BR>> office which is not switching it through to the caller. I have also traced<BR>> the SS7 signalling (i have access to the CO signalling system) and the ACM<BR>> lacks the optional parameter :<BR>><BR>> 'Inband information: inband info or pattern now available'<BR>><BR>> Furthermore, looking at Q931 rec, it appears that not all ISDN networks<BR>> supports the transmission of early media originating from the ISDN<BR>> subscriber side:<BR>><BR>> K.2 Procedures<BR>> As a network option, completion of the transmission path prior to receipt<BR>of<BR>> a call acceptance<BR>> indication may be provided in one of three ways:<BR>> a) on completion of successful channel negotiation at the destination<BR>> interface; or<BR>> b) on receipt of a
message containing an indication that in-band<BR>information<BR>> is being provided;<BR>> or<BR>> c) not at all, i.e. this option is not supported by the network.<BR>><BR>> Thanks a lot for your help.<BR>><BR>> Best regards,<BR>><BR>> Carmelo<BR>><BR>><BR>><BR>><BR>><BR>><BR>> It should be cut through dependent on the sip progress message we receive.<BR>> You might try 'progress setup enable 3' on the voip sip dial-peer as well.<BR>><BR>> Can you make a single test call with the following debug enabled so we can<BR>> see what is happening:<BR>> - debug isdn q931<BR>> - debug ccsip message<BR>> - debug voip ccapi inout<BR>> Make sure that you have disabling console logging to minimize the impact<BR>of<BR>> enabling the debugs.<BR>><BR>> You can also check the output of 'show call active voice brief' while the<BR>> call is in
alerting stage. You should see on the ip call leg side the rx<BR>> packet count incrementing and on the telephony call leg side you should be<BR>> able to see the 'out' dbm level fluctuate when you do multiple iterations<BR>of<BR>> the command. If you see what appears to be some audio on the telephony<BR>call<BR>> leg (meaning that you see the 'out' level at something than<BR>around -79dbm),<BR>> t! hen it sounds like the audio is being cut through at the gateway but<BR>> somewhere in the isdn cloud it is not being cut through.<BR>><BR>> Bryan<BR>><BR>><BR>> From: Karl Smith <<A href="mailto:sipware@yahoo.co.uk">sipware@yahoo.co.uk</A>><BR>> Date: Tue, 12 Apr 2005 15:20:11 +0100 (BST)<BR>> To: <<A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>> Subject: [cisco-voip] Early media<BR>><BR>> Hi,<BR>><BR>> thanks a lot for your help, but unfortunately the rtp send-recv did
not<BR>> solve the problem. I have also upgraded the IOS but still no success.<BR>><BR>> Any other ideas??<BR>><BR>> Regards,<BR>><BR>> Carmelo<BR>><BR>><BR>><BR>><BR>><BR>><BR>> From: "Teodor Georgiev" <<A href="mailto:tgeorgiev@is-bg.net">tgeorgiev@is-bg.net</A>><BR>> To: <<A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>> Sent: Tuesday, April 12, 2005 15:42<BR>> Subject: Re: [cisco-voip] Early media<BR>><BR>> > ><BR>> > voice rtp send-recv<BR>> ><BR>> > issue that command in global configuration mode. It shall solve your<BR>problem.<BR>> > The issue you have described below is an usual behaviour - the reverse<BR>> > "bearer" path won't be opened until a CONNECT message is received.<BR>> ><BR>> ><BR>> ><BR>> > On Tuesday 12 April 2005 11:40, Karl Smith wrote:<BR>> > > Hi,<BR>> > ><BR>> > > I am
using a 2610 as a sip to isdn gateway. It appears that there is<BR>an<BR>> > > issue with early media. When the gateway receives rtp in early media<BR>on the<BR>> > > ip side it does not switch it through on the isdn bearer channel.<BR>Hence if<BR>> > > any announcements or tones are provided on a media server just after<BR>the<BR>> > > 183 session progress and before the 200 OK, these cannot be heard on<BR>the<BR>> > > ISDN side.<BR>> > ><BR>> > > This problem does not exist in the reverse direction; i.e. if an<BR>> > > anno! uncement is available on th! e isdn side before the connect<BR>message,<BR>> the<BR>> > > gateway will swith it on an rtp stream and sends it to the ua.<BR>> > ><BR>> > > The IOS image that I am using is the c2600-is3x-mz.123-6b.bin<BR>> > ><BR>> > > Does any one knows whether this problem was resolved in more recent<BR>> > >
releases? If yes, any ideas which release?<BR>> > ><BR>> > > Thanks and regards,<BR>> > ><BR>> > > Carmelo<BR>> > ><BR>> > ><BR>> > ><BR>> > > Send instant messages to your online friends<BR><A href="http://uk.messenger.yahoo.com">http://uk.messenger.yahoo.com</A><BR>> > _______________________________________________<BR>> > cisco-voip mailing list<BR>> > <A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>> Send instant messages to your online friends <A href="http://uk.messenger.yahoo.com">http://uk.messenger.yahoo.com</A><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR>><BR>> Send instant messages to your online friends <A href="http://uk.messenger.yahoo.com">http://uk.messenger.yahoo.com</A><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR><BR></DIV><p>Send instant messages to your online friends http://uk.messenger.yahoo.com