[Spce-user] NGCP as Web2SIP gateway
alexey.rybalko at gmail.com
Thu Jul 11 07:58:49 EDT 2013
Ok. Thanks. When NGCP 3.0 is planned to come into release?
2013/7/11 Andreas Granig <agranig at sipwise.com>
> The issues you lined out are actually addressed in the upcoming 3.0
> release, where websocket is part of the system, the lb routing is adapted
> accordingly, and usr/dom-preferences are available to control SAVPF profile
> handling, so you can do calls within jssip apps as well as calls from jssip
> to plain SIP and vice versa (at least with audio for now).
> On 07/11/2013 01:25 PM, Alexey Rybalko wrote:
>> Present implementation of WebRTC is a headache if someone making the
>> bridge to a legacy SIP cloud. SRTP, SDP media-profiles...you know. Since
>> the version 2.3.0 of your ngcp-medaproxy-ng Sipwise feeds our hope to
>> get a relief completing that mission of service convergence :) Playing a
>> couple of days with SPCE with no valuable success. More questions appear.
>> The setup is:
>> 1) sip:provider CE,
>> 2) JsSIP as ref. implementation of SIP/WS-client
>> 3) OverSIP as SIP proxy for websocket clients (SPCE comes without
>> websocket.so, but some reconfiguration is required either if this module
>> 4) softphone (like X-Lite or Jitsi)
>> The first problem was that Kamailio registrar can't save "Path" header
>> from JsSIP REGISTER request. Extending DB field "kamilio.location.path"
>> from 128 to 255 characters made that work :) Not sure this is a proper
>> trick but it works: JsSIP cant register and send INVITE to a "legacy"
>> softphone. But that's all. The problems are:
>> 1) SPCE (Kamailio) can't locate JsSIP to forward INVITE from softphone.
>> "Path" header support is enabled however. TCPdump shows us round-robin
>> traffic from 127.0.0.1 to 127.0.0.1. Softphone receives 408 (Request
>> timeout) from registrar. Should we use websocket.so instead of external
>> "websocket-able" SIP-proxy? What might be wrong here?
>> 2) JsSIP drops outbound call (to softphone) on negotiation phase with
>> 488 (Not Acceptable Here). No doubt that's because of unsupported
>> SDES-SRTP and RTP/SAVPF on remote endpoint. ngcp-mediaproxy is intended
>> to solve this issue:
>> /"..the*complete SDP body* is passed to mediaproxy-ng, rewritten and
>> passed back to Kamailio. *Several additional features are available with
>> this protocol, such as ICE handling, SRTP bridging*, etc."
>> Sounds good. However help is needed to move further. Any input would be
>> p.s. Is there some manual about packet processing inside mediaproxy-ng?
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
> Spce-user mailing list
> Spce-user at lists.sipwise.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Spce-user