Hi,
just an idea: Why not look at MGCP or Megaco/H.248 to control the RTP-Proxy? Might be interesting, since you could use Kamailio as a Client for other cases, such as Announcement-Servers or PSTN Termination.... This needs more investigation, i know, and it's way more complicated, but maybe worth the effort; i don't know. Just an idea.
Carsten
2012/6/2 Andreas Granig agranig@sipwise.com:
Hi Peter,
On 06/01/2012 07:25 PM, Peter Lemenkov wrote:
My personal opinion is that we should pass the entire SDP (wrapped into json perhaps) - codec mapping and their parameters, encryption keys, stun data - this all could be useful for the rtpproxy backend. Otherwise it looks good.
When taking into account all kinds of use-cases like ICE handling between ICE/non-ICE clients and srtp bridging for webrtc, as well as transcoding for "normal" clients, it makes sense to pass the full SDP body to the rtpproxy and expecting a full SDP body back in response.
Maybe some basic wrapping which includes generic and SIP specific values (like the cookie, call-id, tags, branches, IPv4/IPv6 bridging etc) as well as the full SDP for a request, and for responses a status and again the full SDP would be sufficient.
That way, we'd get also get rid of certain flags in the rtpproxy module.
Andreas
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev