I agree with Paul, but I think perhaps Kevin is saying something a little different, and interesting.

I think he is asking if the display name in a Contact header field could be presented to the caller to let them know who they have actually reached.

For example, Alice calls Bob, but Bob's phone is forwarded to Carol. Alice's UA instead of just displaying "Connected" when Carol answers could display "Connected to Carol" if Carol provides a Contact header field Contact: Carol <sip:[EMAIL PROTECTED]>. Since this information is even provided in a 18x provisional, Alice's UA could even display "Ringing Carol".

Of course, this has privacy considerations, but the called party has control if a display name is presented in a Contact header field.

Thanks,
Alan Johnston
WorldCom
sip:[EMAIL PROTECTED]

At 12:46 PM 12/16/2002 -0500, Paul Kyzivat wrote:
Kevin,

It can't be used in the request line itself, because that only permits a uri, not a name-address. So I suppose you mean in the To header.

Normally redirection is an alternative to proxying. If the request was proxied, the To header would not be changed by the proxy - only the request uri would be changed. So it is natural for a UAC that handles a 3xx response to do the same - leave the To alone and replace the request uri.

But the UAC has discretion here - it can presumably do what it wants. But in general it would probably be best for it to follow the obvious path. Redirection doesn't alter who the intended recipient was, and it can be valuable for the actual recipient to know that.

Paul

Kevin Summers wrote:
Seems like a simple question, but I've never seen this discussed and
it's not altogether clear to me in the various RFCs/drafts ....
When a request is redirected to a location specified by a Contact header
field value in a 3XX response and the Contact header field value
contains a URI with display-name that differs from that of the original
request's request-URI, should the display-name of the Contact be used in
the new request?
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


Reply via email to