[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Deficiencies of History-Info
Yes.
Isn't the more fundamental design problem that causes this that the
Reason is captured on the hi-targeted-to-uri that has been retargeted
instead of being associated with the new target signifying how it came
into being.
Not sure if adding additional indexes makes things clearer.
BTW: If UA4 is from 302, then why does UA3 line on F8 contain reason
480? I would expect it to have no attached reason.
/Hans Erik
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Dale.Worley at comcast.net
Sent: Wednesday, March 19, 2008 10:33 PM
To: sip at ietf.org
Subject: [Sip] Deficiencies of History-Info
I've looking at History-Info (RFC 4244) and I think that as it is
currently defined, it has a deficiency in regard to capturing the
forking structure of a request.
Let us look at an example that parallels the first example of RFC 4244
Appendix A (with non-significant messages omitted):
UA1 Proxy1 UA2 UA3 UA4
| | | | |
|-INVITE F1->| | | |
| | | | |
| |--INVITE F2------>| | |
| | | | |
| |<-302 F4----------| | |
| | | | |
| |-------INVITE F5 --------->| |
| | | | |
| |<-------486 F6 ------------| |
| | | | |
| |------INVITE F8 ------------------->|
| | | | |
| |<-200 F10 --------------------------|
| | | | |
| |-- ACK F11------------------------->|
|<--200 F12--| | | |
| | | | |
|--ACK F13-->| | | |
| | | | |
Assuming that each agent applies History-Info, the History-Info headers
will look like this:
F1 INVITE UA1 ->Proxy1
History-Info: <sip:UA2 at example.com>; index=1
F2 INVITE Proxy1 ->UA2
History-Info: <sip:UA2 at example.com>; index=1,
<sip:UA2 at ims.example.com>; index=1.1
F5 INVITE Proxy1 -> UA3
History-Info: <sip:UA2 at example.com>; index=1,
<sip:UA2 at ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1.1,
<sip:UA3 at example.com>;index=1.2
F8 INVITE Proxy1 -> UA4
History-Info: <sip:UA2 at example.com>; index=1,
<sip:UA2 at ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UA3 at example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UA4 at example.com>;index=1.3
These History-Info headers correctly give the forking structure of the
INVITE.
The difficulty is that History-Info does not tell us why UA4 was chosen
as a target -- It could have been generated by Proxy1 as a target for
UA2, or it could have been a Contact in the 302 response F4. As one
thinks about call routing, UA4 could be a consequence of
UA2 at example.com, or it could have been a consequence of
UA2 at ims.example.com which was itself a consequence of UA2 at example.com.
It seems to me that we need a further indicator when a target is added
to the target set by a received 3xx response. Let me propose that the
indicator be an additional field parameter "redir" whose value is the
"index" value of the URI whose 3xx response added the target.
In the above example, if both UA3 and UA4 were from the 302 response,
F8 would become:
F8 INVITE Proxy1 -> UA4
History-Info: <sip:UA2 at example.com>; index=1,
<sip:UA2 at ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1;redir=1,
<sip:UA3 at example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2;redir=1,
<sip:UA4 at example.com>;index=1.3
Dale
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip