Topic GTalk2VoIP / General discussions and support for users / P2P call between SIP & gtalk (924 hits)
Hi,
I am developing a gtalk in linux using libjingle.
I have integrated gtalk2voip function in my client too.
gtalk2voip service is great. I can call MSN/Yahoo/SIP/PSTN in my gtalk client.
One thing I don't understand that why all the RTP traffic should be relay to gtalk2voip gateway.
Since gtalk will support ICE protocol, all the RTP traffic can be sent/received from other side.
I would like gtalk2voip can modify the SDP header of the SIP packet based on gtalk transport information.
Therefore, we can establish a P2P connection without relay.
This also increase the reliability of gtalk2voip gateway because the total traffic will be shared with gtalk client and google relay server.
I think it is possible to do that.
I am developing a gtalk in linux using libjingle.
I have integrated gtalk2voip function in my client too.
gtalk2voip service is great. I can call MSN/Yahoo/SIP/PSTN in my gtalk client.
One thing I don't understand that why all the RTP traffic should be relay to gtalk2voip gateway.
Since gtalk will support ICE protocol, all the RTP traffic can be sent/received from other side.
I would like gtalk2voip can modify the SDP header of the SIP packet based on gtalk transport information.
Therefore, we can establish a P2P connection without relay.
This also increase the reliability of gtalk2voip gateway because the total traffic will be shared with gtalk client and google relay server.
I think it is possible to do that.
Hello Wilson,
It's nice to hear that you undestand things behind Jingle Audio . Well, what you described was our first/initial idea, but as soon as we started to implement SIP we faced lots of issues, like 90% of SIP implementaions do not support ICE, and those which support they cannot receive SDP updates throughout the session. So, should we follow this idea it would made our gateway 99% incompatible with SIP.
Besides, you must note the SIP is not the only VoIP protocol we have, we also do H.323 alot, and other VoIM (MSN, Yahoo, AIM). All of them give no ideas about ICE.
Regards,
Ruslan.
It's nice to hear that you undestand things behind Jingle Audio . Well, what you described was our first/initial idea, but as soon as we started to implement SIP we faced lots of issues, like 90% of SIP implementaions do not support ICE, and those which support they cannot receive SDP updates throughout the session. So, should we follow this idea it would made our gateway 99% incompatible with SIP.
Besides, you must note the SIP is not the only VoIP protocol we have, we also do H.323 alot, and other VoIM (MSN, Yahoo, AIM). All of them give no ideas about ICE.
Regards,
Ruslan.
I can image that there are a lots of issues.
If we can focus on GizmoProject/MSN/Yahoo, I think it is easy to do it.
I know that most SIP client can support HOLD/UNHOLD feature through 0.0.0.0 in SDP
In this case, we don't need the other side to support ICE.
gtalk2voip relay server can setup the relay first.
Once we can determinate the public ip/port between gtalk/sip client.
we send RE-INVITE to SIP client to modify the RTP session.
Gtalk seems also support modification of the transport session.
Is it possible to do it? Just a suggestion.
If we can focus on GizmoProject/MSN/Yahoo, I think it is easy to do it.
I know that most SIP client can support HOLD/UNHOLD feature through 0.0.0.0 in SDP
In this case, we don't need the other side to support ICE.
gtalk2voip relay server can setup the relay first.
Once we can determinate the public ip/port between gtalk/sip client.
we send RE-INVITE to SIP client to modify the RTP session.
Gtalk seems also support modification of the transport session.
Is it possible to do it? Just a suggestion.
Hello Wilson,
Well, in theory it could work, but I don't feel like starting to implement all the stuff and face lots compatibility issues when 70% of the way behind . BTW, there's another issue - Google Talk's ICE is not really 100% standard complient, it uses some attributes in STUN packets that are not defined by ICE. So, it is pretty hard to make it working P2P with the rest SIP world. Anyway, we thought about that and we have some ideas on how to proxy STUN/ICE packets and to make RTP flow directly between endpoints, perhaps in some future we will come out with an improved version of the gateway .
Regards,
Ruslan.
Well, in theory it could work, but I don't feel like starting to implement all the stuff and face lots compatibility issues when 70% of the way behind . BTW, there's another issue - Google Talk's ICE is not really 100% standard complient, it uses some attributes in STUN packets that are not defined by ICE. So, it is pretty hard to make it working P2P with the rest SIP world. Anyway, we thought about that and we have some ideas on how to proxy STUN/ICE packets and to make RTP flow directly between endpoints, perhaps in some future we will come out with an improved version of the gateway .
Regards,
Ruslan.
Ok. Thanks.
gtalk2voip is a good thing.
I understand compatibility is more important.
I feel that the current implementation still need some improvement.
I found that the bridging between MSN/gtalk is not very stable.
Sometimes, the will be offline.
That's why I want to give you some suggestion to lower the bandwidth of your gateway.
Hope you can come out better gateway.
gtalk2voip is a good thing.
I understand compatibility is more important.
I feel that the current implementation still need some improvement.
I found that the bridging between MSN/gtalk is not very stable.
Sometimes, the will be offline.
That's why I want to give you some suggestion to lower the bandwidth of your gateway.
Hope you can come out better gateway.
BTW, Wilson, can we have a look on your Linux gtalk software ?
Regards,
Ruslan.
Regards,
Ruslan.
Ruslan, I am sorry.
This is project in my company.
I cannot share this with you.
I am using libjingle to implement the gtalk phone.
This is project in my company.
I cannot share this with you.
I am using libjingle to implement the gtalk phone.
Hello Wilson,
Ok, I understand.
BTW, I hope you already realized that libjingle is pretty crappy library and is not suitable for any real world implication. Back in early 2006 we were trying to use it for the gateway but soon we realized that it's virtually impossible to do anything based on libjingle, so I coded my own Jingle Audio lib in less than two weeks which is less than 2000 lines of C++. I strictly suggest you to throw away libjingle and reimplement Jingle protocol on the ground.
Anyway. Since you are developing some decent Jingle Audio based software we can talk about some partnership here. If you or your company is interested, please mail us to .
Regards,
Ruslan.
Ok, I understand.
BTW, I hope you already realized that libjingle is pretty crappy library and is not suitable for any real world implication. Back in early 2006 we were trying to use it for the gateway but soon we realized that it's virtually impossible to do anything based on libjingle, so I coded my own Jingle Audio lib in less than two weeks which is less than 2000 lines of C++. I strictly suggest you to throw away libjingle and reimplement Jingle protocol on the ground.
Anyway. Since you are developing some decent Jingle Audio based software we can talk about some partnership here. If you or your company is interested, please mail us to .
Regards,
Ruslan.
yes. there are so many bugs in libjingle even 0.4
I have fixed them by using valgrind.
I have rewrited the mediastreamer too.
we are not a pure software company. therefore, we need a quick solution and it is not GPL code too.
it is the reason why I use libjingle.
You means that 2000 c++ code implement all the function in libjingle. xml parser, xmpp, http client, rtp, stun,.....
It is excellent job!!!
I have fixed them by using valgrind.
I have rewrited the mediastreamer too.
we are not a pure software company. therefore, we need a quick solution and it is not GPL code too.
it is the reason why I use libjingle.
You means that 2000 c++ code implement all the function in libjingle. xml parser, xmpp, http client, rtp, stun,.....
It is excellent job!!!
Hello Wilson,
Thanks for your suggestions, but bandwidth is totally not an issue here. Our main problem is a number of bugs in the code which effect gateway stability and are pretty hard to fix, expecially when it's multi-threaded code running on SMP systems. Nontheless we are cleaning our code step by step and I hope it soon becomes pretty stable.
Regards,
Ruslan.
Thanks for your suggestions, but bandwidth is totally not an issue here. Our main problem is a number of bugs in the code which effect gateway stability and are pretty hard to fix, expecially when it's multi-threaded code running on SMP systems. Nontheless we are cleaning our code step by step and I hope it soon becomes pretty stable.
Regards,
Ruslan.
you can try valgrind, http://valgrind.org/
It can detect memory invalid access and multi-thread problem too.
It is a great tools.
It can detect memory invalid access and multi-thread problem too.
It is a great tools.
Hello Wilson,
I know about valgrind and massif and other tools, but they don't help must to resolve deadlocks and pointers pointing to missing objects (once another thread freed them). Besides in SMP environment it's hard reduce memory footprint to avaid cache flushing, etc.
Those 2000 lines are jingle + xmpp implementation (rtp is part of jingle code since ICE takes tight integration), xml parser was written by my colleague and it's less than 300 lines in C++.
Regards,
Ruslan
I know about valgrind and massif and other tools, but they don't help must to resolve deadlocks and pointers pointing to missing objects (once another thread freed them). Besides in SMP environment it's hard reduce memory footprint to avaid cache flushing, etc.
Those 2000 lines are jingle + xmpp implementation (rtp is part of jingle code since ICE takes tight integration), xml parser was written by my colleague and it's less than 300 lines in C++.
Regards,
Ruslan
I think that Memcheck can detect the pointers poiting to missing objects.
How about Helgrind? is it useful to detect deadlocks?
How about Helgrind? is it useful to detect deadlocks?
By cyex Date 2008-03-28 10:30
Hello Wilson,
Regards,
Cyex.
Regards,
Cyex.
Topic GTalk2VoIP / General discussions and support for users / P2P call between SIP & gtalk (924 hits)