I have been developing a proposal for a SIP "References" header to
document within messages their relationship to other dialogs. The
current proposal is at
http://tools.ietf.org/html/draft-worley-references-03.
sipXecs currently uses References for:
- tagging the SUBSCRIBE that searches for the target of a call pickup or
call join operation as related to the INVITE being processed
- tagging the new legs of a transfer operation as related to the
original leg
For example, if the pickup redirector was processing an INVITE like
this:
INVITE sip:*[email protected] SIP/2.0
Via: SIP/2.0/UDP example.com:5061;branch=z9hG4bK74HH
From: Bill <sip:[email protected]>;tag=8675310
To: <sip:*[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
then the generated SUBSCRIBE would have a References header mentioning
the call-id of the INVITE:
SUBSCRIBE sip:[email protected] SIP/2.0
> References: [email protected];rel=inquiry
Via: SIP/2.0/UDP example.com:5061;branch=z9hG4bK74bf
From: <sip:example.com>;tag=8675309
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 SUBSCRIBE
Event: dialog
Expires: 0
Accept: application/dialog-info+xml
Our current plan (XX-5858) is to upgrade sipXbridge to generate the
References header in requests to document the relationships between
dialogs. Because sipXbridge carries out so many functions, there are a
number of different situations where we want to add References headers,
each of which has a different "rel" value. The details are in the
Description of the issue:
For improved diagnostics, it helps if dialog-forming requests carry
"References" headers showing which other dialogs they are associated
with. (Details in
http://tools.ietf.org/html/draft-worley-references-03.txt.) In the case
of sipXbridge, when an INVITE is generated as the "outgoing half" of a
dialog, it should carry a header "References: [call-id of incoming
INVITE];rel=chain".
An example is given in section 3.1 of the Internet-Draft:
Alice --- INVITE F1 ---> B2BUA --- INVITE F2 ---> Bob
F1 INVITE Alice -> B2BUA, en route to Bob
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS
client.atlanta.example.com:5061;branch=z9hG4bKnash3c6h
Max-Forwards: 70
From: Alice <sips:[email protected]>;tag=867AB09
To: Bob <sips:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sips:[email protected]>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
F2 INVITE B2BUA -> Bob
INVITE sips:[email protected] SIP/2.0
References: [email protected];rel=chain
Via: SIP/2.0/TCP b2bua.example.com;branch=z9hG4bKnqhsocn
Max-Forwards: 70
From: Alice <sips:[email protected]>;tag=7923480
To: Bob <sips:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sips:b2bua.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
When the dialog on one side of the connection is replaced (e.g., because
sipXbridge is shortstopping a REFER), there are a number of alternatives
for an acceptable References header:
- carry the call-id of the other side of the connection, with
"rel=chain"
- carry the call-id of the dialog that carried the REFER, with
"rel=refer"
- carry the call-id of the previous dialog on its side, with
"rel=sequel"
In practice, since only the symmetric-transitive closure of the
"References relationship" is significant, all of these choices have the
same effect.
Comments?
Dale
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
