Subject: RE: [Sip] Change of display name

From: "Elwell, John" <[email-masked]>
Date: Thu, 09 Oct 2003 07:45:43 +0100

Jean-Francois,

I thought the earlier thread to which you refer was leaning towards the use
of UPDATE or re-INVITE with revised identity information. A related thread
was started by Cullen Jennings on 29th August ("Update of display name
during a call"), proposing the use of a revised display name in a From/To
header inside an AIB in an UPDATE or re-INVITE request. The thread led to
the related question of whether a revised P-Asserted-ID header could be
included in an UPDATE or re-INVITE request, but this appeared to be
inconclusive.

John ([email-masked])

> -----Original Message-----
> From: Jean-Francois Rey [mailto:[email-masked]] 
> Sent: 01 October 2003 10:53
> To: [email-masked]
> Subject: [Sip] Change of display name
> 
> 
> I'm implementing some attended transfer use cases between a telephone 
> gateway and SIP phones. I need to update the display name when the 
> transfer takes place. Unfortunately, if more than one gateway is 
> involved in the transfer, I cannot use the REFER + replaces 
> mechanism. I 
> know that this topic has already been discussed in this list 
> : Update of 
> display name during a call 
> (http://www1.ietf.org/mail-archive/working-groups/sip/current/
> msg08521.html), 
> Update and P-Asserted-ID 
> (http://www1.ietf.org/mail-archive/working-groups/sip/current/
> msg08142.html). 
> Unfortunately, I'm still a bit unsure of what is the outcome of these 
> threads. Using an identity mechanism (a short term one like 
> P-Asserted-ID or a long term one like AIB) in a UPDATE or re-INVITE 
> seems a bit underspecified to say the least. Could anyone provide 
> guidance on these topics : do we have a consensus ? Would 
> this consensus 
> go beyond telephone gateways experts and include SIP phone and 
> application vendors ? Are there any existing documents or planned 
> actions (new versions of drafts or rfcs, BCP) that would clarify this 
> topic ?
> 
> I played a little bit with SIP phones and I found out that a solution 
> works with many SIP phones : using the usual INVITE + 
> replaces mechanisms.
> 
> So instead of the UPDATE + identity solution
> 
>           Gateway	 Dialog D1	    SIP phone
> 	  |=========================|
> 	  |    (D1)UPDATE	    |
> 	  |------------------------>|
> 
> I tried this :
> 
>           Gateway	 Dialog D1	    SIP phone
> 	  |=========================|
> 	  |    (D2)INVITE	    |
> 	  |	(replaces D1)	    |
> 	  |------------------------>|
> 
> It works fine except if D1 is not confirmed.
> I understand that
> - there might be GRUU/routing problems (but nothing new compared to 
> usual REFER + replaces mechanism),
> - there are more messages being exchanged than in the UPDATE solution 
> (but the INVITE + replaces seems the BCP for attended 
> transfer in SIP).
> 
> So there are issues. OTOH this solution works with many 
> implementations, 
> it can rely on all identity solutions and IMHO it uses nicely the 
> semantic of replaces (which is needed for attended transfer 
> between SIP 
> phones anyway).
> 
> I'd like to have the community's feeling on that topic.
> 
> Thanks,
> Jean-Francois
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Oct 2003 14:31:04 -0400

I tend to think it makes sense to be able to update a bunch of SIP 
related state through an UPDATE request. This is beyond the currently 
documented scope of UPDATE, though certainly the intent was to allow 
it. Indeed, the original drafts on UPDATE described its usage to solve 
the "HERFP" problem, whereby an UPDATE was used to change credentials, 
require header values, etc., after the initial INVITE. This aspect of 
UPDATE was removed from the main spec because it was less stable, and 
we needed UPDATE for other, more pressing things. However, I have not 
had the time to follow through and revive those yanked portions of 
UPDATE. Presumably such a draft would cover the ability to change 
P-Asserted-ID and other things as well. Volunteers to revive this draft?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com