Re: Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Yes. RFC3455, section 4.2.2.2.

/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 4:11 PM, Francois Audet <[email protected]> wrote:

> Does p-called-header include URI parameters?
>
>
> On Mar 12, 2009, at 7:07, "Christer Holmberg" <
> [email protected]> wrote:
>
>
>  Hi,
>
> IF we would remove that requierment, and ONLY care about the case when the
> R-URI is replaced with the CONTACT, I don't think we need to do anything. I
> believe P-Called-Party-ID already solves that.
>
> Regards,
>
> Christer
>
>  ------------------------------
> *From:* [email protected] [mailto:[email protected]<[email protected]>]
> *On Behalf Of *Elwell, John
> *Sent:* 12. maaliskuuta 2009 15:31
> *To:* Hans Erik van Elburg
> *Cc:* <[email protected]>[email protected]
> *Subject:* Re: [Sip] Terminology (was RE: Fwd:
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
>  Hans Erik,
>
> The way I interpreted the 01 draft, you would not get the freephone number
> anyway. If that is a requirement, then I accept my suggestion won't suffice
> .
>
> John
>
>  ------------------------------
> *From:* Hans Erik van Elburg [mailto:[email protected]<[email protected]>]
>
> *Sent:* 12 March 2009 12:57
> *To:* Elwell, John
> *Cc:* <[email protected]>[email protected]
> *Subject:* Re: [Sip] Terminology (was RE: Fwd:
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
> But that does not solve the freephone service use case. Freephone
> represents a use case where the R-URI is replaced with an AoR of user B -
> not with the contact of user B.
>
> A calls Bfreephonenumber routed the B (AOR) routed to B's contact.
>
> The target-uri draft is interested in obtaining: Bfreephonenumber as that
> is what A used to reach B.
>
> So what we like to see that B UA receives is something like
>     H-I:  Bfreephone; "istarget",\
>         B,\
>         contact-B
>
> So you want to get Bfreephonenumber and not B.
>
> In certain situations you are also interested in B, I guess that  PBX's
> would interested in that to deliver to the correct user. We could
> distinguish them like:
>     H-I:  Bfreephone; "istarget",\
>         B,"aor"\
>         contact-B
>
> BR,
> /Hans Erik van Elburg
>
>
> On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John < <[email protected]>
> [email protected]> wrote:
>
>> If 'istarget' is used only to identify the value that was overwritten in
>> the Request-URI by a contact URI, an alternative approach would be to
>> flag the contact URI H-I entry as 'iscontact'. Then the UAS would just
>> need to look for the most recent H-I entry that is not marked
>> 'iscontact'.
>>
>> John
>>
>>
>> ________________________________
>>
>>        From: <[email protected]>[email protected] [mailto:<[email protected]>
>> [email protected]] On
>> Behalf Of Hans Erik van Elburg
>>        Sent: 12 March 2009 08:35
>>        To: Mary Barnes
>>        Cc: <[email protected]>[email protected]
>>        Subject: Re: [Sip] Terminology (was RE: Fwd:
>> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>>
>>
>>        Yes, because you are using the 3261 use of target and the
>> 4244bis introduced definition of retarget. I thought it was clear that
>> we need other words as those definitions don't match the target-uri
>> drafts use of the terms. Also they do not suffice to provide a solution
>> for the use cases in the target-uri draft.
>>
>>        The 3261 text you refer to is exactly about the case where the
>> home proxy overwrites the Request-URI with a new target. This target is
>> teh registered contact address. And hence this would be what target-uri
>> calls a hop or a route. This case and this is where it gets confusing is
>> not a "retarget" in the target-uri draft use of the term.
>>
>>        The target-uri draft states:
>>
>>           "To avoid confusion, we
>>           refer to a SIP URI that is an address for a user or resource
>> as a
>>           "target" and a SIP URI that is a hop for reaching that user
>> as a
>>
>>           "hop".
>>
>>
>>        Apparently that does not suffice to avoid confusion.
>>
>>        As for the tagging, speaking about the solution before agreeing
>> on the terminology and the problem it should solve is meaningless.
>>
>>        /Hans Erik van Elburg
>>
>>
>>
>>        On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes
>> < <[email protected]>[email protected]> wrote:
>>
>>
>>                Responses below [MB].
>>
>>
>>                -----Original Message-----
>>                From: Hans Erik van Elburg
>> [mailto: <[email protected]>[email protected]]
>>
>>                Sent: Wednesday, March 11, 2009 6:42 PM
>>                To: Barnes, Mary (RICH2:AR00)
>>                Cc: Shida Schubert; <[email protected]>[email protected]
>>                Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
>>                ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>>
>>
>>                I was talking about the concept.
>>
>>                The use cases only describe  cases where the target-uri
>> (lets call that
>>                current target from now) has been lost when an initial
>> request for a
>>                dialog or standalone request arrives at the UAS.
>>
>>                [MB] And I think this is where the terminology confusion
>> starts - I
>>                don't think of the "lost" target-uri as being the
>> "current" target. In
>>                my mind, the "current" target is reflected by the last
>> hi-entry and the
>>                request-uri in the incoming request at the UAS. If the
>> entity that sent
>>                the request was the entity that added the last hi-entry,
>> then the uri in
>>                that hi-entry is the same as the request-URI in the SIP
>> request that
>>                arrives at the UAS. I refer to the "lost" uri as the one
>> that was
>>                "retargeted" - that's the one the UAS wants to pull from
>> the hi-entries
>>                in the incoming request. That hi-entry was not the one
>> that was just
>>                added by the entity that built the request just received
>> by the UAS.
>>                That hi-entry is tagged with whatever name we are going
>> to tag it with
>>                BEFORE the request is forwarded (using the term forward
>> per section 16.6
>>                of RFC 3261).  That tag is added once the target set of
>> potential
>>                candidates for the new request uri are determined in
>> section 16.5 of
>>                3261 (with "target set" being a 3261 term), just before
>> the request is
>>                forwarded in section 16.6 to one of those targets.  A
>> new hi-entry
>>                (which will be the last hi-entry in the request received
>> by the UAS) is
>>                added in section 16.6 of 3261 as the request is
>> forwarded.  At this
>>                point in time, the lost information is in the previous
>> hi-entry when the
>>                outgoing request is sent. [/MB]
>>
>>
>>                What has been lost is the current target of the request:
>>
>>                [MB] Right - at which point in my mind, it's no longer
>> the current
>>                target ;) Maybe we call it "lost". [/MB]
>>
>>
>>
>>                     Current target
>>
>>                  The current target of an initial request for a dialog
>> or standalone
>>                  request is the name or address to which the request is
>> targeted, i.e.
>>                  either the initial target inserted in the Request-URI
>> by the UAC that
>>                  originates the request, or when a retarget occurred,
>> the target
>>                  provided in that retarget operation.  Reroute and
>> translation
>>                  operations never change the current target.
>>
>>
>>                [MB] I don't think this definition fits what you want -
>> i.e., if there
>>                is no retargeting, then none of the hi-entries are
>> tagged - i.e., you
>>                won't have your concept of current. The way it works is
>> that if no
>>                hi-entries are tagged, then you know that there was no
>> retargeting, thus
>>                you know the request-uri has not been lost. [/MB]
>>
>>
>>                This defintion only makes sense when the following
>> definitions are used:
>>
>>                Name:
>>
>>                  A name is a moniker for an entity which refers to it
>> in a way which
>>
>>                  reveals nothing about where it is in a network.  In
>> SIP, tel URI
>>
>>                  which doesn't represent the location of the entity is
>> a name.
>>
>>
>>                Address:
>>
>>                  An address is an identifier for an entity which
>> describes it by its
>>
>>                  location on the network.  In SIP, the SIP URI itself
>> is a form of
>>
>>                  address because the host part of the URI, the only
>> mandatory part of
>>
>>                  the URI besides the scheme itself, indicates the
>> location of a SIP
>>
>>                  server that can be used to handle the request.
>>
>>                Route:
>>
>>                  Finally, a route is a   sequence of SIP entities
>> (including the UA
>>                itself!) which are
>>
>>                 traversed in order to forward a request to an address
>> or name.
>>
>>                Retarget (other term might be needed, as this is highly
>> confusing):
>>
>>                   A Request-URI rewrite operation that changes the
>> target identity of
>>                the request.
>>
>>                Reroute (other term might be needed):
>>
>>                   A Request-URI rewrite operation that does not change
>> the current
>>                target of the request, but     determines the route/next
>> hop taken to
>>                reach the target-identity.
>>
>>                /Hans Erik
>>
>> _______________________________________________
> Sip mailing list   <https://www.ietf.org/mailman/listinfo/sip>
> https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
>
>

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip