I see that the GSAPI allows the ability to fork media from a CUBE router via the XCC Provider RequestXccCallMediaForking operation. The relevant information in the sample shows this:
<RequestXccCallMediaForking xmlns="http://www.cisco.com/schema/cisco_xcc/v1_0">
<action>
<enableMediaForking>
<farEndAddr>
<ipv4>1.3.45.155</ipv4>
<port>32599</port>
</farEndAddr>
<nearEndAddr>
<ipv4>1.3.45.155</ipv4>
<port>32598</port>
</nearEndAddr>
</enableMediaForking>
</action>
<callID>8</callID>
<msgHeader>
<registrationID>4C21504:XCC:myapp:3</registrationID>
<transactionID>4C23C6C:2FE</transactionID>
</msgHeader>
</RequestXccCallMediaForking>
I'm curious how we would integrate with a Media Sense server? Is it as simple as providing the Media Sense server IP and listening port range into this API (after registering)? It seems like there would be more to this in order to capture all of the relevant metadata, but just curious if I'm missing anything here.
Also, I don't see documentation on what version the GSAPI is available in. Is this new with 10.0, or was it around prior?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are different ways to configure CUBE to do media forking:
MS use CUBE configuration like
media class 102
recorder parameter
media-recording 108 110
to do media forking
CUBE configuration using
uc wsapiuc wsapi
provider xmf
Is used for UCM “Gateway Recording”
Most probably, MS will support “Gateway Recording” in 10.5 release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CallManager uses SIP trunks to control MediaSense in conjunction with UC Gateway services.
In any case what we send for media forking is just a one way rtp stream to destination.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comments
0 comments
Please sign in to leave a comment.