Subject: RE: [Sipping] Transcoding

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 24 Feb 2005 11:28:37 +0100

Hi,

A short comment on the re-direction case.

>>or using a re-direction at the callee side.
>Problem with that is the redirect needs to somehow specify both the 
>transcoder address and the address of the UAS. How is that 
>going to work?

I think you could use 305. My understanding is that the destination of the INVITE is still the same as in the INVITE that was re-directed, but the message must traverse via the proxy indicated in the Contact header.

The RFC does say that 305 must only be sent by a UAS, though, but I see no reason for that.

Also, 305 has been proposed in 3GPP as one option to re-direct a SIP message to the IMS ALG node in IMS.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Feb 2005 16:35:26 +0200

Hi,

before jumping into this type of solution, we have to decide whether or 
not we want to treat B2BUAs as proxies. That is, invoke them using Route 
header fields, etc... this is something we do not have agreement on yet...

Thanks,

Gonzalo

Christer Holmberg (JO/LMF) wrote:
> I think you could use 305. My understanding is that the destination of
> the INVITE is still the same as in the INVITE that was re-directed, but
> the message must traverse via the proxy indicated in the Contact header.
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Nathan Allen Stratton <[email-masked]>
Date: Thu, 24 Feb 2005 10:57:36 -0500 (EST)

> header fields, etc... this is something we do not have agreement on yet...

Are their any transcoding solutions out there that work with any of the
SBCs currently sold today? We have been looking at transcoding for quite
some time, our sister company is Convergent Network and the ICS2000 is
able to transcode between iLBC, G.726, G.729, and G.711 today, however we
are having problems getting SBC vendors into working with us on
transcoding. They don't necessarily agree with us that their is a market
for it so anything we do needs to be simple.

Our SBC vendor has the ability to route based on SDP, so outbound calls
are easy, if an INVITE comes in with say iLBC as primary CODEC we send
that invite to the ICS2000, it changes the SDP to be it's public IP and
then sends that INVITE back to the SBC, to Appserver then to remote
endpoint.

This works, does not required anything extra, but of course the problem is
it ONLY works for outbound calls, since the logic gets much more complex
to insert the ICS2000 transcoding gateway based on 200 OK.

Would love to know of a more elegant and easy for the SBC vendor to
implement solution.

-Nathan

---

From: David R Oran <[email-masked]>
Date: Thu, 24 Feb 2005 11:13:29 -0500

On Feb 24, 2005, at 9:35 AM, Gonzalo Camarillo wrote:

> Hi,
>
> before jumping into this type of solution, we have to decide whether 
> or not we want to treat B2BUAs as proxies. That is, invoke them using 
> Route header fields, etc... this is something we do not have agreement 
> on yet...
>
Since you have no idea when you route to something with a URI whether 
you will reach a proxy, a UAS, a redirect server, or a black hole, does 
this make any practical difference? Saying you can't put the address of 
a B2BUA into a Route header is unenforceable, and worse, 
unascertainable except by looking beyond the event horizon of that 
entity.

>>> transcoder address and the address of the UAS. How is that going to 
>>> work?
>> The RFC does say that 305 must only be sent by a UAS, though, but I 
>> see
>> no reason for that.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]