I'm still not sure what you originally objected to. Just to
be point
out that the UPDATE can come from either side, I'm copying
figure 1
from the UPDATE RFC here.
Tell me what SDP you think is safe to put in message 9.
I _think_ you're saying it should be answer 1 from message
2. How
could that help anybody? The session described by
offer1/answer1 is
long long gone.
If you repeat offer 3 from message 7, again - how could that
help
anybody?
I'll accept that you don't like the whole idea of early
dialogs and
early media. But that cat's so far out of the bag its
forgotten what
the bag smells like.
Given that this stuff is now _deployed_, what's the best
answer to my
original question?
What Paul points out causes me to champion making a much
clearer MUST
NOT put SDP in the 200-INVITE if you're using 100-rel.
And my questions about how the repeat of either of those
SDPs is
earnest, not rhetorical. I really don't see how its helping
something
work.
Can you diagram the scenario where not repeating the SDP you
want to
repeat leads to abject failure?
RjS
Caller Callee
| |
| |
|(1) INVITE with offer 1 |
|---------------------------->|
| |
| |
|(2) 180 with answer 1 |
|<----------------------------|
| |
| |
|(3) PRACK |
|---------------------------->|
| |
| |
|(4) 200 PRACK |
|<----------------------------|
| |
| |
|(5) UPDATE with offer 2 |
|---------------------------->|
| |
| |
|(6) 200 UPDATE with answer 2 |
|<----------------------------|
| |
| |
|(7) UPDATE with offer 3 |
|<----------------------------|
| |
| |
|(8) 200 UPDATE with answer 3 |
|---------------------------->|
| |
| |
|(9) 200 INVITE |
|<----------------------------|
| |
| |
|(10) ACK |
|---------------------------->|
| |
| |
| |
| |
Figure 1: UPDATE Call Flow
On Nov 21, 2007, at 11:20 PM, Dean Willis wrote:
>
> On Nov 21, 2007, at 10:57 PM, Robert Sparks wrote:
>
>> There can be several UPDATEs with their associated
200-UPDATES
>> before the 200-INVITE.
>> Remember that UPDATE is a nonINVITE transaction and
there may be a
>> _long_ time between the UPDATE and the 200-INVITE.
>>
>> Paul drew the arrow backwards for the 200-UPDATE
though - did that
>> mislead you?
>>
>
> Ah, yes, I read that Alice had sent a second
conflicting offer in
> UPDATE.
>
> However, even with this directionality, the answer in
the
> INVITE-200, if present, would have to be a copy of the
answer in
> the 183. This doesn't create any error I can see, it
just
> illustrates the UPDATE race condition that would have
existed even
> had there not been an answer in the 183. Early media,
early
> session, and UPDATE were all bad ideas (probably all
because of
> forking and PSTN interactions) IMHO, and I'm pretty
sure reliable
> provisionals are on that list too.
>
>
>>>>
>>>> Alice Bob
>>>> | INVITE offer1 |
>>>> |----------------->|
>>>> | 183 answer1 |
>>>> |<-----------------|
>>>> | PRACK |
>>>> |----------------->|
>>>> | 200 PRACK |
>>>> |<-----------------|
>>>> | UPDATE offer2 |
>>>> |<-----------------|
>>>> | 200 UP answer2 |
>>>> |<-----------------|
>>>> | 200 IN SDP? |
>>>> |<-----------------|
>>>>
>>>> Now what should be in the 200 for the
invite?
>>>>
>>>> Its better to do what is already required -
send no SDP in the
>>>> 200 for the invite.
>>>
>
> --
> Dean
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
