RE: [Sipping] Re: Transcoding and route entries

["Gunnar Hellstrom" <[e-mail]>]

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