I was looking at draft-rosenberg-sip-app-components-01.txt,
and noticed a couple of places where an interesting pattern
was used:
- invite A on hold
- use returned SDP to invite B
- reinvite A using SDP from B
One example of this is in section 6.4.2 Web Enabled Message Drops:
The controller then calls the user (3) using an SDP with a single
media stream on hold initially. This is accepted (4), and the
resulting SDP is used in an INVITE to the messaging server (6).
I have a couple of questions about this potentially useful
technique:
1) Is it kosher to invite on hold? Depending on signalling
delays, this could be somewhat disconcerting to the
called party.
2) How can media formats be properly dealt with?
The SDP returned by A will be a subset of what is
initially offered. And that then limits what B may
choose from. But at the time of the initial invitation
there is no knowledge of what B supports.
Paul Kyzivat
Cisco Systems
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
