Subject: [cuss] Redirection requirements

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 19 Sep 2011 14:14:32 +0200

The current requirements specify that it is possible that were A calls B and B forwards to C, B can send UUI data to C.

How do we expect this to work?

>From B to C we have suggested that we might tag the data on to the History-Info header or something like, so that the UUI data is associated with the URI of B.

Given that an INVITE to C may be initiated from a proxy server, that received a 3xx response from B, what does the 3xx response look like?

And if the 3xx response goes all the way back to A, is B also allowed to include a separate UUI that is intended for A rather than C? (And therefore encoded distinctly from that intended for C).

>From my perspective (the ISDN interworking) I don't need to know how to do this, but I do need to know what to preclude because it will not work in the ISDN interworking case.

Regards

Keith

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 19 Sep 2011 10:29:35 -0400

> From: [email-masked] [[email-masked]] On Behalf Of DRAGE, Keith (Keith) [[email-masked]]
> 

If the UUI is encoded in a header, one possibility is to include a "header" in the Contact header of a 3xx response:

SIP/2.0 302 Moved Temporarily
...
Contact:  sip:[email-masked]?UUI=AAAAAAAAAAAAAAAAAAAAAAAAAAAA

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 19 Sep 2011 17:20:02 +0200

Yes that is what I was assuming, but the functionality has to be more complicated that that.

We have an underlying requirement that the source of the UUI is identified (in the absence of such identification it has come from A).

Thus if A forwards to B1 and B1 forwards to B2 and B2 forwards to B3, and B3 forwards to C, I potentially end up with UUI from A, B1, B2, B3 being sent to C. The suggestion has been made that this gets tagged to the History-Info header field entries in some way. So who is responsible for performing the reencoding of the History-Info header field - the SIP proxy server performing the rerouteing, who is modifying it anyway because they have replaced the URI and therefore update the History-Info to suite, or the redirecting UA, who could effectively screw up the entire history of the call by replacing it.

Keith

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:[email-masked]]
> Sent: 19 September 2011 15:30
> To: DRAGE, Keith (Keith); [email-masked]
> Subject: RE: Redirection requirements
> 
> > From: [email-masked] [[email-masked]] On Behalf Of DRAGE,
> Keith (Keith) [[email-masked]]
> >
> > The current requirements specify that it is possible that were A calls B
> and B forwards to C, B can send UUI data to C.
> >
> If the UUI is encoded in a header, one possibility is to include a
> "header" in the Contact header of a 3xx response:
>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 19 Sep 2011 19:47:25 -0500

Keith,

I am working on text on the usage of History-Info in this case, but I expect it will be something similar to this:

1. Requests that contain UUI or potentially contain UUI should include Supported: histinfo
2. Any entity, UA or proxy that forwards or recurses on a redirection includes the appropriate History-Info entry.  Since the UUI will be escaped into the Contact URI, the UUI is included in History-Info without any special processing.
3. A UA receiving a request with UUI checks to see if there are any History-Info fields.  If none, the UUI has come from the originator.  If the UUI matches a UUI in a History-Info, the UUI has come from entity in the previous History-Info field.

Of course, it is possible for History-Info entries to be modified or removed, and of course a B2BUA can do anything at all.  

- Alan -

On Sep 19, 2011, at 10:20 AM, DRAGE, Keith (Keith) wrote:

> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss