I have a situation where have to record some calls from some IP phones. CUCM and server to which is call recorded are in one region (let say RegionA) and phones and HW transcoder (C2650XM) are in other region (RegionB). Gateways to PSTN are also in RegionA. Relation between regions is g729 and inside regions g711. Trunk between CUCM and recording server is SIP.
Problem is when there is call beetween two phones in RegionB. Codec in that case is g711 between phones, and secondary stream to recording server have to go with g729 via transcoder (becouse region relationship). In that case, there is no outgoing stream to recording server from transcoder. I can see inside stream (g711) from phones, but no outgoing.
When testing with several transcoders, we noticed that this scenario works with new 2911 router and PVDM3-256 card,but not working with older 2811 and 2650 and NM-HDV= card.
In attach there is a output of show dspfarm sessions on 2650 router:
- first 4 lines shows transcoding between CUCM and phones while in conference - does not have anything with this case, but it shows that transcoder is working OK
- last 4 lines is incoming streams of phones that are recorded. there is no IP address and there is no outgoing g729 stream to recording server
Is there some limitation with older hardware (maybe SIP signaling) ?
If i undertsnad your set up correctly,
The region between your recording server (sip trunk to cucm) and xcoder is set to use G729.
Which side of your call is invoking the xcoder. The side that is invoking the xcoder needs to do G711 to the Xcoder.
If the recording server is the side invoking xcode, you need to do G711 to the xcoder.
Pls rate useful posts...
phone is initiating stream connection to xcoder with g711 codec. Xcoder should then transcode stream to g729 and send it to recorder in other region. This works with 2911 router xcoder, but not with 2811 or 2650.
Sent from Cisco Technical Support iPhone App
Can you pull callmanager traces? I had like to see what callmanager is saying/seeing.....
The transcoder works the same either on 2900/2811..PVDM2 or PVDM3, I believe. So if we look at cucm traces we will get a clearer picture.
Thne fact that there is no G729 codec in the file attached suggest that the recording server is doing G711 to the xcoder. The phones are also doing G711 because thats the codec set between them and the xcoder. If the recording server is doing G711 to the xcoder, that suggests that it is the one invoking xcoder...This is in theory. The side that invoked xcoder must do G711 to xcoder
This is why cucm trace will tell us which side has actually invoked the xcoder. Have you tried setting g711 between recording server and xcoder and see the results? Just as a test.
I will be happy to look at the traces if you can get them
I'm very sure that recorder is not initiating session to xcoder - I have tcpdumped traffic on recorder and there is only communication to CUCM, not xcoder. I have also captured traffic from phone, and there is a valid stream to xcoder, so conclusion is that xcoder is receiveing g711 stream from phone, but not doing transcoding and not sending g729 to recorder.
If I put g711 between xcoder and recorder, than stream from phone will not be sent to xcoder - it will go direct to recording server.
Unfortunately, I am busy today and cannot do CUCM tracing. However, one more clue; on older transcoders (2650/2811) I do not have PVDM2; I have NM-HDV and PVDM-12. Can this be a problem?
The fact that you see a rtp stream from the ip phone to the xcoder does not suggest that the ip phone is invoking the xcoder(it may well be but this is not the proof)
Each device in the call setup regardless of who invokes the xcoder will send their rtp stream directly to the xcoder.
Because they can't talk to each other, they need the xcoder to mix their rtp stream.
The fact that you see the voice recorder talking to cucm implies that it is unable to send its rtp stream to directly to the end device. Cucm then looks for a xcoder to insert in the call setup on behalf of this device.
If cucm can't insert a xcoder for the requesting device, you get a busy or engaged tone and the call drops.
Ideally devices send rtp stream directly to each other, if for any reason such as codec mismatch, they can't talk directly to each other, a xcoder is inserted and both device send their rtp stream to it. The codec you will see on your sh sccp connection oor sdspfar session will depend on what the region setting between the xcoder and the devices sending their rtp stream to it.
This is why I requested for cucm traces. It usually the place to fix issues like this.
When I said do G711 to voice recorder, I mean reverse your setup now. So that xcoder sits local to recorder and phone does G729n just the opposite of what you have now. This just for testing
let we start with end of your post.
If I put xcoder local to recorder, and phone to remote region, the case is that xcoder is never involved in rtp stream. Why? There is 2 reasons:
1. PhoneA to PhoneB are "talking" g711 (becouse there are in same region), and secondary stream from phone can be only g711, but it can not reach eather xcoder or recorder becouse both are in other region which have g729 relationship to phones regions
2. If I force PhoneA to PhoneB on g729, secondary stream (which is now g729) is going directly to recorder. There is no need to transcode anything because recorder accepts g711 and g729.
I tried both scenarios, and that is as I described.
Next to your thoughts:
I am talking here with one-way stream that is going from phone to recorder; recorder is recording device so it have only incoming stream; does not sending anything out to phone. So I can't see how can xcoder be initiated by recorder?? This is no two-way communications.
Let me show you a little "graphics"; let say that PhoneB is the one which calls are recorded (pay attention on arrows that shows stream direction):
PhoneA <---(G711)---> PhoneB -------(G711)------> XCODER -----------WAN-link (G729) ---------> RECORDER
In case when G729 is used between two phones (eg. PhoneA and PhoneB are in different regions):
PhoneA <----(G729)-----> PhoneB ---------WAN-link (G729) -------------> RECORDER
So PhoneB actualy sends 3 streams:
1. to PhoneA that contains voice of man on PhoneB
2. to recorder that contains voice of man on PhoneB
3. to recorder that contains voice of man on PhoneA
Stream to recorder can be only the same codec that is used to send stream to PhoneA.
As everything works OK with newer router and DSP (PVDM3), I assume that a problem is with older DSP card (PVDM) and not in CUCM or any other configuration. Eventualy, maybe is some settings on transcoder router that will make this thing works with older PVDM.
Current workaround for this is that we lower local codec from G711 to G729 inside regions, so there is no need for xcoder for sending streams over WAN links; but this is not permanent solution becouse we need G711 localy because of other reasons (I will not bother you with this).
You mentioned that recorder is talking to CUCM...what is wrong. CUCM is acctualy talking to recorder, becouse it has to send to recorder signaling for recording to start, and some other informations (phone numbers, callID and so on).
So, if I understand the call proccess, here is how it flows (in basic - maybe I'm wrong...I can't tell for sure because I haven't so much knowledge about that):
1. PhoneA calls PhoneB - acctualy sends signal to CUCM to call PhoneB, so PhoneB rings, no streaming yet.
2. User at PhoneB answers calls, and that is signalized to CUCM.
3.1. CUCM than sends signal to PhoneA that should start sending streaming to PhoneB in codec that PhoneB supports (by regions settings and device capabilities)
3.2. CUCM sends signal to PhoneB to start sending stream to PhoneA (same codec as above)
4. As PhoneB calls are recorded, CUCM have to decide to send mirrored streams to recorder directly or via xcoder, based on region in witch recorder is located, so:
5.1. CUCM sends signal to PhoneB to start sending stream to xcoder (mirrored stream from PhoneA to B)
5.2. CUCM sends signal to PhoneB to start sending stream to xcoder (mirrored stream from PhoneB to A)
5.3. CUCM send signaling to xcoder what to do with these streams and where to send them - to IP adress and port of recorder
6. CUCM send signaling to recorder when to start and stop recording and which stream, also sending some other details like phone numbers, cucm call ID and so on (this is done by SIP trunk)
I have everything OK except 5.3. - xcoder does not transcode and does not sending any stream to recorder. Again, with PVDM3 this same setup works OK.
Your explanation of the setup does make things clearer. I totally agree that recorder is a one-way device...I missed that out and that changes everything. I am no expert on recorders too...
Because a recorder is a one-way device, it does not send RTP stream, There is no way a xcoder can help...
Lets back track and understand what a transcoder does...
A transcoder takes the stream of one codec and transcodes (converts) it from one compression type to another compression type. For example, it could take a stream from a G.711 codec and transcode (convert) it in real time to a G.729 stream. In addition, a transcoder provides MTP capabilities and may be used to enable supplementary services for H.323 endpoints when required.
The Cisco CallManager invokes a transcoder on behalf of endpoint devices when the two devices use different voice codecs and would normally not be able to communicate. When inserted into a call, the transcoder converts the data streams between the two incompatible codecs to enable communications between them.The transcoder remains invisible to either the user or the endpoints that are involved in a call.
Look at that bolded line "When inserted into a call, the transcoder converts the data streams between the two incompatible codecs to enable communications between them"
The transcoder converts data streams between two mismatch codecs. In this scenario there is only one stream Phone to recorder. Could that be the problem. Xcoder (atleast the ones on pvdm-12) does not generate RTP stream of its own?? And the newer ones on PVDM2 and 3 do generate Streams? Just a thought...