|
List Info Thread: Re: RE: 3PCC and draft-kaplan-sip-info-events-00.txt
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: RE: 3PCC and draft-kaplan-sip-info-events-00.txt |
|
List Info Thread: Re: RE: 3PCC and draft-kaplan-sip-info-events-00.txt
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
nostrum.com]
>> 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