Hi,

I am in a little trouble over here, i am monitoring an extension using DMCC , what i am looking into is to get the RTP services packetsize,payload type,IP,Port of the Near End ( Monitoring station) and Far End Station that is associated in the call .

My Application has to only provide the above RTP services and IP,port associated in a call .

1) I am able to get the RTP services and IP,port of the Far end station associated in the call using Media control Adapter methods media started and media stopped, Events.getRtpAddress, .getport , Event.getPacketSize, Event.getCodec

how can i get the Near End Station RTP services , IP ,port

I am aware i can get the IP,port using the SMS services "status station " but how will i obtain the same for near End Station using DMCC.

2) Do these RTP services have a different values for Tx and Rx , I am working on a simulator and i have checked the audio talk path in "Status Station " it always displays the packt size as 20ms and codec G711mu . do these values change in real time scenarios for Tx and Rx .

What i mean is Monitoring station Tx at packet size 20ms and codec G711mu and Rx Packet size 40 ms codec G729 values associated for the same call

3) were will i get a detailed discription related to RTP as how to read the RTP header , just to differentiate an incoming and outbound RTP packets in a mintored station

Thanks,
Rajeev

Rajeev,
I do not understand your setup. Could you describe what media mode and dependancy mode you are using.

1) see above.

2) yes Tx and Rx will use different values depending on the capabilities of the two stations in the call, and the restrictions imposed by the ip-codec set provisioned for their respective ip-network-regions.

3) The RFC for RTP would be where I would start. (1889 and 3550, 3551

Rajeev,

When Communication Manager sets up a call between two endpoints, it attempts to find a common set of media capabilities (codec, encryption etc.) between the two. Depending on the capabilities specified by each endpoint at registration, plus the capabilities in the ip-network regions, Communication Manager may, or may not, be able to find a common set. If it cannot find a common set (such as in your case where one endpoint uses G.711 and the other uses G.729), then CM must play "man-in-the-middle" and trans-code the audio between the two. Thus, in this case, the G.711 endpoint talks to CM in G.711 and CM talks back in G.711, and so the Rx and Tx parameters are the same, as far as the G.711 endpoint is concerned. Similarly, the G.729 endpoint talks to CM in G.729 and CM talks back in G.729 - and again the Rx and TX parameters are the same, as far as the G.729 endpoint is concerned.

Thanks john, Gwilym ,

That has cleared the doubt on call btwn two stations using different codec,packet-size

But could u help me in this , My application has to monitor a station it registers the monitored station in Independent mode and server media.

And the MediaStartEvent indicates when the far end RTP parameters have changed and an RTP session has been established, here i try to get the

- IP , Port , packet size , payload type of the Tx (monitored ) station and Rx ( Far end station )

I am able to get all the above parameters on the far end station using the getPacketSize , getRtpAddress , getCodec on the MediaStartEvent.

Could u let me know how will i get the same on the Near End station .

Thanks,
Rajeev

simple answer, you cant do what you want through DMCC.

You canthrough SMS.
Reasoning

The StartMonitor event provides information about the "other end" RTP parameters. In the configuration you describe you have basically setup a 3 party call. Your device using server media, the phone you are monitoring, and the far end device. Communication Manager models this connection as a 3 party conference. The media information you are getting is for a media processor resource on Communication Manager (not the far end station/trunk).

the statusstation model of SMS supports these fields


Audio_Channel_Codec 660aff00 1 12 Audio Channel Codec
Audio_Channel_Other_End_IP_Address 660cff00 1 15 Audio Channel Other-End IP Address
Audio_Channel_Other_End_Port 660dff00 1 5 Audio Channel Other-End Port
Audio_Channel_Set_End_IP_Address 660eff00 1 15 Audio Channel Set-End IP Address
Audio_Channel_Set_End_Port 660dff00 1 5 Audio Channel Set-End Port


Packet size is not available.

This is as close as it appears the system makes available to what you need.

Hi john,

Could u explain me a little more on the following , i could not find any explanation on these.

1) What i observed was that the dmcc aplication when registered in Independent Dependency and server media would always return IP,port & codec of the MEDPRO initially when it starts to ring on the monitored station.
and return the IP,port and codec of the calling party another station that is also registered on the same switch ,

so i assumed it to always return the IP,port,codec of the calling party whether registered on same switch or not .

But, could u explain me more on this what u had posted to my earlier Query stating that

" The media information you are getting is for a media processor resource on Communication Manager (not the far end station/trunk) "

2) The API states that we recieve an mediastart event when the far-end RTP parameters have changed and an RTP session has been established and the DMCC java programmers guide tells that we can also recieve an media start event when there is a media shuffles

So as told above what i am obtaining is i recieve an media start event from the MEDPRO for the ringing event and again another mediastart event when there is a media shuffle and hence i get the IP,port and codec of the calling party configured on the same swithch

so can there be a situation when there is No media shuffle happening,

one such scenario i feel would be when the medpro acts as a middle man when the two parties are communicating in a different Codec ( calling party G711 and called party G729) so i feel the two parties would communicate only via MEDPRO and hence no media shuffle happens. can u justify on this or state any other situation, so i feel in this situation the Far end would always be the MEDPRO.

3)how would two parties communicate where in monitored station is registered on one switches and the calling station is registered on a different switch .


3) I have not simulated a case where a trunk call recieved from a device not configured on the switch(say from another PSTN phone ) how is such a call handled will i be able to get the IP,port ,codec, packetsize of the calling party will it be possible thru SMS !!!


Regards,
Rajeev

Hi John,

It would be great if you could answer my queries as i will have to consider my next course of action based on your reply to the queries and would relly help us out if you could answer to all the 4 queries in same order.

Thanks ,
Rajeev

Rajeev,
   We support the forums in our 'spare' time, when we are not working on requests from higher level devconnect members (who are paying for support), reviewing designs, documentation, creating portal content, etc.. We do our best, but our responsiveness will vary greatly. If you require a higher level of responsiveness than you are getting please consider joining the devconnect program as a higher level member.

1)   What you are observing is referred to as media shuffling by Avaya. For an inbound call, the initial "far end media" information will be for a MedPro on Communication Manager. Subsequently (once media parameters for the parties in the call have been acquired) the call MAY shuffle from TDM media to direct IP media if Communication Manager can achieve that state transition. If a call transitions to direct IP media, there will be an update and the far end RTP media information will be provided. A transition to direct IP media is not guaranteed. A similar sequence would be observed for an outbound call from a monitored device.

Communication Manager can only provide RTP information for the devices it is working with. Depending on the call topography, a RTP address may represent an IP/SIP station on a remote PBX, or an MedPro (or equivalent) on a remote PBX, a MedPro address on a near or remote gateway or an IP/SIP station on the same system.

Multiple registrations per device should always be modeled as a call with three media participants in Communication Manager (assuming the monitored device and the calling/called party are both active in the call). The third party will be the Independent mode, client/server media mode device. This is handled as a three party conference call by the media handling portion of Communication Manager. All connections involving more than two active participants are handled as a conference connection. Conference connections require all media to be sent to/from Communication Manager MedPro circuit packs where they are normalized, exclusively summed and re-encoded and sent back to the call's participants.

Thus this portion of your question "and return the IP,port and codec of the calling party [sic another] station that is also registered on the same switch ,[at what point in time/under what conditions?]" (which reads like an incomplete thought), should not be occurring unless I am making the wrong assumptions about your call scenario.
2)   Yes, media shuffling is not a guarantee. There are multiple reasons it would not occur. For one it can be disabled via provisioning at numerous levels (station, signaling group, ip-network-region, system wide). There can also be codec, or DTMF transfer mismatches requiring Communication Manager to remain as the man in the middle performing some form of transcoding responsibility. Finally it may not occur if the far end device is TDM based and not IP based. As described in #1 calls involving more than two parties are almost always summed on communication manager (there is a case with a SIP phone where the summing is done at one of the phones in the call - but this is rare).
3)   Please be more specific. What type of stations, what type of trunk, shuffled or non shuffled, IP/TDM. What actually interests you? .. I presume some specific facet of "how do they communicate" interests you, but I can think of numerous perspectives to start to answer from, I could be off topic for pages. If this case is not made clearer by my other comments, please restate it and I'll try to provide an answer.

4)   (the other 3) Communication Manager can only give you what it is aware of. A PSDN phone is presumably a TDM device. If the call comes into Communication Manager through a TDM facility (analog, or digital trunk) then the only 'far end' RTP information will be a MedPro on Communication Manager. If the call comes over an IP facility (H.323 of SIP trunk), then the far end RTP address will most likely be some gateway in a service provider's domain, or it could be (although this is likely to only be the case if the facility is a private network facility) some IP/SIP device where the call originated. Depending on the nature of the session boarder controller involved in such a call, the RTP information that Communication Manager has for the far end part could be a variety of devices. It is unlikely to be the actual device's RTP given that there will most likely be some form of PAT/NAT involved in the connection. As far as this information being available via SMS? whatever it is, yes it will be.

John

Hi John,

Thanks , i regret for the impatience as i had to take few decision based on your comments .now i am clear with the media start event , but one Question that has raised in my mind is when there is no media shuffle will there be a media start event once the call has been answered ( The second media start event that we obtain when the media shuffle happens but in this scenario when there is no media shuffle as MedPro is playing the man in middle but the call has been answered) .

To be more precise will the media start event be trigerred again after the call has been established between the two ends.

I am using a simulator hence i am not able to generate this situation , it would be great if u could let me know the answer to this query at the earliest .

Thanks ,
Rajeev

Rajeev,
In the case that the call does not shuffle (which you can simulate by disabling shuffling via the provisioning interface -SAT - for the devices involved in your call scenario) there is only one media start event. There will be no media event on answer.

If you want to know when the call is answered you will need to utilize call control services.

John