RE: [Sipping] Re: Transcoding and route entries

["Arnoud van Wijk" <[e-mail]>]

Can we be sure that there is no proxy on the route that may change the route
header in a way that the original route information and URI is lost?

If we can be sure that this is not going to happen, that the route header
with the URI will not change in the signalling path. Then I change my choice
into number 2 instead of 1.

Greetz

Arnoud

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands. 
Mobile: [phone]
International text telephone: [phone]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Gunnar Hellstrom
Sent: vrijdag 12 maart 2004 22:31
To: Tim Melanchuk; Rohan Mahy
Cc: Gonzalo Camarillo; Eric Burger; Jonathan Rosemberg; Adam Roach; Henning
Schulzrinne; sipping
Subject: RE: [Sipping] Re: Transcoding and route entries

I prefer 2.

In most cases you would think: "I want to call B."
Then, either you, yourself add "through the
transcoding service T", or that is added
automatically because of some analysis of
preferences registered by A and B.


Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Tim Melanchuk
> Sent: Friday, March 12, 2004 8:07 PM
> To: Rohan Mahy
> Cc: Gonzalo Camarillo; Eric Burger;
> Jonathan Rosemberg; Adam Roach;
> Henning Schulzrinne; sipping
> Subject: Re: [Sipping] Re: Transcoding
> and route entries
>
>
> i agree with rohan and prefer using
> route headers. a transcoding
> service seems much more akin to a relay
> along the path than it
> does a conference which is more a
> destination unto itself. if
> this can be achieved without (imho)
> inappropriately bending
> existing mechanism, it is preferable to
> new mechanism.
>
> timm
>
> Rohan Mahy wrote:
> > Hi Folks,
> >
> > This decision boils down to a
> question of semantics.  Does a URI in a
> > Route header mean:  1) send through
> this proxy, or 2) send through this
> > service or intermediary ?
> >
> > One of the important things to
> consider when there is a difference of
> > philosophy or opinion regarding
> semantics, is to consider if any harm
> > comes from either of the choices.  In
> this case, I can come up with no
> > technical reason that using a Route
> header is harmful.
> >
> > Another key question is if there is
> any precedent.  Again, the two
> > proposals both have some precedent.
> Conference bridges do not use the
> > Route header (the analogy of approach
> 1), but folks have been using
> > Route headers to direct SIP requests
> through B2BUAs for session border
> > control (gasp), policy control,
> P-CSCFs, etc.. for some time now (the
> > analogy of approach 2).  I can even
> dig up some old mail when we
> > encouraged 3GPP to use a loose-route
> for one of their many B2BUAs
> > instead of defining some piece of new
> mechanism.  Taking this a step
> > further, we've been talking about how
> *proxies* can use session policy
> > to meet logging requirements.  I
> think this is very similar to
> > transcoding, since some entity
> operating on behalf of both
> > intermediaries (transcoder and
> logging proxy) need to see the media.
> >
> > Finally there is the question of
> using existing mechanism vs. inventing
> > new mechanism.  If the existing
> mechanism fits, I see no reason to
> > define new mechanism unless a more
> general approach to other problems
> > is achievable with the new mechanism.
>  Nobody is proposing using the
> > new mechanism proposed in (1) to do
> anything else.  Also, the
> > conference bridge analogy breaks IMO
> since conference bridges do not
> > use this new mechanism to indicate
> the other participants in the
> > conference.
> >
> > In summary, I prefer option 2 (use
> the Route header).  The approach
> > causes no harm, has precedent for
> existing usage, and requires no new
> > special-purpose mechanism.
> >
> > thanks,
> > -rohan
> >
> >
> >
> >
> > On Mar 12, 2004, at 3:28 AM, Gonzalo
> Camarillo wrote:
> >
> >> Folks,
> >>
> >> during the SIPPING session, I
> presented the following draft:
> >>
> http://www.ietf.org/internet-drafts/draf
> t-camarillo-sipping-transc-
> >> b2bua-01.txt
> >>
> >> We discussed whether or not it is
> appropriate to use Route headers to
> >> introduce a B2BUA in the path. The
> two options are:
> >>
> >> A and B are the UAs, and T is the
> transcoder, which is a B2BUA
> >>
> >> -----     -----     -----
> >> | A |-----| T |-----| B |
> >> -----     -----     -----
> >>
> >> 1) Without using Route
> >>
> >> INVITE T
> >> Body: B
> >>
> >> 2) Using Route
> >>
> >> INVITE B
> >> Route T
> >>
> >>
> >> Reasons for using option 1:
> >>
> >> - T is behaving as a conference
> server, so we should invoke it in the
> >> same way as we invoke a conference.
> >> - Route headers are intended for
> proxies, not for B2BUAs.
> >> - If we start using Route headers to
> invoke B2BUAs, what is the
> >> meaning of e2e or e2m security? T
> would be the recipient of the
> >> headers in the message, but T would
> not appear in the Request-URI...
> >>
> >> Reasons for using option 2:
> >> - sessions with and without
> transcoder are invoked in the same way.
> >>
> >> I would like to hear your opinions.
> Mine is that we should go for
> >> option 1.
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >>
> >>
> >> This communication is confidential
> and intended solely for the
> >> addressee(s). Any unauthorized
> review, use, disclosure or
> >> distribution  is prohibited. If you
> believe this message has been sent
> >> to you in  error, please notify the
> sender by replying to this
> >> transmission and  delete the message
> without disclosing it. Thank you.
> >>
> >> E-mail including attachments is
> susceptible to data corruption,
> >> interruption, unauthorized
> amendment, tampering and viruses, and we
> >> only send and receive e-mails on the
> basis that we are not liable for
> >> any such corruption, interception,
> amendment, tampering or viruses or
> >> any consequences thereof.
> >>
> >
> >
> >
> _______________________________________________
> > Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the
application of SIP
> Use [e-mail] for
questions on current sip
> Use [e-mail] 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 [e-mail] for questions
on current sip
Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP