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
