Subject: RE: [Sipping] Transcoding

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

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