Hi List,
i have to put an * between two other SIP gateways and due to some
circumstances, i have to use sip over tcp. With 1.6.2.6 this is working
fine: sip gw A (deverto4) sends the call, i hand it over to sip gw B
(ocs) and that's about it. In the other direction however (ocs -> me
->
deverto4) the call setup is complete but there is no audio.
I can see the audio in the form of tcpdump, but neither party hears the
other side. Tcpdump also shows that while the call setup is via tcp,
the audio is transmitted via udp. I'm guessing this is the reason of
silence. The first setup is working because one of the gateways are
supporting sip over tcp only and * accepts both.
my setup is pretty simple as * is only handing calls over to the
gateways. Relevant parts are below.
could anyone please confirm that it is an error, that asterisk sends the
RTP stream via udp and this is the cause of the silence? Is there any
way to tell asterisk to use tcp only? I'm aware of the drawbacks, but i
still need to get this working.
I'd appreciate any help.
thanks
adam
sip.conf:
tcpenable=yes
tcpbindaddr=0.0.0.0
[ocs]
type=friend
host=192.168.1.1
context=ocs
qualify=yes
transport=tcp
nat=no
canreinvite=no
disallow=all
allow=alaw
allow=ulaw
[deverto4]
type=friend
host=172.18.200.4
context=deverto
qualify=yes
nat=no
canreinvite=yes
transport=tcp
disallow=all
allow=alaw
allow=ulaw
and the extensions.conf:
[deverto]
exten => _X.,1,Dial(SIP/${EXTEN}@ocs)
exten => _+X.,1,Dial(SIP/${EXTEN}@ocs)
[ocs]
exten => _X.,1,Dial(SIP/${EXTEN}@deverto4)
exten => _+X.,1,Dial(SIP/${EXTEN}@deverto4)
I don't think RTP can be sent over TCP at all, it would defeat the whole
purpose of RTP. Even if you somehow manage to do so, voice quality will go
down the drain.
Zeeshan A Zakaria
--
Sent from my Android phone with K-9 Mail.
On 2010-04-23 3:27 PM, <adamk at 3a.hu> wrote:
Hi List,
i have to put an * between two other SIP gateways and due to some
circumstances, i have to use sip over tcp. With 1.6.2.6 this is working
fine: sip gw A (deverto4) sends the call, i hand it over to sip gw B
(ocs) and that's about it. In the other direction however (ocs -> me
->
deverto4) the call setup is complete but there is no audio.
I can see the audio in the form of tcpdump, but neither party hears the
other side. Tcpdump also shows that while the call setup is via tcp,
the audio is transmitted via udp. I'm guessing this is the reason of
silence. The first setup is working because one of the gateways are
supporting sip over tcp only and * accepts both.
my setup is pretty simple as * is only handing calls over to the
gateways. Relevant parts are below.
could anyone please confirm that it is an error, that asterisk sends the
RTP stream via udp and this is the cause of the silence? Is there any
way to tell asterisk to use tcp only? I'm aware of the drawbacks, but i
still need to get this working.
I'd appreciate any help.
thanks
adam
sip.conf:
tcpenable=yes
tcpbindaddr=0.0.0.0
[ocs]
type=friend
host=192.168.1.1
context=ocs
qualify=yes
transport=tcp
nat=no
canreinvite=no
disallow=all
allow=alaw
allow=ulaw
[deverto4]
type=friend
host=172.18.200.4
context=deverto
qualify=yes
nat=no
canreinvite=yes
transport=tcp
disallow=all
allow=alaw
allow=ulaw
and the extensions.conf:
[deverto]
exten => _X.,1,Dial(SIP/${EXTEN}@ocs)
exten => _+X.,1,Dial(SIP/${EXTEN}@ocs)
[ocs]
exten => _X.,1,Dial(SIP/${EXTEN}@deverto4)
exten => _+X.,1,Dial(SIP/${EXTEN}@deverto4)
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100423/d0704925/attachment.htm
SIP is just the control protocol, and can be negotiated over TCP or UDP. The actual payload is done over RTP, which is a UDP-based protocol. If you had to add firewall exceptions/PAT config for the TCP SIP traffic, you'll also need to add the same for RTP traffic as well. -- Nathan Clemons On Fri, Apr 23, 2010 at 12:21 PM, <adamk at 3a.hu> wrote:> Hi List, > > i have to put an * between two other SIP gateways and due to some > circumstances, i have to use sip over tcp. With 1.6.2.6 this is working > fine: sip gw A (deverto4) sends the call, i hand it over to sip gw B > (ocs) and that's about it. In the other direction however (ocs -> me -> > deverto4) the call setup is complete but there is no audio. > > I can see the audio in the form of tcpdump, but neither party hears the > other side. Tcpdump also shows that while the call setup is via tcp, > the audio is transmitted via udp. I'm guessing this is the reason of > silence. The first setup is working because one of the gateways are > supporting sip over tcp only and * accepts both. > > my setup is pretty simple as * is only handing calls over to the > gateways. Relevant parts are below. > > could anyone please confirm that it is an error, that asterisk sends the > RTP stream via udp and this is the cause of the silence? Is there any > way to tell asterisk to use tcp only? I'm aware of the drawbacks, but i > still need to get this working. > > I'd appreciate any help. > > thanks > adam > > > sip.conf: > > tcpenable=yes > tcpbindaddr=0.0.0.0 > > [ocs] > type=friend > host=192.168.1.1 > context=ocs > qualify=yes > transport=tcp > nat=no > canreinvite=no > disallow=all > allow=alaw > allow=ulaw > > [deverto4] > type=friend > host=172.18.200.4 > context=deverto > qualify=yes > nat=no > canreinvite=yes > transport=tcp > disallow=all > allow=alaw > allow=ulaw > > and the extensions.conf: > > [deverto] > exten => _X.,1,Dial(SIP/${EXTEN}@ocs) > exten => _+X.,1,Dial(SIP/${EXTEN}@ocs) > > [ocs] > exten => _X.,1,Dial(SIP/${EXTEN}@deverto4) > exten => _+X.,1,Dial(SIP/${EXTEN}@deverto4) >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100423/3660a9d9/attachment.htm
Doesn't surprise me if Microsoft tries sending RTP over TCP. Maybe their engineers didn't know basics of VoIP when they were programming their communication server. Zeeshan A Zakaria -- Sent from my Android phone with K-9 Mail. On 2010-04-24 12:04 PM, "Michael Graves" <mgraves at mstvp.com> wrote: On Fri, 23 Apr 2010 23:11:06 +0200, adamk at 3a.hu wrote:>Hi Guys, > >On 04-23-2010 21:40, Nathan Cle...Actually, it is more common for RTP to be over UDP, but RTP over TCP is possible. In fact, this is the default RTP mode for M$ Office Communications Server. I beleive that it may be possible to use RTP over TCP in Asterisk as there was someone work on this inorder to have interop with M$. Michael -- Michael Graves mgraves<at>mstvp.com http://www.mgraves.org o713-861-4005 c713-201-1262 sip:mgraves at mstvp.onsip.com <sip%3Amgraves at mstvp.onsip.com> skype mjgraves Twitter mjgraves -- _____________________________________________________________________ -- Bandwidth and Coloc... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100424/4c6981e6/attachment.htm
On Fri, Apr 23, 2010 at 3:21 PM, <adamk at 3a.hu> wrote:> i have to put an * between two other SIP gateways and due to some > circumstances, i have to use sip over tcp. ?With 1.6.2.6 this is working > fine: sip gw A (deverto4) sends the call, i hand it over to sip gw B > (ocs) and that's about it. ?In the other direction however (ocs -> me -> > deverto4) the call setup is complete but there is no audio.Don't do it. There have been any number of posts to asterisk-users begging asterisk to bend over backwards to accommodate Microsoft's foray into the world of VoIP. Nobody seems to be asking Microsoft to build a stack compatible with the rest of the world of VoIP. I disagree that sending SIP over TCP is superior to sending it over UDP. Think about it for a second. UDP is 'unreliable' in that lost packets are not rebroadcast. Now let's say you have an 'unreliable' connection where it's just barely good enough that the SIP call setup goes through, but the RTP stream immediately fails. Why would that be superior to having the SIP call setup getting dropped? The end result of no reliable voice is the same, but now you have a funkier debug condition that's going to be more complex to track down. I personally think it would be superior to see the bad connection as early in call setup as possible. And of course, SIP over UDP is the way the rest of the world works. If anybody wants to speak up about a framework that supports BOTH SIP over UDP AND SIP over TCP, maybe somebody already built a middleware layer that will let Microsoft join the world of voip.
RTP stands for Real-Time Transport Protocol. TCP is not designed to deal with real-time data transfer as it takes time to acknowledge packets and re-send them if missing. All audio video data transfer happens in real time, and it doesn't make any sense to retransmit missing packets. Real time packets mixed with old missing packets which are submitted would result in an non-understandable audio and video. So how come any system can use TCP for real time data transfer, while assuring the quality at the same time. Does their exist any such system? I would certainly like to try it, maybe they are doing it right using some trick which I don't know yet. Zeeshan A Zakaria -- Sent from my Android phone with K-9 Mail. On 2010-04-24 1:48 PM, "David Backeberg" <dbackeberg at gmail.com> wrote: On Fri, Apr 23, 2010 at 3:21 PM, <adamk at 3a.hu> wrote:> i have to put an * between two other SIP ga...Don't do it. There have been any number of posts to asterisk-users begging asterisk to bend over backwards to accommodate Microsoft's foray into the world of VoIP. Nobody seems to be asking Microsoft to build a stack compatible with the rest of the world of VoIP. I disagree that sending SIP over TCP is superior to sending it over UDP. Think about it for a second. UDP is 'unreliable' in that lost packets are not rebroadcast. Now let's say you have an 'unreliable' connection where it's just barely good enough that the SIP call setup goes through, but the RTP stream immediately fails. Why would that be superior to having the SIP call setup getting dropped? The end result of no reliable voice is the same, but now you have a funkier debug condition that's going to be more complex to track down. I personally think it would be superior to see the bad connection as early in call setup as possible. And of course, SIP over UDP is the way the rest of the world works. If anybody wants to speak up about a framework that supports BOTH SIP over UDP AND SIP over TCP, maybe somebody already built a middleware layer that will let Microsoft join the world of voip. -- _____________________________________________________________________ -- Bandwidth and Colocati... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100424/c2365b2c/attachment.htm
Adobe has not been successful in VoIP. I have worked for two companies who were trying to make flash phones, and it always came down to the issue of RTP over TCP. This is the primary reason there are no successfully working flash phones out there though some companies are trying to offer service over them. I once set it up myself using redphone and red5. But a java based RTP over UDP is what I ended up with, which simply works. I would suggest you to look into a java based solution. RTP is simply not meant for TCP, those who are doing it, they must not be using TCP as TCP. Zeeshan A Zakaria -- Sent from my Android phone with K-9 Mail. On 2010-04-24 3:07 PM, "Hans Witvliet" <hwit at a-domani.nl> wrote: On Sat, 2010-04-24 at 10:56 -0500, Michael Graves wrote:> On Fri, 23 Apr 2010 23:11:06 +0200, adamk...No, that was just sip over tcp (instead of udp) I friend of mine had an * talking to M$, so that was one of the reasons for early deployment of an 1.6.x asterisk... -- _____________________________________________________________________ -- Bandwidth and Colocat... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100424/491829d2/attachment.htm