View Single Post
Unread 06-23-2007, 09:24 AM   #9
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default RTPproxy for transcoding

Originally Posted by martin
Unfortunately it is not quite that simple. As there are 2 lots of credentials involved:


Two calls must be established. Once the calls are established the re-invites are required.
That explains why VoXaLot passes on the SDP body, unmodified, when the call is destined for a SIP URI (sip code or enum lookup), where there are no credentials required for the next "leg".

In this case, the voice packets bypass VoXaLot from the beginning, however my tests today have shown that, in this situation, the RTP proxy doesn't help when it is needed (for transcoding).

Originally Posted by v164 View Post
In other words, the RTP proxy is only called into service where the alternative would be for the call to fail. I think this is a good backup to have, because some SIP devices only have ulaw, for example, yet someone on a low bandwidth link would have to insist on a lower bandwidth codec.

As far as RTP proxying for the purpose of transcoding is concerned, I would think that the availability of transcoding is more important when the call is destined to a SIP URI (ENUM / SIP code lookup) than when the call is going out via a provider. The reason being that, in the case of the provider, we know, in advance, which codecs the provider supports, and the onus is on the provider to do any transcoding if necessary. However, in the case of a SIP URI obtained via ENUM / SIP code lookup, to which your call may be automatically re-directed, it is not known in advance which codecs that endpoint accepts, hence there is a risk that the call may fail due to incompatible codecs.
v164 is offline   Reply With Quote