Subject: RE: [Sipping] Transcoding

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 27 Feb 2005 19:31:41 +0100

Hi,

I wonder if this isn't part of a more generic discussion. We talk about transcoding, but I guess there could also be other functions which "have to be inserted" during the call setup (the IMS ALG is one example), either using route-inserting, re-routing or some other method. I don't see (and I guess David said the same thing) why the method to invoke a service should depend on if the node providing the service is a B2BUA or a proxy. The node invoking the function probably doesn't even know - it only knows the IP address and/or SIP-URI to the node providing the function. I guess the question is more how/if/when the end-user(s) should be aware, involved, and in control of what is happending.

Regards,

Christer Holmberg
Ericsson Finland

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