Subject: RE: [Sipping] Transcoding

From: "Medhavi Bhatia" <[email-masked]>
Date: Sun, 27 Feb 2005 11:12:52 -0500

The border devices in the IMS are the P- or I-CSCFs. I believe the ALG is
controlled via the S-CSCF (core) or the AS (core). In terms of media, you
could consider it a border device.

> -----Original Message-----
> From: Andrew Graydon [mailto:[email-masked]]
> Sent: Sunday, February 27, 2005 9:53 AM
> To: Christer Holmberg (JO/LMF); Andrew Graydon; David R Oran; Gonzalo
Camarillo
> (JO/LMF)
> Cc: Paul Kyzivat; sipping; Medhavi Bhatia
> Subject: RE: [Sipping] Transcoding
> 
> 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