Inline...
Hadriel Kaplan wrote:
-----Original Message-----
From: Adam Roach [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 28, 2007 11:59 AM
Basically, I think you'll run into problems if you can't support a
scenario like this:
A 3PCC B
|(1) INVITE | |
|(no Recv-Info) | |
|<------------------| |
|(2) 200 | |
|(Recv-Info A) | |
|------------------>| |
| |(3) INVITE |
| |(Recv-Info A) |
| |------------------>|
| |(4) 200 |
| |(Send-Info A) |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK | |
|(Send-Info A) | |
|<------------------| |
|(7) Media | |
|.......................................|
| |(8) INFO |
| |<------------------|
|(9) INFO | |
|<------------------| |
Without the ability to negotiate Info Packages in messages (2) and (5),
you run into the basic inability to support this kind of thing.
I apologize, I didn't mean I didn't get the call flow - I just didn't get why
it should work that way for info-packages. But I think I understand now. I
was thinking info-package requires the UA to understand the package, and a 3PCC
is a B2BUA, hence a UA - and so would need to know them a priori and thus be
able to indicate what packages it supports in Invite-1. Somewhat akin to
Supported/Require usage. But clearly that no workie. (duh)
But, I do think there are multiple options for dealing with this:
Option 1) support the basic model of offer/answer a la SDP.
Don't get stuck on the analogy to SDP O/A. There are relationships but
they are not the same thing. The specification of O/A in 3264 doesn't
even map it to SIP messages.
Its the basic notion of being able to make an offer in the invite or
solicit an offer in the invite that provides both the power and the pain.
Option 2) since we'll support re-negotiation in re-Invite anyway, force 3PCC or
any such blind Invite initiator to offer all in the invite, and re-negotiate in
a re-Invite when it knows more.
For 3pcc, where the existing mechanism must be handled for SDP, a
mechanism that requires additional messages would at least be annoying
and inconvenient if it can be accomplished with the existing messages.
Option 3) do what you basically said later in your email: make
send-info/recv-info purely an announcement not a negotiation. It can be
changed at will, sent in any message, etc. Someone actually raised this model
before (maybe Dean?).
The reason I'm even suggesting Option 2 is it (a) seems simpler to me from a KISS/high-level-logic
perspective (and thus hopefully easier for implementers and fewer "bugs"), (b) I've seen
numerous issues with SDP delayed offers in the field, and (c) I'm thinking the burden of handling
3PCC cases should be placed on 3PCC controllers, not by complicating the logic for all others. But
I'm not sure how "offering all" would really work. I mean you could define some
token/syntax that means it, but I would think that would be dangerous. Option 3 seems to have
these same properties to me as well and more, without this last problem.
But Option 3 I thought had some issue but I can't remember what it is now.
(probably related to DTMF use?)
It seems to me that there is a need to know what *will* be used as well
as what *could* be used. This is especially the case when there are
multiple possible mechanisms to accomplish the same thing and one is
being chosen. That is the situation with DTMF.
Paul
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
