View Single Post
Unread 05-13-2007, 11:59 AM   #6
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 voice bypassing VoXaLot

Originally Posted by martin View Post
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.
Thanks for that explaination. I can see, looking at the two SIP INVITE messages in the original post, that there are, as you say, two separate phone calls, each with their own (separate) set of credentials.

I've skimmed through RFC 3261 again.

The concept I imagined was the SDP body (the "message body" being carried by SIP) from my SIP phone (user agent client (UAC)) could traverse several SIP proxy servers on the way to the destination user agent server (UAS), and the series of SIP proxies would, through various logic, route the message appropriately, each "hop" taking it "closer" to the destination. A SIP proxy server might re-write the request URI, (and/or modify the SIP message in other ways allowed by the SIP specification), but would not touch the SDP body. In the words of RFC 3261:

The proxy MUST NOT add to, modify, or remove the message body.
It seems that the above concept works fine, except for when authentication for more than one SIP domain is needed (ie, more than one set of credentials are needed). RFC 3261 explains a user agent client authenticating itself (providing credentials) to a SIP proxy (in this context, or a UAS (in this context, the VSP (, but doesn't seem to provide a way for a SIP proxy ( to authenticate itself (provide credentials) to a UAS (

(I think I had mistakenly assumed that RFC 3261 included authentication between SIP proxies as part of the SIP proxy<->SIP proxy message routing.)

VoXaLot's method of establishing two separate phone calls (in doing so, VoXaLot is acting as a back-to-back user agent (B2BUA)), and then attempting to subsequently modify the media stream with re-INVITE messages is one way (possibly the only way) this can be handled, while still conforming to RFC 3261.

However, I'm not entirely convinced that, in doing this, it is necessary for VoXaLot to create a new SDP body and initially proxy the media, although I concede that changing the current arrangement could involve significant engineering effort for custom programming of Asterisk and/or Openser (or whatever VoXaLot uses).

My idea could be summarised as VoXaLot acting similar to a B2BUA in respect of the SIP part of the SIP messages, but not touching the SDP part (not having anything to do with the message body). This, I understand, would be fully RFC 3261-compliant, since RFC 3261 is about SIP, not SDP. (My understanding is that the authentication / credential details in RFC 3261 are not related to the SDP body).
v164 is offline   Reply With Quote