Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 16 Jun 2009 14:02:51 -0400

I do not think toll free is a 3GPP term

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Francois Audet <[email-masked]>
Cc: [email-masked] <[email-masked]>; Shida Schubert <[email-masked]>
Sent: Tue Jun 16 14:00:22 2009
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

Bringing back the 3gpp definition:

*Alias Public User Identities:* A Public User Identity is an alias of 
another Public User Identity if both identities belong to the same 
implicit registration set, are linked to the same service profile and 
have the same service data configured for each and every service.

In this sense the freephone number that I have is not an alias of my 
normal AOR, because different service logic is invoked and different 
service data applies.

You had a similar definition in 4244bis.

BR,
/Hans Erik

Francois Audet wrote:
> I'm thinking it's the first case we are talking about.
>
> The second case IMHO is multiple logical users.
>
> But I see your point. We need to word this carefully.
>
>
> Christer, I still don't get what's wrong with the 
> 3GPP terminology. Can you clarify? 
>
>   
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email-masked]] 
>> Sent: Tuesday, June 16, 2009 10:44
>> To: Audet, Francois (SC100:3055)
>> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary 
>> (RICH2:AR00); Shida Schubert; [email-masked]
>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri
>>
>> Francois Audet wrote:
>>
>>     
>>>> But, I think there is a small missunderstading for the AOR-to-AOR 
>>>> cases.
>>>>
>>>> We don't think you need to know whether the new AOR is an alias or 
>>>> not. You need to know whether the new AOR belongs to the 
>>>>         
>> same user or 
>>     
>>>> not.
>>>>         
>>> To me, that is the definition of an alias.
>>>       
>> I have to differ here.
>>
>> I may own a bunch of AORs. Some of them may be aliases, 
>> others may not be. For instance:
>>
>> - sip:[email-masked] and [email-masked]
>>    might be aliases.
>>
>> - sip:[email-masked] and sip:[email-masked]
>>    may be designed to bucket specific kinds of traffic, and so
>>    not be aliases.
>>
>> 	Thanks,
>> 	Paul
>>
>>     
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 17 Jun 2009 06:17:33 -0400

I agree with Roland

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Wed Jun 17 02:00:38 2009
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

I have slide concerns with that approach. Some network operators does not like to present all the way of messages.
Even if the entry is anonymous the amount of entries will show the network structure which could also raise security concerns.

BR, Roland 

-----Ursprüngliche Nachricht-----
Von: Francois Audet [mailto:[email-masked]] 
Gesendet: Dienstag, 16. Juni 2009 19:22
An: Jesske, Roland; [email-masked]; [email-masked]; Mary Barnes; [email-masked]
Cc: [email-masked]
Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

In the new draft, the entries are always there and never removed. It makes
HI much more reliable.

If entries need to be anonymous, they are anonymized but the entry is still there. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, June 15, 2009 22:38
> To: Audet, Francois (SC100:3055); 
> [email-masked]; [email-masked]; 
> Barnes, Mary (RICH2:AR00); [email-masked]
> Cc: [email-masked]
> Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri
> 
> Such values looks good and gives more guideline why the entry 
> was included.
> My question would be if there is a different network 
> behaviour foreseen for the History mechanism.
> Perhaps some of the networks needs the history only to 
> indicate where the URI were mapped ("mp") and others would 
> really track the whole history of each SIP proxy.
> Or is it only seen either to support history full  or not.
> 
> BR,
> 
> Roland  
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Francois Audet
> Gesendet: Dienstag, 16. Juni 2009 03:44
> An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; 
> Shida Schubert
> Cc: [email-masked]
> Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri
> 
> All right guys,
> 
> I've been thinking about this.
> 
> It seems to me that what we want to capture is:
> 1) If the target is an AOR, a contact, or a routing URI 
> (maddr, noop intra-domain, or noop
>    forward to next domain, or strict routing).
> 2) In the case that the target is an AOR, then if that AOR is 
> known to be an alias for the previous
>    one, or if it is mapped to another AOR.
> 
> It seems to me that a Proxy should mark a Previous entry in 
> H-I with aor if it determines that it owns this AOR. Just as 
> Hans's current target-uri draft.
> 
> Now, for the mapped vs routed (versus reg-contact, etc.), 
> instead of marking the Previous entry, we should mark the 
> OUTGOING (i.e., New) entry instead. This would make the procedures of
> 7.2.1 & 7.2.2 of target-URI draft clearer.
> 
> Specifically, the logic would be:
> 
> When proxy receives an incoming request with H-I, it adds an 
> ;aor tag to that incoming entry if it determines that it is 
> responsible for the AOR and. 
> 
> Also, if there was no Hi-entry at all (i.e., it came from a 
> UAC), and the Proxy creates then two entries, the first one 
> in this case would also have the ;aor tag associated to it.
> 
> For the Outgoing entry, I would see the following tags:
> 
> rc	:	The entry is an explicit registered contact 
> (i.e., it was provided in a REGISTER message)
> 
> ic	:	The entry is an implicit registered contact 
> (i.e., it's exactly as a registered contact,
> 		but was not discovered using SIP Registration: 
> it could have been manually configured
> 		or done with a proprietary mechanism).
> 
> 		(TBD: we could debate if we need both rc and 
> irc, but I think we do).
> 
> mp	:	The request-URI is changed to a new URI that 
> represent another user.
> 
> rt	:	The entry is "routed", i.e., it is either a 
> no-opt like a proxy forwarding within
> 		a domain, predetermined by a maddr in the 
> Request-URI, or when proxy is NOT responsible
> 		for domain, or the address is an alias for the 
> incoming URI.
> 
> So, to give an example. 
> 
> Say Alice calls Bob. Bob is forwarded to freephone. Freephone 
> routes to Carol. 
> 
> The History-info at Carol would look like this:
> 
> Alice -> example.com
> Nothing because UAC typically doesn't send H-I (otherwise, it 
> would be as per Index 1 in next entry, but without the AOR.
> 
> example.com -> [email-masked]
> History-Info: <sip:[email-masked]>;index=1;aor
> History-Info: <sip:[email-masked]>;index=1.1;mp
> 
> example.net -> [email-masked]
> History-Info: <sip:[email-masked]>;index=1;aor           
> History-Info: <sip:[email-masked]>;index=1.1;mp;aor  
> <- aor is added
> History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor    } 
>  Two entries are
> History-Info: <sip:[email-masked]>;index=1.1.1.1;rc        } 
>  added at same time
> 
> Also, I don't think we need to define an equivalent to the 
> "reg-uri-alias" anymore.
> If Freephone was configured to go to +14085551212 instead of 
> the registered Contact (assuming +14085551212 was an Alias 
> AOR for [email-masked]), the last H-I entries would look 
> like this instead:
> 
> example.net -> [email-masked]
> History-Info: <sip:[email-masked]>;index=1;aor     
> History-Info: 
> <sip:[email-masked];user=phone>;index=1.1;mp;aor <- 
> aor is added
> History-Info: <sip:[email-masked]>;index=1.1.1;rt;aor  
> <- aor is added
> History-Info: <sip:[email-masked]>;index=1.1.1.1;rt;aor    
> }  Two entries are
> History-Info: <sip:[email-masked]>;index=1.1.1.1.1;rc        
> }  added at same time