I think we all agree that it would be nice if there was an identifier
that worked through b2bua, which we could use to identify dialogs.
However, I think the problem is far more complicated than this document
talks about. The focus is on making it work through SBC type of boxes
which aren't doing a lot of fancy call control, but are rewriting
call-id and doing security things. There, I think the problem is easy.
However, there are lots of cases where more complicated dialog
manipulation mucks this up in a really horrible way. In particular,
enterprise features like transfer, park/pickup, and so on, are often
implemented by means of re-INVITEs on dialogs all anchored in the
IP-PBX. For example, consider the following transfer implementation:
A calls B. A calls C. Both calls are routed through an IP-PBX, which
acts as a b2bua, and so we end up with something which looks like this:
Please view in a fixed-width font such as Courier.
+------------+ S1
S1 | | ------------ B
--------| |
A S2 | server |
--------| | S2
| | ------------- C
| |
+------------+
Where S1 and S2 are the two session IDs. So far, so good. Now, A
transfers the call to B. A sends a REFER on dialog S1. Like it or not,
due to frequent REFER/transfer interop issues, this is sometimes
implemented as a re-INVITE from the server, connecting B and C's media
streams together, and then disconnecting A, so that you end up with:
Please view in a fixed-width font such
as Courier.
+------------+ S1
| | ------------ B
| |
| server |
| | S2
| | ------------- C
| |
+------------+
Now B and C are talking to each other. What is the session ID for this
dialog? B and C were both originally the UAS on different dialogs with
different session IDs!
The problem happens more generally for any 3pcc operation, and the
meta-issue is how to come up with a clear notion of who 'owns' the
sessionID creation and destruction in cases where calls are transferred,
moved, conferenced, parked and picked up all over the place.
As such, a true comprehensive solution to this problem is much more
complicated than just 'tell the SBCs to stop mucking with this header'.
It would need to account for a wider range of 3pcc and other dialog
manipulations which occur in the wild. Or, we could try to scope this in
a more limited way, focusing on the basic A-calls-B case and solve just
the SBC problem.
Which is it?
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
jdro...@cisco.com
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implement...@cs.columbia.edu for questions on current sip
Use sipp...@ietf.org for new developments on the application of sip
