Subject: RE: [Sipping] Transcoding

From: "Andrew Graydon" <[email-masked]>
Date: Sun, 27 Feb 2005 09:53:09 -0500

I think that this is a very important point which we need to elaborate on, since this functionality of the IMS ALG could be critical in the decisions we make on the overall concept of the message flow and the alterations necessary for the header. In the case where the IMS ALG is a transparent proxy, allowing it to alter the header and TCP destinations of the message, coupled with the ability to enforce certain policies based upon the content of the massage and other administrator-based or business-based decisions in the implementation, then it may be useful to define the IMS ALG as being on the 'perimeter' of all transport to the IMS. Any comments ?

Andrew

-----Original Message-----
From:	Christer Holmberg (JO/LMF) [mailto:[email-masked]]
Sent:	Sun 27/02/2005 7:37 AM
To:	'Andrew Graydon'; David R Oran; Gonzalo Camarillo (JO/LMF)
Cc:	Paul Kyzivat; sipping; Medhavi Bhatia
Subject:	RE: [Sipping] Transcoding

Hi,

>I am a bit unsure as to why you would have to send the 305. If the IMS
>ALG is not only forwarded the message, but is actually a transparent
>proxy in the message flow, rather than trying to be a 
>separate proxy or B2BUA, then the ALG is able to redirect the message to the destination
>or next hop, altering the headers if necessary but also able 
>to perform it functionality.

Correct. But, the 305 would be sent in cases where the IMS ALG is not in the initial "message flow".

Regards,

Christer Holmberg
Ericsson Finland

> ______________________________________________________________
> __________
> Andrew Graydon                                 Phone: 
> 905-804-1855 x289
> V.P. Technology                                Fax:   905-804-1865
> Borderware Technologies Inc.                   
> http://www.borderware.com
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg (JO/LMF)
> Sent: February 25, 2005 2:22 AM
> To: 'David R Oran'; Gonzalo Camarillo (JO/LMF)
> Cc: 'Paul Kyzivat'; 'sipping'; Medhavi Bhatia
> Subject: RE: [Sipping] Transcoding
> 
> 
> Hi,
> 
> Another solution for inserting the IMS ALG that was presented was to
> actually forward (instead of sending 305) the INVITE directly 
> to the IMS
> ALG, eg an intermediate node (in this case the S-CSCF) inserts a Route
> header in the request, pointing to the IMS ALG, and sends the message
> there.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> > -----Original Message-----
> > From: David R Oran [mailto:[email-masked]]
> > Sent: 24. helmikuuta 2005 18:13
> > To: Gonzalo Camarillo (JO/LMF)
> > Cc: 'Paul Kyzivat'; Christer Holmberg (JO/LMF); 'sipping'; Medhavi 
> > Bhatia
> > Subject: Re: [Sipping] Transcoding
> > 
> > 
> > 
> > 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.
> > 
> > > Thanks,
> > >
> > > Gonzalo
> > >
> > > Christer Holmberg (JO/LMF) wrote:
> > >> 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
> > >
> > > -- 
> > > 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
> > >
> > David R. Oran
> > Cisco Fellow
> > Cisco Systems
> > 7 Ladyslipper Lane
> > Acton, MA 01720 USA
> > Tel: +1 978 264 2048
> > Email: [email-masked]
> > 
> 
> _______________________________________________
> 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
> 
> 

_______________________________________________
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