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

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]] On Behalf  
> Of Elwell, John
> Sent: 12. maaliskuuta 2009 15:31
> To: Hans Erik van Elburg
> Cc: [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]]
> Sent: 12 March 2009 12:57
> To: Elwell, John
> Cc: [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] 
> > 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] [mailto:[email protected]] On
> Behalf Of Hans Erik van Elburg
>        Sent: 12 March 2009 08:35
>        To: Mary Barnes
>        Cc: [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]> wrote:
>
>
>                Responses below [MB].
>
>
>                -----Original Message-----
>                From: Hans Erik van Elburg
> [mailto:[email protected]]
>
>                Sent: Wednesday, March 11, 2009 6:42 PM
>                To: Barnes, Mary (RICH2:AR00)
>                Cc: Shida Schubert; [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
> 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