> -----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. 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. 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?) -hadriel _______________________________________________ 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
