Subject: [Sip] Connected Destination in SIP

From: Frank Derks <[email-masked]>
Date: Thu, 29 Sep 2005 12:55:31 +0200

Hi,

I went through several SIP specifications to find out how the following 
could be achieved, but thusfar I have not been able to find this is 
supposed to be done with SIP. Hopefully someone has an idea.

When an INVITE is retargeted by a SIP proxy, the actual destination 
changes. The sender of the INVITE, however, remains unaware of this. 
I.e. the original sender of the INVITE has no clue as to "who" is at
the other end. E.g. Alice calls Bob, but Bob has instructed the SIP 
proxy to forward his calls to Carl. Alice ends up being connected to 
Carl, but SIP does not communicate this. Only when Carl answers the 
phone, Alice realises that she's not talking to Bob. 

I have not seen an obvious way to inform Alice about the identity of 
the actual destination. Does anyone have ideas?

Cheers,

Frank

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 29 Sep 2005 09:46:09 -0400

> the actual destination. Does anyone have ideas?

There is the Contact header in the 200 response, which gives (in
principle, if not in practice) a direct address of the UA which
responded to the INVITE.

But you can't go beyond this, because the concept of "identity of the
actual destination" is not well-defined.  Suppose the UA which responds
to the INVITE is a registered contact for several different AORs.  In a
perfect world, it would use different users in the Contacts it
registered for each AOR, but that's about as far as it could go in
making clear its "identity".

I think some work has been done on the idea of having each agent which
forwards an INVITE adding a header explaining how and why it forwarded
the INVITE, which would then get returned in the 200, but I don't think
it has gone forward, due to the difficulty of clearly classifying the
reasons.

Compare with TCP, where about the best you can do is "the host at the
other end is 10.20.123.45".

Dale

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 29 Sep 2005 09:49:58 -0400

> it has gone forward, due to the difficulty of clearly classifying the

I'm probably wrong about that -- check the discussion of draft-elwell-
sipping-redirection-reason-02 on the Sipping mailing list.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Sep 2005 10:00:28 -0400

This subject has gotten a fair bit of discussion and remains a somewhat 
controversial one. Some of the recent drafts on it:

http://www.watersprings.org/pub/id/draft-peterson-sipping-retarget-00.txt
http://www.watersprings.org/pub/id/draft-jennings-sipping-connected-00.txt

There remains strong interest in solving this "connected party problem", 
however.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Frank Derks <[email-masked]>
Date: Thu, 29 Sep 2005 16:35:36 +0200

Hi Jonathan,

Thanks for the quick response. I will read through these drafts and see 
what 
I can do with it.

The fact that it "remains controversial" sounds like there is not a lot 
agreement on whether this should be supported by SIP or that the proposed 
solutions aren't good enough (whether technically or politically). 

What is the real problem?

Frank

Jonathan Rosenberg <[email-masked]> 
Sent by:
[email-masked]
2005-09-29 04:00 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
[email-masked]
Subject
Re: [Sip] Connected Destination in SIP
Classification

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Sep 2005 11:48:25 -0500

> What is the real problem?

The real problem is that:

1) The call could go to some agent with whom you do not have a pre- 
established relationship, making it a "general public" scope problem.

2) We lack a solution for strongly expressing identity in the general  
public.

One "solution" is to use a global PKI infrastructure. We don't have  
one of those. People have been working on it for a while.

So, at its worst, the connected-identity problem equates to the  
global PKI problem, which is in the category of "really hard".

So we're left with trying to define a restricted subset of the  
general solution. For example, IMS as envisioned by the mobile  
operator community provides a fairly constrained confederation of  
identity domains that, (even if it does so imperfectly) might allow  
for the management of keying material.

At its simplest, this might be accounted for by having a UA insert a  
"P-Preferred-Identity" header field into responses (like 200 OK) and  
requiring the P-CSCF to match its value against the set of P- 
Associated-URI header field values returned by the S-CSCF in the 200  
OK response to that UA's authenticated REGISTER request. This is  
essentially the request-identity mechanism of IMS Release 5.

But that's a narrowly applicable "P-header" solution, fine for 3GPP  
but below the expectations of an IETF solution. So we're trying to  
find a happy medium.

--
Dean