Quote:
Originally Posted by martin
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.