Ashish Khare wrote:
Hi Joegen,
Please reply for my below mail.
Thanks for the reply.
Is there any design document about openSBC, which will tell me in detail
about how it is implementing the NAtting/ ALG functinality and how it will
handle the Media streams.
No there isn't yet. Your best bet is to analyze the code and ask
questions.
For Call Transfer, we will use the relay approach.
Then you may not need to parse RTP
Also, if i want to just relay the Media packets, can you let me know the
algorithm you have applied in the openSBC.
RTP is parsed in RTPSession::OnReceiveData(). You may override this
function to not parse anything and just return e_ProcessPacket for all
cases. I haven't done this myself so i'm not sure what side effects
there will be. If that happens, you are on your own.
Also, in openSBC product, is High Availability supported or it is in
roadmap
?
It is planned but did not get a date yet in the roadmap.
On 8/10/07,
Ashish Khare > wrote:
Hi Baclor,
Thanks for the reply.
Is there any design document about openSBC, which will tell me in
detail about how it is implementing the NAtting/ ALG functinality
and how it will handle the Media streams.
For Call Transfer, we will use the relay approach.
Also, if i want to just relay the Media packets, can you let me
know the algorithm you have applied in the openSBC.
Also, in openSBC product, is High Availability supported or it is
in roadmap ?
On 8/10/07,
Joegen E. Baclor > wrote:
inline...
Ashish Khare wrote:
Hi Baclor,
This is still not clear to me.
Lets take a example:
Sip Client A is talking to Sip Client B through
Proxy/B2BUA(P) which
handles only SIP signaling messages.
Now in Call, Sip Client A is trasnferred to Sip CLient C and
now B and
C are talking.
But still they are abel to talk.
Then how this case is different from yours. Can you please
elaborate
and explain to me.
There are two ways OpenSBC handles REFER. The default is to
relay the
REFER to the UA and let the UA do the transfer request. This
is ok
because the UA knows that there will be a change in the audio
session.
The second way (Local REFER) will not relay the REFER.
Instead OpenSBC
do the transfer. This leaves the other UA to not know that
the call is
actually transfered. If the transfer succeeded, a new media
would with
a different SSRC would have been created. If OpenSBC just
relays that,
the UA may reject the packets because the ssrc has already
changed.
we are considering to build ALG. We have our own SIP stack (
Proxy and
B2BUA ) but we dont have RTP stack. Also we dont want to
parse the
RTP stream. Just Rely it, based on source and destination IP and
ports. Is this feasible ?. We are also exploring your openSBC
if we
can used it.
Of course this is feasible. You will have to change some
lines of code
in the media interface but it wont take much. Just post
questions
about the code if you need to clarify something.
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
http://get.splunk.com/
_______________________________________________
opensipstack-devel mailing list
opensipstack-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
