Subject: [Sip] Can a UA initiate a late offer (in UPDATE instead of INVITE)

From: Kapil Nayar <[email-masked]>
Date: Tue, 6 Mar 2007 20:25:26 +0000 (GMT)

Consider UA-1 initiating an INVITE without SDP offer
(with 100Rel in the supported header). UA-1 expects
the remote end UA-2 to support 100Rel but also at the
same time doesn't want to offend endpoints which donot
support the same. Now, if UA-2 did not support 100Rel
and sends 180-Ringing without offer/ RSeq header. 

Can UA-1 at this point decide to initiate an offer in
an UPDATE - I didn't find any text in RFC 3261/ 3311
which specifically restricts this behavior? In
essence, can an UPDATE be sent with SDP-offer if the
initial INVITE didnot contain an offer, but at the
same time the callee didnot send an offer in either
reliable provisional response or UPDATE or PRACK? This
seemingly is some sort of "late offer initiation".

Although it seems the RFC doesnot specifically
restrict this behavior, it should be disallowed to
prevent any collision between the offer in UPDATE from
UA-1 and 200-OK/ UPDATE from UA-2.

thanks,

Kapil Nayar

___________________________________________________________ 
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Tue, 6 Mar 2007 18:27:22 -0500

Table 1 in draft-ietf-sipping-sip-offeranswer-00.txt mentions that
UPDATE can not be used to send initial offer.

>-----Original Message-----
>From: Kapil Nayar [mailto:[email-masked]] 
>Sent: Tuesday, March 06, 2007 8:25 PM
>To: [email-masked]
>Subject: [Sip] Can a UA initiate a late offer (in UPDATE 
>instead of INVITE)
>
>Consider UA-1 initiating an INVITE without SDP offer (with 
>100Rel in the supported header). UA-1 expects the remote end 
>UA-2 to support 100Rel but also at the same time doesn't want 
>to offend endpoints which donot support the same. Now, if UA-2 
>did not support 100Rel and sends 180-Ringing without offer/ 
>RSeq header. 
>
>Can UA-1 at this point decide to initiate an offer in an 
>UPDATE - I didn't find any text in RFC 3261/ 3311 which 
>specifically restricts this behavior? In essence, can an 
>UPDATE be sent with SDP-offer if the initial INVITE didnot 
>contain an offer, but at the same time the callee didnot send 
>an offer in either reliable provisional response or UPDATE or 
>PRACK? This seemingly is some sort of "late offer initiation".
>
>Although it seems the RFC doesnot specifically restrict this 
>behavior, it should be disallowed to prevent any collision 
>between the offer in UPDATE from
>New Yahoo! Mail is the ultimate force in competitive emailing. 
>Find out more at the Yahoo! Mail Championships. Plus: play 
>games and win prizes. 
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2007 16:11:18 -0500

> which specifically restricts this behavior? In

No.

This would totally screw things up by changing who is expected to make 
the offer. UA-2 has already understood that it is supposed to do so, and 
may well have on in transit.

The manner in which the offer/answer protocol can be mapped onto sip 
messages when taking all of the relevant RFCs into account is very 
poorly and incompletely specified. There is work underway to clarify 
this. See draft-ietf-sipping-sip-offeranswer-00.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 7 Mar 2007 09:43:53 +0100

Hi,

I think this is an interesting question, and should be added to the
offer-answer draft.

The question is valid even if the 18x is sent reliably without SDP (yes,
I know it is currently written that the first reliable response MUST
contain an SDP offer, but that is a restriction we are also looking at
in the offer-answer draft).

One problem is that you can end up with a race condition, if UA-1 sends
an UPDATE/offer at the same time as UA-2 sends an offer in a reliable
response (18x or 200). Since it is not possible to reject a reply it
could become a little messy...

So, my initial opinion would be: no, what you propose shall not be
allowed, i.e. if the INVITE does not contain an offer the first offer
MUST be sent by the remote party before the sender of the INVITE can
send his first offer.

Regards,

Christer

> Sent: 6. maaliskuuta 2007 22:25
> To: [email-masked]
> to offend endpoints which donot support the same. Now, if 
> UA-2 did not support 100Rel and sends 180-Ringing without 
> offer/ RSeq header. 
> 
> New Yahoo! Mail is the ultimate force in competitive 
> emailing. Find out more at the Yahoo! Mail Championships. 
> Plus: play games and win prizes.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2007 12:15:18 -0500

> I think this is an interesting question, and should be added to the

It is covered. (It says you can't do it.)

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 7 Mar 2007 21:49:03 +0100

Hi, 

>It is covered. (It says you can't do it.)

Ok. Good.

Note, however, that it should be perfectly ok to send an SDP offer in
the INVITE without any m= lines (you do need to include a c= line,
though).

That way you can add the media parts later.

Whether terminals will support it is another issue....

Regards,

Christer

> 
> 	Paul
> 
> > The question is valid even if the 18x is sent reliably without SDP 
> > (yes, I know it is currently written that the first 
> reliable response 
> > MUST contain an SDP offer, but that is a restriction we are also 
> > looking at in the offer-answer draft).
> > 
> > One problem is that you can end up with a race condition, if UA-1 
> > sends an UPDATE/offer at the same time as UA-2 sends an offer in a 
> > reliable response (18x or 200). Since it is not possible to 
> reject a 
> > reply it could become a little messy...
> > 
> instead of 
> >> INVITE)
> 100Rel in 
> >> the supported header). UA-1 expects the remote end
> >> UA-2 to support 100Rel but also at the same time doesn't want to 
> >> offend endpoints which donot support the same. Now, if
> offer/ RSeq 
> >> header.
> UPDATE - I 
> >> didn't find any text in RFC 3261/ 3311 which specifically 
> restricts 
> >> this behavior? In essence, can an UPDATE be sent with SDP-offer if 
> >> the initial INVITE didnot contain an offer, but at the 
> same time the 
> >> callee didnot send an offer in either reliable provisional 
> response 
> >> or UPDATE or PRACK? This seemingly is some sort of "late offer 
> >> initiation".
> >>
> >> behavior, it should be disallowed to prevent any collision between 
> >> the offer in UPDATE from
> emailing. Find 
> >> out more at the Yahoo! Mail Championships.
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2007 16:13:41 -0500

Christer Holmberg (JO/LMF) wrote:
> the INVITE without any m= lines

Yes it should.

>(you do need to include a c= line, though).

We disagree on that. Dale and I both interpret the existing spec as 
saying you only need c= if you have m=.

> Whether terminals will support it is another issue....

Yes, that is likely to be a problem.

If I send an invite that offers media (say MSRP) and it forks to 
multiple UAs (say one that supports MSRP and one that supports voice) 
then I want the one that supports voice to answer and the one that 
supports only MSRP to reject the invite. The rejection is because it has 
no matching media.

If that is agreed as desired behavior, then what should those two 
devices do when receiving an offer with no media? It would seem that 
either they will both ring, or both reject. What happens if a ringing 
device is answered? Its not a very useful call with no media.

This is potentially useful, but only if there is some understanding of 
what is expected and what should happen next.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 8 Mar 2007 06:24:19 +0100

Hi, 

>We disagree on that. Dale and I both interpret the existing 
>spec as saying you only need c= if you have m=.

Actually, after double checking the SDP spec I do agree with you.

>If I send an invite that offers media (say MSRP) and it forks 
>to multiple UAs (say one that supports MSRP and one that 
>supports voice) then I want the one that supports voice to 
>answer and the one that supports only MSRP to reject the 
>invite. The rejection is because it has no matching media.
> 
>If that is agreed as desired behavior, then what should those 
>two devices do when receiving an offer with no media? It 
>would seem that either they will both ring, or both reject. 
>What happens if a ringing device is answered? Its not a very 
>useful call with no media.

I guess this is related to the issue we discussed a while ago, whether
there are use-cases for no-media SIP sessions, OR use-cases where the
media is added later.

Regards,

Christer

---

From: Kapil Nayar <[email-masked]>
Date: Thu, 8 Mar 2007 15:19:00 +0000 (GMT)

Hi

Thanks for pointing to the new draft....its an
excellent piece and clarifies a lot of confusion. A
few questions though:-

1. Is there a specific reason for disallowing Pattern4
in Table1 for changing media in an early dialog..may
be I am missing something here. Anticipate an incoming
Invite (call) replied with multiple provisional
responses (an IVR-183 and then a server queue-182).
UAS may decide to have media with different
characteristics/ source for these instances within the
call. Only allowing UPDATE for changing early dialog
media seems to be more restrictive and may need more
message exchanges.

2. Just to clarify, in Figure1 "After F6 UAC and UAS
can send a new offer in an UPDATE request", I guess
the authors meant F7.

3. In the description for Figure1 it is indicated that
F12 (final response) should not contain an SDP, and if
it does and is different than F6, the UAC should
discard it. (Similar description is present in
Figure2.)

a).Does this mean that a UAS cannot change the early
media to a final media in final response?
b).If F12 carries SDP, it should be designated as a
new offer-SDP, right? If UAC discards the offer-SDP in
F12, is it still obligated to send an answer-SDP in
ACK?
c).If UAC accepts the offer-SDP in F12, can the
answer-SDP in ACK be different than the one originally
offered in F1? What is the behavior expected at the
UAS upon receiving this different media?

I don't know if it is too early to ask, but whats the
estimated time-frame for this draft to be moving to an
RFC?

thanks,
Kapil Nayar

		
___________________________________________________________ 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 13:56:37 -0500

Kapil Nayar wrote:
> be I am missing something here.

Its been a long time, and I don't recall all the reasoning that went 
into this. This was partly a matter of inferring original intent in all 
the pertinent RFCs, and extrapolating where things are unclear. We 
concluded that this was the only self consistent interpretation that 
works in all cases. (The assumption being that an interpretation that 
didn't work must not be the right one.)

If you were to allow a second o/a exchange via reliable 1xx, then it 
would have the potential for a race with a concurrent UPDATE in the 
other direction. And that would result in a need to send an error 
response. But PRACK isn't prepared for carrying an error response. 
Forcing subsequent o/a to use UPDATE avoids this.

> Anticipate an incoming

It may take an extra message, but it is cleaner. It is not more 
restrictive in what can be done.

> can send a new offer in an UPDATE request", I guess

Debatable. I think the UAS can send an UPDATE after sending F6, without 
waiting to receive F7. (With the understanding that the UPDATE could 
fail if received before F6.)

The UAC should probably wait until it sends F7.

> media to a final media in final response?

It means that each offer has been answered, and that once an answer has 
been sent, it can't be changed without another offer/answer cycle. And 
that another offer/answer cycle may not be initiated in the 2xx if one 
has already been completed.

This last is part of a principle that was discovered during the 
evolution of this work: At most one offer and one answer per transaction.

At the time of F12, if the UAS wants to change the SDP, it can send an 
UPDATE before sending the 2xx for the INVITE. Or it can send the 2xx and 
send an UPDATE or reINVITE after the ACK.

> F12, is it still obligated to send an answer-SDP in

No. This is all as specified in 3261. Having sent an unreliable 
provisional with an answer in F2, if there is any SDP in the 2xx it must 
be identical to what was sent in F2. It is *not* another offer, and so 
it there must not be an answer to it in F13.

> UAS upon receiving this different media?

See above.

> estimated time-frame for this draft to be moving to an

Pretty soon. I think there is hope for WGLC in April.

	Paul

---

From: Kapil Nayar <[email-masked]>
Date: Fri, 9 Mar 2007 15:08:23 +0000 (GMT)

Thanks Paul for the clarifications.
Replies inline.

Kapil

> Forcing subsequent o/a to use UPDATE avoids this.

KN>> Perfect. So UPDATE (with SDP) support is sort of
mandatory for implementations which want to enable
changing early-media.

> The UAC should probably wait until it sends F7.
KN>> I would agree with mandating UAC to wait until it
sends F7.

> > UAS upon receiving this different media?
KN>> Actually, there is some confusion here. In
Figure1 and Figure2 call flows there is a successful
completion of the o/a through reliable 1xx. As per RFC
3261..."Once the UAS has sent or received an answer to
the initial offer, it MUST NOT generate subsequent
offers in any responses to the initial INVITE." 
However, if you read the description in line with the
figures it seems we have relaxed the MUST NOT to
SHOULD NOT.
Figure1 - UAS should not include an SDP in the
responses F9 and F12. Figure2 - UAS should not include
an SDP in the responses F6 and F9.
And, it sort of opens the discussion to possible
scenarios where another o/a can be initiated. Is this
intentional?

> and if 
> >> We disagree on that. Dale and I both interpret
> the
> >> existing spec as 
> >> If I send an invite that offers media (say MSRP)
> and
> >> it forks to 
> >> devices do when receiving an offer with no media?
> It
> >> would seem that 
> >> device is answered? Its not a very useful call
> with
> >> no media.
> >>
> 
> > Now you can scan emails quickly with a reading
> pane. Get the new Yahoo! Mail.
> http://uk.docs.yahoo.com/nowyoucan.html
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2007 11:12:31 -0500

*** OFFER/ANSWER FANS AND GURUS: PLEASE SEE BELOW AND COMMENT ***

(References are to figures in draft-ietf-sipping-sip-offeranswer-00.)

Comments inline.

	Paul

> mandatory for implementations which want to enable

Yeah. It would be quite unwise to support 100rel and not UPDATE.

> KN>> I would agree with mandating UAC to wait until it

I don't feel too strongly about this. I think it would probably be wise 
to wait until after F7, but if somebody wants to jump the gun and is 
prepared for the potential error if F7 was lost then I guess that is 
their business.

> an SDP in the responses F6 and F9.

It has been a long time, and I no longer remember the rationale that led 
to the SHOULD here. Note that in these figures the SDP in the 2xx is not 
to be considered an offer. It is just a piece of redundant data.

Personally I would be happy to say that the UAS MUST NOT include SDP in 
the 2xx in these examples. But I would also like to say (this is a best 
practice) that the UAC SHOULD/MUST ignore any SDP that arrives in the 
2xx in these cases. This happens a lot in the wild, so one ought not 
break in these cases.

But I would like to hear from Takuya (who is the primary author) and 
others on this.

> scenarios where another o/a can be initiated. Is this

Definitely not.

	Paul

---

From: "Takuya Sawada" <[email-masked]>
Date: Tue, 13 Mar 2007 01:38:14 +0900

Hi,

I just catched up the discussion...

Comments inline with [TS].

>>> If you were to allow a second o/a exchange via
>>> reliable 1xx, then it would have the potential for a race with a
>>> concurrent UPDATE in the other direction. And that would result in a
>>> need to
>>> send an error response. But PRACK isn't prepared for carrying an
>>> error response. Forcing subsequent o/a to use UPDATE avoids this.
>>
>>> Debatable. I think the UAS can send an UPDATE after
>>> sending F6, without waiting to receive F7. (With the understanding that
>>> the UPDATE could fail if received before F6.)
>>>
> I don't feel too strongly about this. I think it would probably be wise to
> wait until after F7, but if somebody wants to jump the gun and is prepared
> for the potential error if F7 was lost then I guess that is their
> business.
>
[TS]
I did not care so much on F6 or F7.
Now I agree with that waiting unil F7 is better and safe.
Probably we can modify the figure in a later version.

>>> It means that each offer has been answered, and that
>>> once an answer has been sent, it can't be changed without another
>>> offer/answer cycle. And that another offer/answer cycle may not be
>>> initiated
>>> in the 2xx if one has already been completed.
>>>
>>> This last is part of a principle that was discovered
>>> during the evolution of this work: At most one offer and one
>>> answer per transaction.
>>>
>>> At the time of F12, if the UAS wants to change the
>>> SDP, it can send an UPDATE before sending the 2xx for the INVITE. Or it
>>> can send the 2xx and send an UPDATE or reINVITE after the ACK.
>>>
>>> No. This is all as specified in 3261. Having sent an
>>> unreliable provisional with an answer in F2, if there is any
>>> SDP in the 2xx it must be identical to what was sent in F2. It is *not*
>>> another offer, and so it there must not be an answer to it in F13.
>>>
>> offers in any responses to the initial INVITE." However, if you read the
>> description in line with the
> practice) that the UAC SHOULD/MUST ignore any SDP that arrives in the 2xx
> in these cases. This happens a lot in the wild, so one ought not break in
> these cases.
>
[TS]
RFC 3261 says "UAS MUST NOT generate offer", not "UAS MUST NOT include
SDP". I guess some may interpret this as follows;

  UAS can include the same SDP both 1xx and 2xx.
  It does not care whether 1xx is reliable or not.
  If 1xx is reliable, SDP in 1xx is the answer and if not, SDP in 2xx is the 
answer.
  Some SDPs may be neither an offer nor an answer, just a hint or nothing.

I would be also happy to say "UAS MUST NOT" but I could not conclude to
say that. Clearly some implementation would violate "MUST NOT" rule.
That is why I put the following description in the draft.

       UAS should not include an SDP in the responses F9 and F12. However,
       UAC should prepare to receive an SDP in F9 and/or F12, and just
       ignore them for the case that the peer does not conform to the
       recommended implementation.

Regards,
Takuya

---

From: Kapil Nayar <[email-masked]>
Date: Wed, 14 Mar 2007 02:24:42 +0000 (GMT)

Hi Takuya

Thanks for the reply.
I would agree with you - since RFC 3261 does not
clearly restrict the "SDP" (but only offer) in 1xx and
200OK AFTER the completion of the first o/a exchange.
What do you think should be the behavior of the UAC if
the UAS sends an SDP-offer (a new session ID - new
media) in 100Rel/ 200OK in the above case? Would
ignoring suffice or you would like to recommend UAC to
cancel the call since UAS violated RFC 3261.

Also, you might want to take note of the corrections
indicated inline KN>>.

Thanks,
Kapil

--- Takuya Sawada <[email-masked]> wrote:

> >>>> 2. Just to clarify, in Figure1 "After F6 UAC
> and
> >>> UAS
> >>>> 3. In the description for Figure1 it is
> indicated
> >>> that
> >>>> b).If F12 carries SDP, it should be designated
> as
> >>> a
> >>>> F12, is it still obligated to send an
> answer-SDP
> >>> in
> >>>> ACK?
KN>>
This is a bit confusing on the first read. Actually,
it seems you are trying to refer to the generic cases
in table1 in the description for Figure1(2)- with
reference to the Figures 1(2), SDP in F9(F6) and
F12(F9) will always be ignored. Isn't it? The case
w.r.t. the Figure is always non-conformant. 

Further, the conformant case is when the o/a exchange
has not already taken place in the transaction. 

You may want to disassociate (correct) these text
description.

> > Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2007 09:47:22 -0400

Kapil Nayar wrote:
> media) in 100Rel/ 200OK in the above case?

I don't understand exactly what case you are describing.

Do you mean:

   UAC                UAS
    | INVITE w/Offer1  |
    |----------------->|
    | 1xxRel w/Answer1 |
    |<-----------------|
    |     PRACK        |
    |----------------->|
    | 1xxRel w/Offer2  |
    |<-----------------|
    |     ??????       |
    |----------------->|

If so, I can see little to do other than send some error response to the 
PRACK. I think ignoring in that case would be a mistake. Its not nice to 
reject a PRACK, but it seems the only option.

	Paul

> Would

---

From: Kapil Nayar <[email-masked]>
Date: Thu, 15 Mar 2007 13:46:46 +0000 (GMT)

Hi Paul

Yes, I am refering to similar cases - the offer2 in
subsequent 100Rel/ 200OK after the first o/a exchange.

You are indicating that RFC3261 still holds good and
UAC should reject the 2nd100Rel/ 200OK. Note, that
offer2 is invalid (protocol violation) and UAC may
have to cancel(reject) the transaction(dialog) in this
case since there is no clear way of indicating
protocol violation rejection in PRACK/ ACK.

However, going by Takuya's proposal in the draft -the
UAC would assume the o/a completed based upon
offer1/answer1 and ignore the SDP in 2nd100Rel/
200OK(irrespective of if it is answer1 or offer2). The
onus now is on the UAS(violating UAS) to interpret no
answer2 in PRACK/ ACK. 
Ignoring is perfect for SDP-answer1 in the 2nd100Rel/
200OK. In case of SDP-offer2 it seems your suggestion
is correct, unless Takuya has some clarification.

thanks,
Kapil

--- Paul Kyzivat <[email-masked]> wrote:

> >>> *** OFFER/ANSWER FANS AND GURUS: PLEASE SEE
> BELOW
> >> AND COMMENT ***
> >>>>> send an error response. But PRACK isn't
> prepared
> >> for carrying an
> >>>>> sending F6, without waiting to receive F7.
> (With
> >> the understanding that
> >>> wait until after F7, but if somebody wants to
> jump
> >> the gun and is prepared
> >> Now I agree with that waiting unil F7 is better
> and
> >> safe.
> >>>>>> F12 (final response) should not contain an
> SDP,
> >>>>> and if
> >>>>>> a).Does this mean that a UAS cannot change
> the
> >>>>> early
> >>>>> It means that each offer has been answered,
> and
> >> that
> >>>>> can send the 2xx and send an UPDATE or
> reINVITE
> >> after the ACK.
> >>>>> unreliable provisional with an answer in F2,
> if
> >> there is any
> >>>>> SDP in the 2xx it must be identical to what
> was
> >> sent in F2. It is *not*
> >>>>>> offered in F1? What is the behavior expected
> at
> >>>>> the
> >>> It has been a long time, and I no longer
> remember
> >> the rationale that led
> >>> to the SHOULD here. Note that in these figures
> the
> >> SDP in the 2xx is not
> >>> practice) that the UAC SHOULD/MUST ignore any
> SDP
> >> that arrives in the 2xx
> >>> in these cases. This happens a lot in the wild,
> so
> >> one ought not break in
> >>> these cases.
> >>>
> >>   If 1xx is reliable, SDP in 1xx is the answer
> and
> >> if not, SDP in 2xx is the 
> >> answer.
> >>   Some SDPs may be neither an offer nor an
> answer,
> >> just a hint or nothing.
> >>
> >> say that. Clearly some implementation would
> violate
> >> "MUST NOT" rule.
> >> That is why I put the following description in
> the
> >> draft.
> >>
> >>        ignore them for the case that the peer
> does
> >> not conform to the
> >>>> scenarios where another o/a can be initiated.
> Is
> >> this
> >>>> intentional?
> >>> Definitely not.
> >>>
> >>> Paul
> >>>
> >>> Use [email-masked] for
> questions
> >> on current sip
> 
> > The all-new Yahoo! Mail goes wherever you go -
> free your email address from your Internet provider.

___________________________________________________________ 
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Mar 2007 11:18:58 -0400

We are quibbling over how the UAC should respond to a UAS that is in 
violation of the specs. We don't normally specify this normatively - it 
is up to implementors to cope as best they can.

Perhaps the same can be said for SDP in the 200 when a reliable 
provisional has already completed the o/a. The difference is that we 
know some implementations do this, and don't consider it to be an offer, 
so ignoring it will most likely work. In your example, its hard to 
imagine that the UAS doesn't think it is making a new offer, so ignoring 
it is much less likely to work. The only reason I can see for 
recommending this is to sneak in another optional way to do o/a.

	Paul

---

From: Kapil Nayar <[email-masked]>
Date: Thu, 15 Mar 2007 16:16:07 +0000 (GMT)

So, the SDP that your refer to in the figures/
description in draft is (answer1) always and nothing
else. Correct?

--- Paul Kyzivat <[email-masked]> wrote:

> >>> clearly restrict the "SDP" (but only offer) in
> 1xx
> >> and
> >> If so, I can see little to do other than send
> some
> >> error response to the 
> >>>>>>> reliable 1xx, then it would have the
> potential
> >>>> for a race with a
> >>>>>>> concurrent UPDATE in the other direction.
> And
> >>>> that would result in a
> >>>>>>> need to
> >>>>>>> error response. Forcing subsequent o/a to
> use
> >>>> UPDATE avoids this.
> >>>>> Yeah. It would be quite unwise to support
> 100rel
> >>>> and not UPDATE.
> >>>>>>>> can send a new offer in an UPDATE request",
> I
> >>>>>>> guess
> >>>>>>>> the authors meant F7.
> >>>>>>> Debatable. I think the UAS can send an
> UPDATE
> >>>> after
> >>>>> I don't feel too strongly about this. I think
> it
> >>>> would probably be wise to
> >>>>>>> during the evolution of this work: At most
> one
> >>>> offer and one
> >>>>>>> answer per transaction.
> >>>>>>>
> >>>>>>> At the time of F12, if the UAS wants to
> change
> >>>> the
> >>>>>>> SDP, it can send an UPDATE before sending
> the
> >>>> 2xx for the INVITE. Or it
> >>>>>>> another offer, and so it there must not be
> an
> >>>> answer to it in F13.
> >>>>>> completion of the o/a through reliable 1xx.
> As
> >>>> per RFC
> >>>>>> responses F9 and F12. Figure2 - UAS should
> not
> >>>> include
> >>>>> to be considered an offer. It is just a piece
> of
> >>>> redundant data.
> >>>>> Personally I would be happy to say that the
> UAS
> >>>> MUST NOT include SDP in
> >>>>> the 2xx in these examples. But I would also
> like
> >>>> to say (this is a best
> >>>>> But I would like to hear from Takuya (who is
> the
> >>>> primary author) and
> >>>>> others on this.
> >>>>>
> >>>> [TS]
> >>>> RFC 3261 says "UAS MUST NOT generate offer",
> not
> >>>> "UAS MUST NOT include
> >>>> I would be also happy to say "UAS MUST NOT" but
> I
> >>>> could not conclude to
> >>>>        UAC should prepare to receive an SDP in
> F9
> >>>> and/or F12, and just
> >>>>> This list is for NEW development of the core
> SIP
> >>>> Protocol
> >>>>> Use [email-masked] for new developments on
> the
> >>>> application of sip
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> 		
> >>>
> >
>
> 
> > What kind of emailer are you? Find out today - get
> a free analysis of your email personality. Take the
> quiz at the Yahoo! Mail Championship. 
> >
>

___________________________________________________________ 
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html

---

From: Kapil Nayar <[email-masked]>
Date: Thu, 15 Mar 2007 16:18:21 +0000 (GMT)

So, the SDP that your refer to in the figures1(2)/
description for F9,F12(F6,F9) in draft is (answer1)
always and nothing else. Correct?

		
___________________________________________________________ 
All New Yahoo! Mail – Tired of unwanted email come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Mar 2007 18:55:06 -0400

> always and nothing else. Correct?

Neither of these examples are suggesting that there is a second offer 
hiding in here. If SDP is included where it should not be by the UAS, 
and is ignored by the UAC, things will still work *if* the UAS had not 
intended the SDP as a new offer. If it did intend it as a new offer, 
then things are not going to work.

	Paul