View Single Post
Unread 05-05-2007, 10:24 AM   #3
v164
Member
 
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

Quote:
Originally Posted by martin View Post
Under the new platform, if the user sets this value to "No" Voxalot will do 2 things:

1. It will disable the RTPProxy for the user and
2. Voxalot will initiated the RE_INVITEs rather than relying on the end points to do so.
I hope your team can get it to work, Martin, but with these "re-INVITES" in the mix, things are starting to get really complicated.


I'm not an expert on SIP, but I would have thought that RTPproxying would work like this:

- VoXaLot forwards the SDP body, unmodified, to the call destination (VSP, etc).

- If the call destination responds with "488 Not Acceptable Here" (the normal error message if the codecs offered are not OK), VoXaLot would then offer a revised SDP body, referring to VoXaLot's RTP proxy, and containing the codecs that VoXaLot's RTP proxy is prepared to transcode.

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.

I feel that using re-INVITES is kind of pushing the boundaries of SIP compatibility, such that some SIP devices will fail to handle it.
v164 is offline   Reply With Quote