Subject: [Sipping] About offeranswer draft:

From: [email-masked]
Date: Wed, 7 Apr 2010 11:14:07 +0800

Hi Paul,

While considering one problem in our production's interoperability 
testing, I re-read some parts of offeranswer draft and find something 
might be deserving discussion.

//begin of text(part):
For example, in Figure 1, only the SDP in F6 is the answer.  The SDP
   in the non-reliable response (F2) is the preview of the answer and

Kyzivat & Sawada        Expires September 9, 2010               [Page 8]

Internet-Draft     SIP Usage of the Offer/Answer Model        March 2010

   must be the same as the answer in F6.  Receiving F2, the UAC should
   act as if it receives the answer.
//end of text(part)

[Gao] In fact, UAS sending SDP in non-reliable response is for potential 
early media usage. Considering some UAS may have different address for 
early media channel and the final session, some UAS may send different 
SDP(compare with the answer) in non-reliable response. And I really found 
such equipment inside and outside of ZTE. And considering UAC, I think we 
should allow the UAC ignore the SDP in non-reliable response, while some 
UAC really do not handle any SDP which is not offer or answer. 

But the permissibility of the degree of the difference might be delicate. 
If the non-answer SDP just has different ip address or port, it seams OK. 
If the non-answer SDP has different media streams, it would be hard to 
handle for UAC.

And I re-read correlative part of RFC3261. I don't know that whether 
allowing different SDP(compare with the answer) in non-reliable response 
is violation/correction of current text or not.

//correlative part of RFC3261
o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 09 Apr 2010 11:13:53 +0900

Hi Gao,

I have no doubt that the different SDP in non-reliable response
violates current regulations.

The behaviour of UAC is an implementation issue, I think.
When UAS receives the different SDP in a reliable response from
the prior one in a non-reliable response, UAS may ...
1. terminate the session.
2. keep using the SDP in a non-reliable response.
3. change to the SDP in a reliable response.

It is not clear, but it is not a regular case.

Regards,
Shinji

[email-masked]
Wed, 7 Apr 2010 11:14:07 +0800

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 09 Apr 2010 11:24:25 +0900

Sorry,

It is just an editorial mistake.
"UAS" means "UAC".

OKUMURA Shinji <[email-masked]>
Fri, 09 Apr 2010 11:13:53 +0900
>_______________________________________________
>Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Fri, 9 Apr 2010 11:44:34 +0800

Hi,

Yes, considering implementation, I also find the three ways, especially 
for the last two ways.

My original thought is make clarification on the third one("3. change to 
the SDP in a reliable response"), by RFC3264's rule.

In fact, I think by rules, the UAC should modify the session as it is the 
lawful answer. Using early media by the SDP prior to the lawful answer is 
something outside of the lawful rules(Reliably way of using early media is 
Answer in 100rel). 

So, I think using or just discarding the SDP prior to the lawful answer is 
something depends on implementation. While "change to the SDP in a 
reliable response" should be normative.

Thanks,

Gao

OKUMURA Shinji <[email-masked]> 
发件人:  [email-masked]
2010-04-09 10:13

收件人
[email-masked]
抄送

主题
Re: [Sipping] About offeranswer draft:

Hi Gao,

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 09 Apr 2010 15:23:28 +0900

Hi Gao,

Considering a BCP recommendation in this case,

>When UAC receives the different SDP in a reliable response from
>the prior one in a non-reliable response, UAC may ...

and,
4. In case 2 or 3, it is recommended that the UAC confirms the current
   offer-answer status using a reINVITE or an UPDATE request.

However I think "may" is adequate in case 3.

Regards,
Shinji

[email-masked]
Fri, 9 Apr 2010 11:44:34 +0800

---

From: [email-masked]
Date: Fri, 9 Apr 2010 15:25:58 +0800

Hi Shinji,

By myself, I am OK with the three ways. But if there's no normative 
definition here, there would be some interworking fight for this issue.

Thanks,

Gao

2010-04-09 14:23

收件人
[email-masked]
抄送

主题

Hi Gao,

and,

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 09 Apr 2010 17:30:29 +0900

Hi Gao,

In this case it is no doubt the UAS is a cause of the problem.
All you have to do is say "Your UAS is against the rules".
You will surely win the fight.

Regards,
Shinji

[email-masked]
Fri, 9 Apr 2010 15:25:58 +0800

---

From: [email-masked]
Date: Fri, 9 Apr 2010 16:50:12 +0800

Hi Shinji,

Thanks firstly. 

But the UAS do not think it throws the problem. RFC3261 said UAS may send 
the same SDP before the answer, but there is not normative words of to 
forbid the different SDPs.

And if the equipment has been in the network, unless we using the evident 
standard, we has no way to request their correction.

Gao

2010-04-09 16:30

收件人
[email-masked]
抄送

主题

Hi Gao,

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 12 Apr 2010 11:55:47 +0900

Hi Gao,

The clarifications for the section 13.2.1 of RFC 3261 is
one of the major purposes in this draft.

In the section 3.1 of this draft,
|   3.1.  Offer/Answer for the INVITE method with 100rel extension
|   (snip)  All the session
|   descriptions in the unreliable responses to the INVITE request must
|   be identical to the answer which is included in the reliable
|   response.

Do you doubt this clarification?
In my understanding, this has already reached the consensus in WG.

I'm confused.
Do you have something a concrete proposal?

Just to be sure, this draft is not a normative document but
an informational one as you no doubt know.

Regards,
Shinji

[email-masked]
Fri, 9 Apr 2010 16:50:12 +0800

---

From: [email-masked]
Date: Mon, 12 Apr 2010 11:37:09 +0800

Hi Shinji,

Please see inlines.

Thanks,

Gao

> In my understanding, this has already reached the consensus in WG.

[Gao] I am not want to *challenge* the consensus we have reached in WG. 
But as this draft is aims for clarification, not for normative correction, 
I have no way to convince the *UAS*.

> Do you have something a concrete proposal?

[Gao] I think the original illegibility is from RFC3261. So, I sended 
mails about it in SIPCore ML:

http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html

To be honest, I think there are two options here:
1. Forbid different SDP(compare with the answer) before the answer 
normatively.
2. Allowing different SDP(compare with the answer) before the answer 
normatively.

> an informational one as you no doubt know.

[Gao] Sure, I know it is informative.

> >>>something outside of the lawful rules(Reliably way of using 
earlymedia is 
> >>>>such equipment inside and outside of ZTE. And considering UAC, 
Ithink we

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 14 Apr 2010 12:17:23 +0900

Hi Gao,

In the following case,

      UAC                   UAS
       | F1  INVITE (SDP1)   |  <-- offer
       |-------------------->|
       | F2     1xx (SDP2)   |
       |<--------------------|
       | F3     1xx (SDP3)   |
       |<--------------------|
       | F4 1xx-rel (SDP4)   |  <-- answer
       |<--------------------|
       | F5 1xx-rel (SDP5)   |
       |<--------------------|
       | F6    1xxl (SDP6)   |
       |<--------------------|
       | F7  2xx INV(SDP7)   |
       |<--------------------|
       | F8     ACK          |
       |-------------------->|
    (PRACK transactions are not shown)

I tried to arrange the rules.
(small letters mean informational)

UAC,
(Rc1)	MUST treat SDP2 as the answer.
(Rc2)	MUST ignore SDP5, SDP6 and SDP7.
(Rc3)	may treat SDP3 as the answer.
(Rc4)	should treat SDP4 as the answer and confirm the current O/A status by sending new offer.

UAS,
(Rs1)	should not send SDP5, SDP6 and SDP7.
(Rs2)	must not send SDP2 and SDP3 if these are not the same as SDP4.

Rc3 and Rc4 are new added descriptions.
Rs1 and Rs2 are current descriptions in this draft.

I think "MUST NOT" is suitable for (Rs1).
Because RFC3261 says
	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.  This means that a UAS based on this
	specification alone can never generate subsequent offers until
	completion of the initial transaction.

SDP5 and SDP7 are regarded as "subsequent offers".

What do you think of these?

Regards,
Shinji

[email-masked]
Mon, 12 Apr 2010 11:37:09 +0800
>> >>>something outside of the lawful rules(Reliably way of using earlymedia is 
>> >>>Answer in 100rel). 
>> >>>
>> >>>>such equipment inside and outside of ZTE. And considering UAC, Ithink we

---

From: [email-masked]
Date: Wed, 14 Apr 2010 12:21:45 +0800

>        | F1  INVITE (SDP1)   |  <-- offer

[Gao] OK

> status by sending new offer.

[Gao] support of this, though this may be modification of current RFC3261.

>    completion of the initial transaction.

[Gao] Yes.

> SDP5 and SDP7 are regarded as "subsequent offers".

[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no "subsequent 
offers" in subsequent response.

> >> >But the UAS do not think it throws the problem. RFC3261 said UASmay 
send 

> >> >>>My original thought is make clarification on the third 
one("3.change to

---

From: Eric wang <[email-masked]>
Date: Wed, 14 Apr 2010 13:04:34 +0800

Hi all,

    I believe that SDP in non-reliable response is useful. eg, if the UAS
wants to send a tone to UAC while the UAC doesn't support 100rel, the UAS
can use a non-reliable response with the tone SDP.
So I believe different SDPs(compare with the answer) can exist in
non-reliable response and final 2xx response.

   But, when I saw the chart below, the only words in my mind is ,"OMG, the
SIP is never SI(m)P(le) again!"

2010/4/14 OKUMURA Shinji <[email-masked]>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 14 Apr 2010 16:31:54 +0900

Hi Gao,

[email-masked]
Wed, 14 Apr 2010 12:21:45 +0800
>[Gao] support of this, though this may be modification of current RFC3261.

You will probably think of the following statements,
RFC3261/13.2.1 Creating the Initial INVITE
	(snip) "The UAC MUST treat the first session
	description it receives as the answer, and MUST ignore any
	session descriptions in subsequent responses to the initial
	INVITE."

No doubt this is one of the cussword built in this document.
It is a personal interpretation of mine,
	"as the answer" is associated with not "treat" but "receives",
	and "treat" means "not ignore".

Just putting that aside for now, I think there is a consensus that
Rc4 does not need a modification of current RFC3261.

>offers" in subsequent response.

Certainly UAC MUST ignore SDPs no matter what these are.

Regards,
Shinji

---

From: [email-masked]
Date: Wed, 14 Apr 2010 17:18:41 +0800

Hi Shinji,

> Rc4 does not need a modification of current RFC3261.

I see. But if there's memo of such consensus, it would be quite useful in 
interworking testing.

---

From: "Somogyi, Gabor (NSN - HU/Budapest)" <[email-masked]>
Date: Wed, 14 Apr 2010 14:51:30 +0300

Hi,
 
RFC3261: "...MUST ignore any session descriptions in subsequent responses..."
I think that the common industry understanding of RFC3261 is that 1 offer has 1 answer, even though that 1 answer may be transmitted several times. And the 1st transmission is used (treated as THE answer). While you are speaking about several answers with 1 matching offer. That is a fundamental difference.
 
In your chart SDP4 is a reliable answer. Therefore SDP5 might be interpreted as a new offer, hence UAC could send an answer in PRACK. Quite similarly to 3PCC cases, where 200 contains the offer and ACK the answer.
 
In my opinion it is better not to allow an answer updating a prior answer of the same offer. If early meadia is a real issue, implement support for 100rel and send update using UPDATE method. Or UAC could play ring-back tone locally. That is another cheap and easy solution. I do not see any reason for hacking.
 
BR,
Som
 
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, April 14, 2010 11:19
To: OKUMURA Shinji
Cc: [email-masked]; [email-masked]
Subject: [Sipping] 答复: Re: About offeranswer draft:

Hi Shinji, 

> Rc4 does not need a modification of current RFC3261.

I see. But if there's memo of such consensus, it would be quite useful in interworking testing.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Apr 2010 15:07:09 +0200

As far as I am concerned we are NOT writing these things into offer answer

offer answer is meant to be a general clarification of what exists at the moment.

The statements you are proposing update RFC 3264 and need to be in a candidate standards track RFC that does that.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of OKUMURA Shinji
> Sent: Wednesday, April 14, 2010 8:32 AM
> To: [email-masked]
> Subject: Re: [Sipping] About offeranswer draft:
> 
> Hi Gao,
> 
> [email-masked]
> >> (Rc4)   should treat SDP4 as the answer and confirm the 
> current O/A 
> >> status by sending new offer.
> >
> >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no 
> >"subsequent offers" in subsequent response.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2010 09:56:50 -0400

Keith,

I agree with with the point I think you are making. But we are walking a 
fine line here. The goal has not been to enact changes with this draft. 
There are some cases where the spec is definitely ambiguous, and for 
those we have had to get another stds track doc to fix - e.g. reinvite.

In other cases the specs are far from clear, but if you read them very 
carefully some seemingly ambiguous cases can be found to be corollaries 
of existing text. In that situation, having this draft write down those 
determinations doesn't change anything but is of great aid to developers.

And then there remain cases that are ambiguous, but where some best 
practices can avoid the ambiguities.

> Rc4 does not need a modification of current RFC3261.

then I am actually not sure at the moment which category this falls 
into. Its worthy of discussion.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2010 10:02:59 -0400

Eric wang wrote:
> Hi all,
>  
>     I believe that SDP in non-reliable response is useful. eg, if the 
> UAS wants to send a tone to UAC while the UAC doesn't support 100rel, 
> the UAS can use a non-reliable response with the tone SDP.

IMO this makes no sense. For one thing, the UAC is instructed to accept
the first and ignore the rest, so sending differing values will have no
utility. For another, this only affects where the UAS will receive media
- it can have no effect on where the UAC receives media. Generally the
UAC isn't transmitting until the call is established, so what is the point.

>    But, when I saw the chart below, the only words in my mind is ,"OMG, 
> the SIP is never SI(m)P(le) again!"

Where have you been? SIP hasn't been simple since early in the century.

	Thanks,
	Paul

> 2010/4/14 OKUMURA Shinji <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Hi Gao,
> 
>     In the following case,
> 
>          UAC                   UAS
>     [email-masked] <mailto:[email-masked]>
>      >[email-masked] <mailto:[email-masked]> 写于
>     2010-04-12 10:55:47:
>      >
>      >> Hi Gao,
>      >>
>      >> [email-masked] <mailto:[email-masked]>
>      >> >OKUMURA Shinji <[email-masked]
>     <mailto:[email-masked]>>
>      >> >发件人:  [email-masked] <mailto:[email-masked]>
>      >> >2010-04-09 16:30
>      >> >
>      >> >收件人
>      >> >[email-masked] <mailto:[email-masked]>
>      >> >抄送
>      >> >
>      >> >主题
>      >> >[email-masked] <mailto:[email-masked]>
>      >> >>OKUMURA Shinji <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      >> >>2010-04-09 14:23
>      >> >>
>      >> >>收件人
>      >> >>[email-masked] <mailto:[email-masked]>
>      >> >>抄送
>      >> >>
>      >> >>主题
>      >> >>[email-masked] <mailto:[email-masked]>
>     one("3. change to
>      >> >>>OKUMURA Shinji <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      >> >>>2010-04-09 10:13
>      >> >>>
>      >> >>>收件人
>      >> >>>[email-masked] <mailto:[email-masked]>
>      >> >>>抄送
>      >> >>>
>      >> >>>主题
>      >> >>>[email-masked] <mailto:[email-masked]>
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new developments of core SIP
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2010 10:12:48 -0400

Somogyi, Gabor (NSN - HU/Budapest) wrote:
> I think that the common industry understanding of RFC3261 is that 1 
> offer has 1 answer, even though that 1 answer may be transmitted several 
> times. 

Yes. Well, actually one answer per dialog. (With forking, an offer in
the initial invite will get a separate answer per-forked-dialog.)

> And the 1st transmission is used (treated as THE answer). While 
> you are speaking about several answers with 1 matching offer. That is a 
> fundamental difference.

This of course only makes sense if the sdp in all unreliable responses
is the same as the sdp in the first reliable response. That is so
because any/all of the unreliable responses may be lost. You cannot
count on the UAC using the SDP from the first transmission.

And because of that, a valid implementation could drop all the SDP
received unreliably and only process the one received reliably.

> In your chart SDP4 is a reliable answer. Therefore SDP5 might be 
> interpreted as a new offer, hence UAC could send an answer in PRACK. 
> Quite similarly to 3PCC cases, where 200 contains the offer and ACK the 
> answer.

That has been investigated. Its not allowed. (Unfortunately I cannot
recall the chain of reasoning that derived its illegality - it wasn't
obvious but it was sound. It was worked out a *long* time ago.)

	Thanks,
	Paul

> In my opinion it is better not to allow an answer updating a prior 
> answer of the same offer. If early meadia is a real issue, implement 
> support for 100rel and send update using UPDATE method. Or UAC could 
> play ring-back tone locally. That is another cheap and easy solution. I 
> do not see any reason for hacking.
>  
> BR,
> Som
>  
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext [email-masked]
> *Sent:* Wednesday, April 14, 2010 11:19
> *To:* OKUMURA Shinji
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [Sipping] 答复: Re: About offeranswer draft:
> 
> 
> Hi Shinji,
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2010 10:23:57 -0400

inline

[email-masked] wrote:
> But as this draft is aims for clarification, not for normative 
> correction, I have no way to convince the *UAS*.

(I just posted a related reply to a later message in this thread.)

Whether this clarification is supported by the existing normative text
is worthy of some careful thought.

As I noted in the other reply, a UAS sending multiple *unreliable*
responses with SDP must assume that some or all of them will be lost. If
these SDPs have different values, and the UAC processes the first it
receives, and ignores the rest, then the resulting behavior will be
indeterminate.

IMO this is sufficient to infer that there is only one meaningful
interpretation, so that a clarification is sufficient without a
normative change.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2010 10:25:30 -0400

I'm not going to reply to this until there has been discussion on my 
other replies.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Apr 2010 22:38:21 +0200

Hi,

>obvious but it was sound. It was worked out a *long* time ago.)

The rule we have agreed to is very simple: at most one offer/answer exchange per SIP transaction.

Whether it's clearly specified somewhere needs to be checked, though.

I know there are implementations that "update" the SDP answer from one reliable response to another (within the same transaction), for the same transaction, but that is certainly nothing we have standardized.

Regards,

Christer

---

From: [email-masked]
Date: Thu, 15 Apr 2010 09:03:59 +0800

> exchange per SIP transaction.

Yes, it is. And what I talked here is also under this basic rule.

> I know there are implementations that "update" the SDP answer from 
> one reliable response to another (within the same transaction), for 
> the same transaction, but that is certainly nothing we have 
standardized.

I think it should be mentioned here, what is the *lawful* answer?
It is the one in the first reliable response.

As it is the *lawful* answer, I think the UAC should using it when it get 
the answer. And this seems *should* be made normative.
While how UAC handle SDP(from UAS) before the real answer, it can be BCP 
issue.

Why I think this should be clarified, is that during interworking testing, 
we should know which side is reasonable.

Thanks,

Gao

> >  > >> (Rc4)   should treat SDP4 as the answer and confirm the current 
O/A
> > ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> > This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: [email-masked]
Date: Thu, 15 Apr 2010 09:52:16 +0800

> received unreliably and only process the one received reliably.

Supporting of this. 
My point here is that making UAC's using of the SDP in first reliable 
response normatively, no matter how many SDP it received before the *real* 
answer. And how UAC handle SDP(from UAS) before the real answer is another 
issue, it can be BCP issue.

---

From: Eric wang <[email-masked]>
Date: Thu, 15 Apr 2010 13:41:48 +0800

在 2010年4月15日 下午1:29，Eric wang <[email-masked]>写道：

> Hi Paul,
>    I have been in the world for many years =_=!!!!
>    We shouldn't make complicated rules because the system has already  been
> complicated.
>
>   In my opinion, the offer/answer model works well if responses are
> reliable.
>   If we allow several reliable 18x with SDP, what happen if 18x is after
> UPDATEs.There must be some rules saying "NO".I prefer several reliable 18xs
> with SDP appear only in fork.
>
>  BR
>  Eric
>
>
>
> 在 2010年4月14日 下午10:02，Paul Kyzivat <[email-masked]>写道：
>
>
>>
>> Eric wang wrote:
>> > Hi all,
>> >

---

From: [email-masked]
Date: Thu, 15 Apr 2010 14:32:20 +0800

Hi Paul and Shinji,

I guess I can converg my discussion on the point, should UAC refresh the 
media plane by the real answer? 

Or, just ignore the real answer, if it has gotten one in one previous 
unreliable response?

And no matter what direction we choose, we should do the evaluation about 
whether it is violation/correction of RFC3261.

Thanks,

Gao

---

From: Eric wang <[email-masked]>
Date: Thu, 15 Apr 2010 14:50:52 +0800

HI,
    inlines.

BR.
2010/4/15 <[email-masked]>

> issue, it can be BCP issue.

 Eric: I  think, the UAC should listen the SDP sending packets,and choose
another to listen according to rfc3264.
 Reuse Shinji 's chart, if SDP2 sends packets while SDP3/SDP4 don't,
 the UAC should listen SDP2 and SDP5.

       UAC                   UAS
        | F1  INVITE (SDP1)   |  <-- offer
        |-------------------->|
        | F2     1xx (SDP2)   |
        |<--------------------|
        | F3     1xx (SDP3)   |
        |<--------------------|
        | F4     1xx (SDP4)   |
        |<--------------------|
        | F5 1xx-rel (SDP5)   |<-- answer
        |<--------------------|

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 15 Apr 2010 17:20:09 +0900

Hi Eric,

Eric wang <[email-masked]>
Thu, 15 Apr 2010 13:29:41 +0800
>We shouldn't make complicated rules because the system has
>already been complicated.
>
>In my opinion, the offer/answer model works well if responses
>are reliable.
>If we allow several reliable 18x with SDP, what happen if 18x
>is after UPDATEs.There must be some rules saying "NO".
>I prefer several reliable 18xs with SDP appear only in fork.

I'm confused.
Nobody says that several reliable 18x may include a SDP even if
it is the same as the answer.

Just you said "different SDPs(compare with the answer) can
exist in non-reliable response and final 2xx response".

Regards,
Shinji

>Paul Kyzivat wrote

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 15 Apr 2010 17:22:59 +0900

Hi Gao,

[email-masked]
Thu, 15 Apr 2010 14:32:20 +0800
>Hi Paul and Shinji,
>
>I guess I can converge my discussion on the point, should UAC refresh the 

IMO UAC should refresh the current view of a session description
by the real answer.

>whether it is violation/correction of RFC3261.

I think, in RFC3261 UAC's behavior is described based on the
premise that UAS never include the different SDP from the answer
into the prior unreliable responcse.
It is absolutely an implicit premise. But it is not bad, I think.

So then we can think that UAC's behavior for the different SDP
is not described in RFC. Therefor it can be BCP and does not
violate RFC.

Quod Erat Demonstrandum.

Regards,
Shinji

---

From: [email-masked]
Date: Thu, 15 Apr 2010 16:42:48 +0800

Hi Shinji,

2010-04-15 16:22

收件人
[email-masked]
抄送

主题

Hi Gao,

[email-masked]

[Gao] By myself, I also prefer this one.

[Gao] If we want to BCP thing for different SDP, we need to clarify that 
*same* SDP is not mandatory for UAS's behavior.
I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is 
normative change from RFC3261 or not.

Quod Erat Demonstrandum.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 15 Apr 2010 18:07:08 +0900

Hi,

I think "*same* SDP is mandatory for UAS's behavior",
and
"That same exact answer MAY also be placed in any provisional
responses sent prior to the answer." means it adequately for me.

Regards,
Shinji

[email-masked]
Thu, 15 Apr 2010 16:42:48 +0800

---

From: [email-masked]
Date: Thu, 15 Apr 2010 17:14:09 +0800

Hi,

2010-04-15 17:07

收件人
[email-masked]
抄送

主题

Hi,

[Gao] As you think *same* if mandatory, why not just ignore the real 
answer, if it has gotten one in one previous unreliable response?

and

Regards,
Shinji

---

From: Eric wang <[email-masked]>
Date: Thu, 15 Apr 2010 17:17:47 +0800

HI Shinji,

  I noticed the chart in your mail showed ,SDP4 and SDP5 both exist in
reliable response(1xx-rel). In my mind, no matter SDP5 is offer or answer,
it shouldn't be allowed.

     UAC                   UAS

Shinji: Just you said "different SDPs(compare with the answer) can
exist in non-reliable response and final 2xx response".
Eric:  I mean different SDPs may appear in non-reliable response,because
some SERVER may use 1xx with SDP
to play some announcements before foward a call, eg a charge server "HI guy,
you have only 5 minute to communicate",
or, a redirect server "the call is forwarding"!   If the server want to use
reliable response, it must use re-INVITE after
the call is established ,for the SERVER cannot send the SDP in final
response from UE-B to UE-A.But if the SERVER
use non-reliable response, the SERVER may use final response to carry SDP.

UE-A       SERVER     UE-B
| - INVITE -> |                |
 | <-18x-------- |                |
 |                  | -INVITE ->|
|                  |                |

BR

Eric

---

From: Eric wang <[email-masked]>
Date: Thu, 15 Apr 2010 17:40:17 +0800

HI Shinji,

     UAC                   UAS

UE-A       SERVER     UE-B
| - INVITE -> |                |
| <-18x-------- |                |
|                  | -INVITE ->|
|                  |                |

BR

Eric

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 15 Apr 2010 19:04:13 +0900

Hi,

[email-masked]
Thu, 15 Apr 2010 17:14:09 +0800
>发件人:  [email-masked]

Because I am a kind man for an ill-behaved UAS.

nantene

---

From: [email-masked]
Date: Wed, 14 Apr 2010 14:07:02 +0800

Hi Eric,

Are you ZTE's Eric? I have one colleague also named Eric wang(Wang Libo). 

And some comments inlines.

Thanks,

Gao

[email-masked] 写于 2010-04-14 13:04:34:

> Hi all,
> 
>     I believe that SDP in non-reliable response is useful. eg, if 
> the UAS wants to send a tone to UAC while the UAC doesn't support 
> 100rel, the UAS can use a non-reliable response with the tone SDP.

Yes, it is so in many deployed network. But the key problem here about the 
UAC's normative handling of the real answer, if it is different from the 
previous the SDP from the UAS.

> 
>    But, when I saw the chart below, the only words in my mind is 
> ,"OMG, the SIP is never SI(m)P(le) again!"

I guess it is the extreme use case in theory. Considering normal call 
flow, it would be more simple. But if we should evaluate the rules, we 
usually need such use cases, as Shinji showed us.

>       | F1  INVITE (SDP1)   |  <-- offer
correction,
one("3.change to
> >> >>>>should allow the UAC ignore the SDP in non-reliable 
response,while some

---

From: [email-masked]
Date: Thu, 15 Apr 2010 09:11:44 +0800

> receives, and ignores the rest, then the resulting behavior will be

Yes. So, I think finally using the real answer in the first reliable 
response can making the final session determinate.
But in your case, UAC would have a indeterminate early media, depending on 
which SDP is the one it first receives.

> interpretation, so that a clarification is sufficient without a

I don't catch this point. Could you say it more.

Thanks,

Gao

> >  > >>>In fact, I think by rules, the UAC should modify the session as 
it 
> > is the
> >  > >>>So, I think using or just discarding the SDP prior to the lawful 

> > answer is
> >  > >>>>   must be the same as the answer in F6.  Receiving F2, the UAC 

> > should
> >  > >>>>But the permissibility of the degree of the difference might be 

> > delicate.
> >  > >>>>If the non-answer SDP just has different ip address or port, it 

> > seams OK.
> >  > >>>>allowing different SDP(compare with the answer) in non-reliable 

> > response
> >  > >>>>      o  If the initial offer is in an INVITE, the answer MUST 
be 
> > in a

---

From: Eric wang <[email-masked]>
Date: Thu, 15 Apr 2010 13:29:41 +0800

Hi Paul,

 BR
 Eric

在 2010年4月14日 下午10:02，Paul Kyzivat <[email-masked]>写道：

> >      >> >发件人:  [email-masked] <mailto:[email-masked]
> >
> >      >> >2010-04-09 16:30
> >      >> >
> >      >> >收件人
> >     response, while some

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 10:42:03 -0400

Eric - inline

Eric wang wrote:
> HI,
>     inlines.
> 
> BR.
> 2010/4/15 <[email-masked] <mailto:[email-masked]>>
> 
> 
>     Paul Kyzivat <[email-masked] <mailto:[email-masked]>> 写于
>     2010-04-14 22:12:48:
> 
> 
>      >
>      >
>     My point here is that making UAC's using of the SDP in first
>     reliable response normatively, no matter how many SDP it received
>     before the *real* answer. And how UAC handle SDP(from UAS) before
>     the real answer is another issue, it can be BCP issue. 
> 
>  
>  Eric: I  think, the UAC should listen the SDP sending 
> packets,and choose another to listen according to rfc3264.

Eric,

I think you may be talking about cases where the call has been forked to 
different destinations, and the distinct answers are coming from them. 
Is that right?

Because in that case the responses should have different to-tags, thus 
becoming distinct (early) dialogs. The discussion we are having is about 
what happens in a *single* dialog. And in a single dialog the behavior 
you describe is *wrong*.

When there are multiple early dialogs, it is indeed a challenge for the 
UAC to figure out what to do. And one of the things it might choose is 
to listen to one input stream and ignore the others. Unfortunately, 
there is universal and certain way to associate the incoming media 
streams you are receiving with the answers you have received in the 
signaling. You can do so in certain cases that may apply to you, such as 
when symmetric RTP is used (address/port of sender is same as 
address/port that is listened on.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 10:59:50 -0400

inline

[email-masked] wrote:
> As it is the *lawful* answer, I think the UAC should using it when it 
> get the answer. And this seems *should* be made normative.

I think you are arguing that it is "lawful" for the UAS to send
differing values for the SDP successive unreliable responses and in the
subsequent reliable response. And that it is then the responsibility of
the UAC to make this work "right" and "deterministically" by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC will receive the
first, or any of, the unreliable responses. So if it were to do this odd
behavior it must be satisfied that *any* of then are the one that the
UAC uses. Or else it must be assuming that the UAC *might* use one or
more of the unreliable ones, and eventually *switch* to the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it receives, and
ignore the remainder, *including* the reliable one. There is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC can follow
that is valid and consistent in the face of loss of unreliable responses
is for them all to contain the same SDP. So that is the *lawful*
behavior - a UAS that violates this is unreasonable.

	Thanks,
	Paul

> Why I think this should be clarified, is that during interworking 
> testing, we should know which side is reasonable.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 11:10:27 -0400

Correction:

> Hence, its a corollary that the only behavior that the UAC can follow

I meant to say UAS above.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 19:16:44 +0200

Hi,

>>the same transaction, but that is certainly nothing we have standardized.
>>

Agree. Whatever comes before that (unreliably), and after that (reliably OR unreliably),
has no meaning.

>provision for *switching*.

Agree.

I am aware of implementations that, once they have received a reliable SDP answer,
they don't even parse additional SDPs for the same transaction. So, they don't even
know whether the additional SDPs are identical or not.

>behavior - a UAS that violates this is unreasonable.

Yes.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 19:26:25 +0200

Hi,

SIP used to be (m)music to my ears...

Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a SDP in an unreliable 18x. But, it is not the "official" SDP answer.

And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the reliable answer is then different, the UAC should consider it as a protocol error in my opinion - not do any "switching".

>We shouldn't make complicated rules because the system has already  been complicated.

What is complicated in "There can be only one SDP answer per transaction, and it comes in the first reliable response of that transaction"?

>In my opinion, the offer/answer model works well if responses are reliable.
>If we allow several reliable 18x with SDP, what happen if 18x is after UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs with SDP appear only in fork.

If the UAC sends a new offer in UPDATE, it will receive the new answer in the UPDATE 200 OK.

The 18x still belongs to the INVITE transaction, and may contain the previous SDP answer. But, since you have already received an SDP answer for the INVITE transaction, the SDP in the new 18x it has no meaning - no matter if there are UPDATE(s) or not...

Regards,

Christer

在 2010年4月14日 下午10:02，Paul Kyzivat <[email-masked]<mailto:[email-masked]>>写道：

       Thanks,
       Paul

> 2010/4/14 OKUMURA Shinji <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>
>
>     Hi Gao,
>
>     In the following case,
>
>          UAC                   UAS
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> 写于
>     2010-04-12 10:55:47:
>      >
>      >> Hi Gao,
>      >>
>      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >OKUMURA Shinji <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      >> >发件人:  [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >2010-04-09 16:30
>      >> >
>      >> >收件人
>      >> >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >抄送
>      >> >
>      >> >主题
>      >> >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >>OKUMURA Shinji <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      >> >>发件人:  [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >>2010-04-09 14:23
>      >> >>
>      >> >>收件人
>      >> >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >>抄送
>      >> >>
>      >> >>主题
>      >> >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >>>OKUMURA Shinji <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      >> >>>发件人:  [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >>>2010-04-09 10:13
>      >> >>>
>      >> >>>收件人
>      >> >>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> >>>抄送
>      >> >>>
>      >> >>>主题
>      >> >>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     Use [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> for questions on current sip
>     Use [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> for new developments of core SIP
>
>
>
> Use [email-masked]<mailto:[email-masked]> for questions on current sip
> Use [email-masked]<mailto:[email-masked]> for new developments of core SIP

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Apr 2010 20:55:27 +0200

> Anyway, I don't anyone has said that it is "forbidden" for a
> UAC to use a SDP in an unreliable 18x. But, it is not the
> "official" SDP answer.
>

We write specifications that indicate what you are meant to do, not what you are not meant to do.

If someone tries to write different SDP in a subsequent response, then that is a proprietary extension that has not been signalled by any of the compatibility mechanisms, and people should expect it not to work.

We do not change the standard to fix those sort of problems.

Keith

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Thursday, April 15, 2010 6:26 PM
> To: Eric wang; Paul Kyzivat
> Cc: OKUMURA Shinji; [email-masked]
> Anyway, I don't anyone has said that it is "forbidden" for a
> UAC to use a SDP in an unreliable 18x. But, it is not the
> "official" SDP answer.
>
> And, if the UAC uses the SDP in the unreliable 18x, and the
> SDP in the reliable answer is then different, the UAC should
> consider it as a protocol error in my opinion - not do any
> "switching".
>
> What is complicated in "There can be only one SDP answer per
> transaction, and it comes in the first reliable response of
> that transaction"?
>
> >If we allow several reliable 18x with SDP, what happen if
> 18x is after UPDATEs.There must be some rules >saying "NO".I
> prefer several reliable 18xs with SDP appear only in fork.
>
> The 18x still belongs to the INVITE transaction, and may
> contain the previous SDP answer. But, since you have already
> received an SDP answer for the INVITE transaction, the SDP in
> the new 18x it has no meaning - no matter if there are
> UPDATE(s) or not...
>
> Regards,
>
> Christer
>
>
>
>
>
>
> 在 2010年4月14日 下午10:02，Paul Kyzivat
> <[email-masked]<mailto:[email-masked]>>写道：
>
>
> Eric wang wrote:
> > Hi all,
> >
> IMO this makes no sense. For one thing, the UAC is instructed
> to accept the first and ignore the rest, so sending differing
> values will have no utility. For another, this only affects
> where the UAS will receive media
> - it can have no effect on where the UAC receives media.
> Generally the UAC isn't transmitting until the call is
> established, so what is the point.
>
> > 2010/4/14 OKUMURA Shinji
> > <[email-masked]<mailto:[email-masked]>
> >
> <mailto:[email-masked]<mailto:[email-masked]
> > >>>
> >
> >     Hi Gao,
> >
> >     In the following case,
> >
> >          UAC                   UAS
> >     [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> 写于
> >     2010-04-12 10:55:47:
> >      >
> >      >> Hi Gao,
> >      >>
> >      >[Gao] I am not want to *challenge* the consensus we
> have reached
> >     in WG.
> >      >> [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >But the UAS do not think it throws the problem.
> RFC3261 said
> >     UAS may send
> >      >> >And if the equipment has been in the network,
> unless we using
> >     the evident
> >      >> >OKUMURA Shinji
> <[email-masked]<mailto:[email-masked]>
> >
> >      >> >发件人:
> [email-masked]<mailto:[email-masked]>
> >      >> >[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >抄送
> >      >> >
> >      >> >主题
> >      >> >[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >>definition here, there would be some interworking
> fight for
> >     this issue.
> >      >> >>
> >      >> >>Thanks,
> >      >> >>
> >      >> >>Gao
> >      >> >>
> >      >> >>OKUMURA Shinji
> <[email-masked]<mailto:[email-masked]>
> >
> >      >> >>发件人:
> [email-masked]<mailto:[email-masked]>
> >
> >      >> >>[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >>抄送
> >      >> >>
> >      >> >>主题
> >      >> >>4. In case 2 or 3, it is recommended that the UAC
> confirms the
> >     current
> >      >> >>[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >>>Yes, considering implementation, I also find the
> three ways,
> >     especially
> >      >> >>>for the last two ways.
> >      >> >>>
> >      >> >>>In fact, I think by rules, the UAC should modify
> the session
> >     as it is the
> >      >> >>>something depends on implementation. While
> "change to the SDP
> >     in a
> >      >> >>>OKUMURA Shinji
> <[email-masked]<mailto:[email-masked]>
> >
> >      >> >>>发件人:
> [email-masked]<mailto:[email-masked]>
> >
> >      >> >>>[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >>>抄送
> >      >> >>>
> >      >> >>>主题
> >>>[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> >>>>testing, I re-read some parts of offeranswer
> draft and find
> >     something
> >      >> >>>>   in the non-reliable response (F2) is the
> preview of the
> >     answer and
> >      >> >>>>   must be the same as the answer in F6.
> Receiving F2, the
> >     UAC should
> >      >> >>>>[Gao] In fact, UAS sending SDP in non-reliable
> response is
> >     for potential
> >      >> >>>>early media usage. Considering some UAS may
> have different
> >     address for
> >      >> >>>>early media channel and the final session, some
> UAS may send
> >     different
> >      >> >>>>SDP(compare with the answer) in non-reliable
> response. And I
> >     really found
> >      >> >>>>such equipment inside and outside of ZTE. And
> considering
> >     UAC, Ithink we
> >      >> >>>>But the permissibility of the degree of the
> difference might
> >     be delicate.
> >      >> >>>>If the non-answer SDP just has different ip
> address or port,
> >     it seams OK.
> >      >> >>>>If the non-answer SDP has different media
> streams, it would
> >     be hard to
> >      >> >>>>handle for UAC.
> >      >> >>>>
> >      >> >>>>
> >      >> >>>>And I re-read correlative part of RFC3261. I
> don't know that
> >     whether
> >      >> >>>>      o  If the initial offer is in an INVITE,
> the answer
> >     MUST be in a
> >      >> >>>>         reliable non-failure message from UAS
> back to UAC
> >     which is
> >      >> >>>>         correlated to that INVITE.  For this
> specification,
> >     that is
> >      >> >>>>         only the final 2xx response to that
> INVITE.  That
> >     same exact
> >      >> >>>>         prior to the answer.  The UAC MUST
> treat the first
> >     session
> >      >> >>>>         session descriptions in subsequent
> responses to the
> >     initial
> >      >> >>>>         INVITE.
> >      >> >>>>
> >      >> >>>>Thanks,
> >      >> >>>>
> >      >> >>>>Gao
> >     Sipping mailing list
> https://www.ietf.org/mailman/listinfo/sipping
> >     Use
> [email-masked]<mailto:[email-masked]
> lumbia.edu>
> >
> <mailto:[email-masked]<mailto:sip-implemento
> [email-masked]>> for questions on current sip
> >     Use [email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>> for new developments of
> > core SIP
> >
> >
> >
> >
> > This list is for NEW development of the application of SIP Use
> >
> [email-masked]<mailto:[email-masked]
> > du> for questions on current sip Use
> [email-masked]<mailto:[email-masked]>
> > for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 16:15:51 -0400

another correction :-(
(I'm having a bad day that way)

Paul Kyzivat wrote:
...
> there is universal and certain way to associate the incoming media 

s/there is universal/there is *no* universal/

	Sorry,
	Paul

---

From: Eric wang <[email-masked]>
Date: Fri, 16 Apr 2010 10:56:18 +0800

Hi Paul,
inlines.

On Thu, Apr 15, 2010 at 10:42 PM, Paul Kyzivat <[email-masked]> wrote:

>>     > >       > > RFC3261: "...MUST ignore any session descriptions in
>> subsequent
>>     > > responses..."
> different destinations, and the distinct answers are coming from them. Is
> that right?
>
No. I meant there may be several non-reliable responses in  a *single*
dialog.
There maybe several servers that want to send non-reliable response with
SDP(neither offer nor answer) to the caller.I accept it as  non-reliable
responses with SDP can also establish early dialog for tone/announcement and
do nothing with offer/answer negotiation between the caller and the called.
I know it violate rfc3261, but it's useful and simple.

> what happens in a *single* dialog. And in a single dialog the behavior you
> describe is *wrong*.
>
But I cannot accept that several reliable responses with SDP appear in a
single dialog, and it seems be allowed in Shinji's chart.

BR
Eric

> When there are multiple early dialogs, it is indeed a challenge for the UAC
> to figure out what to do. And one of the things it might choose is to listen
> to one input stream and ignore the others. Unfortunately, there is universal
> and certain way to associate the incoming media streams you are receiving
> with the answers you have received in the signaling. You can do so in
> certain cases that may apply to you, such as when symmetric RTP is used
> (address/port of sender is same as address/port that is listened on.)
>
>        Thanks,
>        Paul
>
>
>        UAC                   UAS
>>        | F4     1xx (SDP4)   |         |<--------------------|
>>    ZTE Information Security Notice: The information contained in this mail
>> is solely property of the sender's organization. This mail communication is
>> confidential. Recipients named above are obligated to maintain secrecy and
>> are not permitted to disclose the contents of this communication to others.
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> originator of the message. Any views expressed in this message are those of
>> the individual sender.

---

From: [email-masked]
Date: Fri, 16 Apr 2010 11:36:22 +0800

Christer Holmberg <[email-masked]> 
2010-04-16 01:16

收件人
Paul Kyzivat <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, OKUMURA Shinji 
<[email-masked]>
主题
RE: [Sipping] About offeranswer draft:

Hi,

standardized.
>It is the one in the first reliable response.

Agree. Whatever comes before that (unreliably), and after that (reliably 
OR unreliably),
has no meaning.

Agree.

I am aware of implementations that, once they have received a reliable SDP 
answer,
they don't even parse additional SDPs for the same transaction. So, they 
don't even
know whether the additional SDPs are identical or not.

[Gao] Yes. 
But when the UAC have received the SDP in one unreliable response, could 
it ignore subsequent SDP, even the REAL ANSWER. By current RFC3261, it 
should ignore subsequent SDP, even the REAL ANSWER.

Now, we also have other signal rules on O/A, such as sending UPDATE after 
the ini-O/A. The key here is, IS the SDP (in unreliable before the real 
ANSWER) answer?
If it is answer, then signal rules on O/A need to be corrected. 
If it is not answer, the RFC3261's text seems need correction. 

As O/A draft does not aim for normative correction, so I just feel it 
seams need a normative one. I guess Paul has the prestige to draft such 
text:)

Yes.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 16 Apr 2010 12:39:12 +0900

Hi Eric,

Eric wang <[email-masked]>
Thu, 15 Apr 2010 17:40:17 +0800
>HI Shinji,
> 
>I noticed the chart in your mail showed ,SDP4 and SDP5 both
>exist in reliable response(1xx-rel). In my mind, no matter
>SDP5 is offer or answer, it shouldn't be allowed.

Agree. And I have said the same thing in the original mail.
You have misunderstood my mail.

>Shinji:
>Eric:
>    I mean different SDPs may appear in non-reliable response,
>    because some SERVER may use 1xx with SDP
>    to play some announcements before foward a call, eg a charge
>    server "HI guy, you have only 5 minute to communicate",
>    or, a redirect server "the call is forwarding"!   If the server
>    want to use reliable response, it must use re-INVITE after
>    the call is established ,for the SERVER cannot send the SDP
>    in final response from UE-B to UE-A.But if the SERVER
>     | <-18x------ |            |
>     |             | -INVITE -> |

IMO "SERVER" in your chart is B2BUA.
Because it sends an original 18x not depended on UE-B.

This situation is just a fork.

Regards,
Shinji

---

From: [email-masked]
Date: Fri, 16 Apr 2010 11:43:43 +0800

Hi Paul,

My previous mail to Christer is about the same topic.

To be honest, your agree almost all of your reply. And I once have the 
same understanding of RFC3261.
But when I reviewed again during the interworking-testing(in new 
interworking-testing, we always face some new equipment and hear some new 
understanding of RFC3261 from them), I feel it seams need correction.

Thanks,

Gao

Paul Kyzivat <[email-masked]> 
2010-04-15 22:59

收件人
[email-masked]
抄送
Christer Holmberg <[email-masked]>, "Somogyi, Gabor (NSN - 
HU/Budapest)" <[email-masked]>, OKUMURA Shinji 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [Sipping] About offeranswer draft:

inline

                 Thanks,
                 Paul

---

From: Eric wang <[email-masked]>
Date: Fri, 16 Apr 2010 11:49:31 +0800

> You have misunderstood my mail.

Sorry for that ,I was shocked by your chart:)

> Because it sends an original 18x not depended on UE-B.
Yes!

BR
Eric

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 07:29:27 +0200

Hi,

>I think UAC should consider SDP in reliable response as the correct one and listen to it.

Yes, and I think that is what at least me and Paul have been trying to say. But, after you've received the answer in one reliable answer, it can't be updated in another reliable answer.

>I don't konw why unreliable 18x with SDP be considered as answer if received, I will be appreciate if someone tell my why.

It will NOT be considered as answer. Sometimes we talk about it as a "preview of the answer". Whatever the UAC does with it is unspecified (unless you use ICE, where the unreliable SDP actually IS used - but it is still not considered as answer).

>I mean, It's complicated if SDPs in reliable responses should be ingored(treated as neither offer nor answer), because UAC has already received answer SDP in either reliable or unreliable response.
>I support no SDP in reliable responses should be ignored, we should trust *reliable*.

I agree.

But, still, according to the rules the SDPs in the unreliable and reliable responses have to be the same.

>The meaningless SDP would make mechanism harder to implementation.

I don't understand how it would make anything harder. Once you've received an SDP answer in a reliable response, you simply don't care about the SDPs in the additional responses...

Maybe we can recommend that, once the UAS has sent the SDP answer in a reliable response, it should not include it in additional responses for the same transaction. But, the UAC still has to be able to handle cases where the additional responses do contain SDP.

Regards,

Christer

                      Thanks,
                      Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 07:39:05 +0200

Hi, 

>To be honest, your agree almost all of your reply. And I once have the same understanding of RFC3261. 
>But when I reviewed again during the interworking-testing(in new interworking-testing, we always face some new equipment and hear some new understanding of RFC3261 from them), I feel it seams need correction. 

That is why we are working with the o/a draft, which hopefully will clarify things for people.

Regards,

Christer

	Thanks, 
	
	Gao 

	

	2010-04-15 22:59 

		收件人
		[email-masked] 
		抄送
		Christer Holmberg <[email-masked]>, "Somogyi, Gabor (NSN - HU/Budapest)" <[email-masked]>, OKUMURA Shinji <[email-masked]>, "[email-masked]" <[email-masked]> 
		主题
		Re: [Sipping] About offeranswer draft:

	inline

	

	
	                Thanks,
	                Paul

---

From: [email-masked]
Date: Fri, 16 Apr 2010 13:43:58 +0800

Hi,

But as we know, O/A draft is just for clarification, not for correction.

Thanks,

Gao

2010-04-16 13:39

收件人
"[email-masked]" <[email-masked]>, Paul Kyzivat 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [Sipping] About offeranswer draft:

Hi, 

That is why we are working with the o/a draft, which hopefully will 
clarify things for people.

Regards,

Christer

                 Thanks, 
 
                 Gao 

 

                 2010-04-15 22:59 

                                 收件人
                                 [email-masked] 
                                 抄送
                                 Christer Holmberg 
<[email-masked]>, "Somogyi, Gabor (NSN - HU/Budapest)" 
<[email-masked]>, OKUMURA Shinji <[email-masked]>, 
"[email-masked]" <[email-masked]> 
                                 主题
                                 Re: [Sipping] About offeranswer draft:

                 inline
 
                 [email-masked] wrote:
                 >  > >> Quite similarly to 3PCC cases, where 200 contains 
the offer and 
                 > ACK the
                 >  > The rule we have agreed to is very simple: at most 
one offer/answer
                 >  > exchange per SIP transaction.
                 > 
 
                 I think you are arguing that it is "lawful" for the UAS 
to send
                 differing values for the SDP successive unreliable 
responses and in the
                 subsequent reliable response. And that it is then the 
responsibility of
                 the UAC to make this work "right" and "deterministically" 
by honoring
                 the first and ignoring the subsequent ones. Is that 
right?
 
                 But that makes no sense. The UAS cannot know if the UAC 
will receive the
                 first, or any of, the unreliable responses. So if it were 
to do this odd
                 behavior it must be satisfied that *any* of then are the 
one that the
                 UAC uses. Or else it must be assuming that the UAC 
*might* use one or
                 more of the unreliable ones, and eventually *switch* to 
the one in the
                 reliable response.
 
                 But 3261 is clear that the UAC should use the first one 
it receives, and
                 ignore the remainder, *including* the reliable one. There 
is no
                 provision for *switching*.
 
                 Hence, its a corollary that the only behavior that the 
UAC can follow
                 that is valid and consistent in the face of loss of 
unreliable responses
                 is for them all to contain the same SDP. So that is the 
*lawful*
                 behavior - a UAS that violates this is unreasonable.
 
                                 Thanks,
                                 Paul 

                 --------------------------------------------------------
                 ZTE Information Security Notice: The information 
contained in this mail is solely property of the sender's organization. 
This mail communication is confidential. Recipients named above are 
obligated to maintain secrecy and are not permitted to disclose the 
contents of this communication to others.
                 This email and any files transmitted with it are 
confidential and intended solely for the use of the individual or entity 
to whom they are addressed. If you have received this email in error 
please notify the originator of the message. Any views expressed in this 
message are those of the individual sender.
                 This message has been scanned for viruses and Spam by ZTE 
Anti-Spam system.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 07:47:18 +0200

So, what is it actually that you want to correct?

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: 16. huhtikuuta 2010 8:44
To: Christer Holmberg
Cc: Paul Kyzivat; [email-masked]
Subject: RE: [Sipping] About offeranswer draft:

Hi,

Thanks,

Gao

2010-04-16 13:39

收件人
"[email-masked]" <[email-masked]>, Paul Kyzivat <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [Sipping] About offeranswer draft:

Hi,

Regards,

Christer

                Thanks,

                Gao

                2010-04-15 22:59

                                 收件人
                                 [email-masked]
                                 抄送

                inline

                                Thanks,
                                Paul

---

From: [email-masked]
Date: Fri, 16 Apr 2010 13:48:35 +0800

Please see 
http://www.ietf.org/mail-archive/web/sipping/current/msg17552.html

2010-04-16 13:47

收件人
"[email-masked]" <[email-masked]>
抄送
Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [Sipping] About offeranswer draft:

Hi, 

Thanks, 

Gao 

收件人

Hi, 

Regards,

Christer

                Thanks, 
 
                Gao 

 

                2010-04-15 22:59 

                                 收件人
                                 [email-masked] 
                                 抄送
                                 Christer Holmberg 

                inline
 
the offer and 
one offer/answer
                > While how UAC handle SDP(from UAS) before the real 
answer, it can be BCP 
 
                I think you are arguing that it is "lawful" for the UAS to 
send
 
                UAC uses. Or else it must be assuming that the UAC *might* 
use one or
 
                But 3261 is clear that the UAC should use the first one it 
receives, and
                ignore the remainder, *including* the reliable one. There 
is no
                provision for *switching*.
 
                Hence, its a corollary that the only behavior that the UAC 
can follow
                that is valid and consistent in the face of loss of 
unreliable responses
                is for them all to contain the same SDP. So that is the 
*lawful*
                behavior - a UAS that violates this is unreasonable.
 
                                Thanks,
                                Paul 

                --------------------------------------------------------
                ZTE Information Security Notice: The information contained 
in this mail is solely property of the sender's organization. This mail 
communication is confidential. Recipients named above are obligated to 
maintain secrecy and are not permitted to disclose the contents of this 
communication to others.
                This email and any files transmitted with it are 
confidential and intended solely for the use of the individual or entity 
to whom they are addressed. If you have received this email in error 
please notify the originator of the message. Any views expressed in this 
message are those of the individual sender.
                This message has been scanned for viruses and Spam by ZTE 
Anti-Spam system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 08:24:33 +0200

Hi,

I think you need to separate things.

Since the SDP in the unreliable and reliable responses shall be the same, the UAC should not have to look at the SDP in the reliable response, if it is already "using" the SDP from an unreliable answer.

However, even if the UAC is using the SDP from an unreliable response, the UAC can not initiate a new offer/answer transaction before it has received the reliable response, because the reliable response terminates the offer/answer transaction.

So, just because the UAC is using an SDP from an unrelaible response, it doesn't mean that the offer/answer transaction is finished.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: 16. huhtikuuta 2010 8:49
To: Christer Holmberg
Cc: Paul Kyzivat; [email-masked]
Subject: 答复: RE: [Sipping] About offeranswer draft:

Please see http://www.ietf.org/mail-archive/web/sipping/current/msg17552.html

2010-04-16 13:47

收件人

Hi,

Thanks,

Gao

2010-04-16 13:39

收件人

Hi,

Regards,

Christer

               Thanks,

               Gao

               2010-04-15 22:59

                                收件人
                                [email-masked]
                                抄送

               inline

                               Thanks,
                               Paul

---

From: [email-masked]
Date: Fri, 16 Apr 2010 14:44:48 +0800

Hi,

Christer Holmberg <[email-masked]> 写于 2010-04-16 
14:24:33:

> Since the SDP in the unreliable and reliable responses shall be the 
> same, the UAC should not have to look at the SDP in the reliable 
> response, if it is already "using" the SDP from an unreliable answer.
> 
> However, even if the UAC is using the SDP from an unreliable 
> response, the UAC can not initiate a new offer/answer transaction 
> before it has received the reliable response, because the reliable 
> response terminates the offer/answer transaction.

[Gao] I know it well.
But RFC3261 said UAC MUST treat the SDP(which we think should not be the 
ANSWER, at most treat it as if answer) as answer.

During interworking testing, the other side's people said it is answer, 
then it(the UAC) has finished it's Ini-O/A, what's  normative text can you 
use to convince them?

So, first we should correct RFC3261 clearly that the SDP in unreliable 
response is not ANSWER, even it is the first SDP UAC got. 

Until finishing of the correction, we *MAY* do BCP thing on the handling 
of such SDP. And about BCP, I think there still are two alternative:
1. as O/A draft says, such SDP MUST be the same as the subsequent real 
answer. And UAC MUST using it AS IF answer.

2. Do not do such MUST/MUST NOT restrict, just let UAC's free to handle 
the SDP. If the UAC use it, OK; just ignore it, also OK. But the UAC MUST 
handle the real ANSWER as answer.

Thanks,

Gao

> 
> So, just because the UAC is using an SDP from an unrelaible 
> response, it doesn't mean that the offer/answer transaction is finished.
> 
> Regards,
> 
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 09:00:43 +0200

Hi,
 
>But RFC3261 said UAC MUST treat the SDP(which we think should not be the ANSWER, at most treat it as if answer) as answer. 
>	
>During interworking testing, the other side's people said it is answer, then it(the UAC) has finished it's Ini-O/A, what's  normative text can you use to convince them? 

You tell them that an offer/answer transaction is not finished until the answer has been delivered reliably.

>So, first we should correct RFC3261 clearly that the SDP in unreliable response is not ANSWER, even it is the first SDP UAC got. 

Could you please show the text in 3261 which says that the SDP in an unreliable response is the SDP answer?

>Until finishing of the correction, we *MAY* do BCP thing on the handling of such SDP. And about BCP, I think there still are two alternative: 
>1. as O/A draft says, such SDP MUST be the same as the subsequent real answer. And UAC MUST using it AS IF answer. 

Since it has to be the same, it doesn't really matter which the UAC uses. But still, the offer/answer transaction is not finished until the SDP has been received reliably.
	
>2. Do not do such MUST/MUST NOT restrict, just let UAC's free to handle the SDP. If the UAC use it, OK; just ignore it, also OK. But the UAC MUST handle the real ANSWER as answer. 

I am not really sure what you mean, but I am the first one to agree that offer/answer, and usage of SDP in SIP, is a big mess. We use SIP message to carry SDP, mix together session control and media control, but there is not always a one-to-one mapping between SIP transactions and offer/answer exchanges, and therefor we need to define rules on what you can insert where, etc.

Regards,

Christer

---

From: [email-masked]
Date: Fri, 16 Apr 2010 15:06:45 +0800

15:00:43:

> >But RFC3261 said UAC MUST treat the SDP(which we think should not 
> be the ANSWER, at most treat it as if answer) as answer. 
> > 
> >During interworking testing, the other side's people said it is 
> answer, then it(the UAC) has finished it's Ini-O/A, what's 
> normative text can you use to convince them? 
> 
> >So, first we should correct RFC3261 clearly that the SDP in 
> unreliable response is not ANSWER, even it is the first SDP UAC got. 
> 

[Gao]: text from RFC3261:

And, considering UAS send SDP in unreliable response before the answer, 
then the SDP would be the the first session
         description it receives.

RFC3261 using the word "AS THE ANSWER", not as if. 

> 
> >Until finishing of the correction, we *MAY* do BCP thing on the 
> handling of such SDP. And about BCP, I think there still are two 
alternative: 
> >1. as O/A draft says, such SDP MUST be the same as the subsequent 
> real answer. And UAC MUST using it AS IF answer. 
> 
> Since it has to be the same, it doesn't really matter which the UAC 
> uses. But still, the offer/answer transaction is not finished until 
> the SDP has been received reliably.
> 
> >2. Do not do such MUST/MUST NOT restrict, just let UAC's free to 
> handle the SDP. If the UAC use it, OK; just ignore it, also OK. But 
> the UAC MUST handle the real ANSWER as answer. 
> 
> I am not really sure what you mean, but I am the first one to agree 
> that offer/answer, and usage of SDP in SIP, is a big mess. We use 
> SIP message to carry SDP, mix together session control and media 
> control, but there is not always a one-to-one mapping between SIP 
> transactions and offer/answer exchanges, and therefor we need to 
> define rules on what you can insert where, etc.
> 
> Regards,
> 
> Christer
> 
> 
>    > 
>    > Please see http://www.ietf.org/mail-
> archive/web/sipping/current/msg17552.html
>    > 
>    ZTE Information Security Notice: The information contained in 
> this mail is solely property of the sender's organization. This mail
system.

---

From: Eric wang <[email-masked]>
Date: Fri, 16 Apr 2010 11:32:24 +0800

HI Christer
    inlines

2010/4/16 Christer Holmberg <[email-masked]>

> Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a
> SDP in an unreliable 18x. But, it is not the "official" SDP answer.
>
> And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the
> reliable answer is then different, the UAC should consider it as a protocol
> error in my opinion - not do any "switching".
>

I think UAC should consider SDP in reliable response as the correct one and
listen to it.
I don't konw why unreliable 18x with SDP be considered as answer if
received, I will be appreciate if someone tell my why.It seems like for
purpose as precondition, if I'm right, I recommand use reliable 18x with SDP
for precondition and treat SDP in reliable response as answer that should be
used finally(I konw it's violate rfc3261).

> What is complicated in "There can be only one SDP answer per transaction,
> and it comes in the first reliable response of that transaction"?

I mean, It's complicated if SDPs in reliable responses should be
ingored(treated as neither offer nor answer), because UAC has already
received answer SDP in either reliable or unreliable response.
I support no SDP in reliable responses should be ignored, we should trust
*reliable*.

> UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs
Yes!

> The 18x still belongs to the INVITE transaction, and may contain the
> previous SDP answer. But, since you have already received an SDP answer for
> the INVITE transaction, the SDP in the new 18x it has no meaning - no matter
> if there are UPDATE(s) or not...
>
>

BR,
Eric

> >     [email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>> 写于
>  >     2010-04-12 10:55:47:
> >      >
> >      >> Hi Gao,
> >      >>
> >      >> [email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >> >[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >> >抄送
> >      >> >
> >      >> >主题
> >      >> >[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >> >>发件人:  [email-masked]<mailto:[email-masked]
> >
> >      >> >>[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >> >>抄送
> >      >> >>
> >      >> >>主题
> >      >> >>[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >> >>>[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >      >> >>>抄送
> >      >> >>>
> >      >> >>>主题
> >      >> >>>[email-masked]<mailto:[email-masked]> <mailto:
> [email-masked]<mailto:[email-masked]>>
> >     <mailto:[email-masked]<mailto:
> [email-masked]>> for questions on current sip
> >     Use [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:
> [email-masked]>> for new developments of core SIP
> >
> >
> >
> > Use [email-masked]<mailto:
> [email-masked]> for questions on current sip

---

From: Eric wang <[email-masked]>
Date: Fri, 16 Apr 2010 14:45:28 +0800

HI Christer ,

> Yes, and I think that is what at least me and Paul have been trying to say.
> But, after you've received the answer in one reliable answer, it can't be
> updated in another reliable answer.

Eric: Agree. And It's better another reliable answer doesn't exist.

> received, I will be appreciate if someone tell my why.
>
> It will NOT be considered as answer. Sometimes we talk about it as a
> "preview of the answer". Whatever the UAC does with it is unspecified
> (unless you use ICE, where the unreliable SDP actually IS used - but it is
> still not considered as answer).
>

Eric: If it is a "preview of the answer", I think the negotiation should be
like precondition, not SDP in unreliable response.
I prefer the SDP in unreliable response can used for something else, eg, the
CALLED want to send CALLER a music while alerting.

> responses have to be the same.

Eric:  I'd be glad if  you can explain why they should be the same.

> I don't understand how it would make anything harder. Once you've received
> an SDP answer in a reliable response, you simply don't care about the SDPs
> in the additional responses...
>

Eric: I meant harder, not cannot:)
If meaningless SDPs are allowed, as a B2BUA server, we should distinguish
the meaning SDP from meaningless, should recognize if the SDP in reliable
18x is a new offer, when this happened in a
complex service such as Call Transfer, meaningless SDPs will make the
implementation more complex.

>
>
> Maybe we can recommend that, once the UAS has sent the SDP answer in a
> reliable response, it should not include it in additional responses for the
> same transaction. But, the UAC still has to be able to handle cases where
> the additional responses do contain SDP.
>

Eric: I suppose so. Then the UAC may just return an error to UAS, I think.

BR
Eric

               在 2010年4月14日 下午10:02，Paul Kyzivat <[email-masked]<mailto:
[email-masked]>>写道：

               IMO this makes no sense. For one thing, the UAC is instructed
to accept
               the first and ignore the rest, so sending differing values
will have no
               utility. For another, this only affects where the UAS will
receive media
               - it can have no effect on where the UAC receives media.
Generally the
               UAC isn't transmitting until the call is established, so what
is the point.

               > the SIP is never SI(m)P(le) again!"

               Where have you been? SIP hasn't been simple since early in
the century.

                     Thanks,
                     Paul

               > 2010/4/14 OKUMURA Shinji <[email-masked]
<mailto:[email-masked]>

current O/A

               >      >[email-masked]<mailto:
[email-masked]> <mailto:[email-masked]<mailto:
[email-masked]>> 写于

               >      >> |   descriptions in the unreliable responses to the
INVITE
               >     request must
have reached

RFC3261 said
               >     UAS may send
               >      >> >the same SDP before the answer, but there is not
normative
               >     words of to
unless we using
               >      >> >OKUMURA Shinji <[email-masked]
<mailto:[email-masked]>

               >      >> >发件人:  [email-masked]<mailto:
[email-masked]> <mailto:[email-masked]<mailto:
[email-masked]>>

               >      >> >>By myself, I am OK with the three ways. But if
there's no
               >     normative
fight for
               >      >> >>OKUMURA Shinji <[email-masked]
<mailto:[email-masked]>

confirms the

three ways,
the session
               >     as it is the
               >      >> >>>lawful answer. Using early media by the SDP
prior to the
               >     lawful answer is
               >      >> >>>So, I think using or just discarding the SDP
prior to the
               >     lawful answer is
"change to the SDP
               >      >> >>>OKUMURA Shinji <[email-masked]
<mailto:[email-masked]>

               >      >> >>>>While considering one problem in our
production's
               >     interoperability
draft and find
               >      >> >>>>   For example, in Figure 1, only the SDP in F6
is the
               >     answer.  The SDP
preview of the
 Receiving F2, the
response is
have different
UAS may send
response. And I
considering
difference might
address or port,
streams, it would
don't know that
               >     whether
               >      >> >>>>allowing different SDP(compare with the answer)
in
               >     non-reliable response
the answer
back to UAC
specification,
INVITE.  That
               >     same exact
               >      >> >>>>         answer MAY also be placed in any
provisional
               >     responses sent
treat the first
               >     session
               >      >> >>>>         description it receives as the answer,
and MUST
               >     ignore any
responses to the
               >     Use [email-masked]<mailto:
[email-masked]>

               >     Use [email-masked]<mailto:[email-masked]> <mailto:
[email-masked]<mailto:[email-masked]>> for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 18:14:28 -0400

I think we are now down to the essence of the question:

[email-masked] wrote:

>          answer MAY also be placed *in any provisional responses sent*
> *         prior to the answer*.  The UAC *MUST *treat *the first session*
> *         description it receives as the answer*, and MUST ignore any
> then the SDP would be the *the first session*
> *         description it receives*.
> 

At this point, we are arguing about the *intent* of the text - it is
clearly confusing to some people.

And AFAIK we (me, Gao, Shinji, and Christer) are all in agreement that
the intent of the existing text is that:

- *if* the UAC receives SDP in an unreliable response before
  receiving it in a reliable response, it MUST begin to use it
  in the same way that it would use it if that SDP had been
  received in a reliable response,

- but that it is not officially "the answer", and so it is not
  yet permissible to initiate another o/a exchange until a reliable
  response containing "the answer" is received.

- but when "the answer" is received, it MUST be ignored
  (rather than "used") if an earlier SDP has already been
  received and so "treated as the answer".

Are *we* all in agreement that this is the one and only *intended*
meaning of the text?

Then the issue is that *someone else* (who Gao has had occasion to do
interop testing with) is claiming that there is a different, yet
legitimate, interpretation of the exiting text. Namely:

- *if* the UAC receives SDP in an unreliable response before
  receiving it in a reliable response, it MUST begin to use it
  in the same way that it would use it if it had been received
  in a reliable response,

- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
  and hence it MAY send another offer, even before receiving
  another copy of that answer SDP in a *reliable* response.

- still it MUST ignore SDP in subsequent responses to the
  INVITE.

If so, then the question comes down to:

Is this alternate interpretation a valid and legitimate interpretation
of the existing text, or not?

I agree that this is a fair question to ask, and I am not yet settled on
an answer to it.

I am approaching this in the manner of a mathematical proof by
contradiction: If this alternative interpretation leads to some sort of
inconsistency, then it is not valid. If we can find no inconsistencies,
then it is a valid interpretation. And if it is, then the text is
ambiguous and will require normative changes to fix.

So, we can either seek out such an inconsistency, OR we can simply
concede that the text is ambiguous and begin work on a normative
correction to address it.

I'm pretty sure that we are going to reach the same endpoint either way.
So its a matter of whether we need a normative document to convince
everyone or not.

I'd appreciate feedback on my logic above.

	Thank you,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 18:22:36 -0400

inline, with some trimming

Eric wang wrote:
> Hi Paul,
> inlines.
> 
>  
> On Thu, Apr 15, 2010 at 10:42 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Eric - inline
> 
>     Eric wang wrote:
> 
>         HI,
>            inlines.
> 
>         BR.
>         2010/4/15 <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
> 
> 
>            Paul Kyzivat <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> 写于
> 
>            2010-04-14 22:12:48:
> 
> 
>             >
>             >
>             > >       > > RFC3261: "...MUST ignore any session
>         descriptions in subsequent
>             > > responses..."
>             > > you are speaking about several answers with 1 matching
>         offer.
>            That is a
>             > > fundamental difference.
>             >
>     I think you may be talking about cases where the call has been
>     forked to different destinations, and the distinct answers are
>     coming from them. Is that right?
> 
> responses with SDP can also establish early dialog for tone/announcement 
> and do nothing with offer/answer negotiation between the caller and the 
> called. 

Well, if you agree it violates 3261 then lets stop talking.
You can do lots of non-conforming things that are simple and useful. But
 doing them results in interoperability problems.

And I will assert that you can achieve what you wish in a conforming way
simply by having those separate servers use a distinct to-tag for their
response, thus creating distinct early dialogs. The UAC will then
understand them for what they are - responses from different entities -
and can decide how to render them with that understanding.

>     Because in that case the responses should have different to-tags,
>     thus becoming distinct (early) dialogs. The discussion we are having
>     is about what happens in a *single* dialog. And in a single dialog
>     the behavior you describe is *wrong*.
> 

Shinji was using that as an example of *invalid* usage, for the purpose
of discussing how the UAC might react to such invalid usage.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 18:48:35 -0400

Too many messages - it would be insane to reply to them all.
This reply is generally to several of Eric's prior messages in this
thread and the discussion about them.

IIUC, eric doesn't like SDP in unreliable responses.
But such usage is still very common. There are many deployments that
don't use PRACK at all. So implementations must be prepared for this.
When reliable provisionals are *not* used, providing "a preview" (my
terminology for this) in unreliable provisionals is very valuable,
because it allows the media streams to get started sooner than if the
UAC had to wait for the 200. So the UAC has much incentive to honor the
SDP in an unreliable provisional in order to get the media going.

(The 3261 text says the UAC MUST honor the SDP in the reliable
provisional if it receives it. But if it chose not to honor it, it could
simply claim that it was lost somewhere along the way, maybe after the
network interface on its box. And who can argue?)

Even when the UAC has included Supported:100_rel in the INVITE, there is
no guarantee that the UAS supports it, or is willing to use it. So still
in this case the UAC has strong motivation to honor the SDP in an
unreliable provisional.

Support for reliable provisionals has to be consistent with all of the
above. It provides *additional* behavior options - it removes none of
the above. (Unless the UAC specifies Required:100_rel. Lets not talk
about that case now.)

A nicely behaved UAS that is intending to use reliable provisionals will
probably not ever send an unreliable provisional containing SDP. In that
case Eric will be happy. But that is not *required* behavior. Maybe it
should have been, but since it was not, it would now be harder to go
back and fix than it is to simply cope with it. So we carefully specify
what is meant if SDP is received in an unreliable provisional and then
again in a reliable provisional.

That's my take on this particular discussion.

	Thanks,
	Paul

Eric wang wrote:
> HI Christer ,
>  
> 
> 
>  
> 2010/4/16 Christer Holmberg <[email-masked] 
> <mailto:[email-masked]>>
> 
> 
>     Hi,
> 
> 
>      >>Anyway, I don't anyone has said that it is "forbidden" for a UAC
>     to use a SDP in an unreliable 18x. But, it is not the "official" SDP
>     answer.
>      >>
>      >>And, if the UAC uses the SDP in the unreliable 18x, and the SDP
>     in the reliable answer is then different, the UAC should consider it
>     as a protocol error in my opinion - not do any "switching".
>      >
>      >
>      >
>     Yes, and I think that is what at least me and Paul have been trying
>     to say. But, after you've received the answer in one reliable
>     answer, it can't be updated in another reliable answer.
> 
>  
>      >I don't konw why unreliable 18x with SDP be considered as answer
>     if received, I will be appreciate if someone tell my why.
> 
>     "preview of the answer". Whatever the UAC does with it is
>     unspecified (unless you use ICE, where the unreliable SDP actually
>     IS used - but it is still not considered as answer).
> 
>  
> Eric: If it is a "preview of the answer", I think the negotiation should 
> be like precondition, not SDP in unreliable response.
> I prefer the SDP in unreliable response can used for something else, eg, 
> the CALLED want to send CALLER a music while alerting.
>  
>  
> 
> 
> 
>     transaction, and it comes in the first reliable response of that
>     transaction"?
>      >
>     ingored(treated as neither offer nor answer), because UAC has
>     already received answer SDP in either reliable or unreliable response.
>     is after UPDATEs.There must be some rules >saying "NO".I prefer
>     several reliable 18xs with SDP appear only in fork.
>      >The 18x still belongs to the INVITE transaction, and may contain
>     the previous SDP answer. But, since you have already received an SDP
>     answer for the INVITE transaction, the SDP in the new 18x it has no
>     meaning - no matter
>     I don't understand how it would make anything harder. Once you've
>     received an SDP answer in a reliable response, you simply don't care
>     about the SDPs in the additional responses...
> 
>  
> If meaningless SDPs are allowed, as a B2BUA server, we 
> should distinguish the meaning SDP from meaningless, should recognize if 
> the SDP in reliable 18x is a new offer, when this happened in a
>     Maybe we can recommend that, once the UAS has sent the SDP answer in
>     a reliable response, it should not include it in additional
>     responses for the same transaction. But, the UAC still has to be
>     able to handle cases where the additional responses do contain SDP.
> 
>  
> <[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>写道：
> 
> 
> 
>                Eric wang wrote:
>                > Hi all,
>                >
> <mailto:[email-masked]><mailto:[email-masked] 
>                > <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>>
> 
>                >
>                >     Hi Gao,
>                >
>                >     In the following case,
>                >
>                >          UAC                   UAS
>                >     (Rc4)   should treat SDP4 as the answer and confirm 
> the current O/A
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>> 写于
> 
>                >     2010-04-12 10:55:47:
>                >      >
>                >      >> Hi Gao,
>                >      >>
>                >      >> |   descriptions in the unreliable responses to 
> the INVITE
>                >     request must
>                >      >[Gao] I am not want to *challenge* the consensus 
> we have reached
>                >     in WG.
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >But the UAS do not think it throws the 
> problem. RFC3261 said
>                >     UAS may send
>                >      >> >the same SDP before the answer, but there is 
> not normative
>                >     words of to
> <mailto:[email-masked]><mailto:[email-masked] 
>                >     <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>>
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >2010-04-09 16:30
>                >      >> >
>                >      >> >收件人
> 
>                >      >> >[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >抄送
>                >      >> >
>                >      >> >主题
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>By myself, I am OK with the three ways. But 
> if there's no
>                >     normative
>                >      >> >>definition here, there would be some 
> interworking fight for
>                >     this issue.
>                >      >> >>
>                >      >> >>Thanks,
>                >      >> >>
>                >      >> >>Gao
>                >      >> >>
> <mailto:[email-masked]><mailto:[email-masked] 
>                >     <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>>
> 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>
> 
>                >     <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>2010-04-09 14:23
>                >      >> >>
>                >      >> >>收件人
> 
>                >      >> >>[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>抄送
>                >      >> >>
>                >      >> >>主题
>                >      >> >>4. In case 2 or 3, it is recommended that the 
> UAC confirms the
>                >     current
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>>Yes, considering implementation, I also find 
> the three ways,
>                >     especially
>                >      >> >>>for the last two ways.
>                >      >> >>>
>                >      >> >>>In fact, I think by rules, the UAC should 
> modify the session
>                >     as it is the
> <mailto:[email-masked]><mailto:[email-masked] 
>                >     <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>>
> 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>
> 
>                >     <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>>2010-04-09 10:13
>                >      >> >>>
>                >      >> >>>收件人
> 
>                >      >> >>>[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>>抄送
>                >      >> >>>
>                >      >> >>>主题
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>>
> 
>                >      >> >>>>testing, I re-read some parts of 
> offeranswer draft and find
>                >     something
>                >      >> >>>>   For example, in Figure 1, only the SDP 
> in F6 is the
>                >     answer.  The SDP
>                >      >> >>>>[Gao] In fact, UAS sending SDP in 
> non-reliable response is
>                >     for potential
>                >      >> >>>>early media channel and the final session, 
> some UAS may send
>                >     different
>                >      >> >>>>SDP(compare with the answer) in 
> non-reliable response. And I
>                >     really found
>                >      >> >>>>such equipment inside and outside of ZTE. 
> And considering
>                >     UAC, Ithink we
>                >      >> >>>>And I re-read correlative part of RFC3261. 
> I don't know that
>                >     whether
>                >      >> >>>>allowing different SDP(compare with the 
> answer) in
>                >     non-reliable response
>                >      >> >>>>      o  If the initial offer is in an 
> INVITE, the answer
>                >     MUST be in a
>                >      >> >>>>         reliable non-failure message from 
> UAS back to UAC
>                >     which is
>                >      >> >>>>         correlated to that INVITE.  For 
> this specification,
>                >     that is
>                >      >> >>>>         only the final 2xx response to 
> that INVITE.  That
>                >     same exact
>                >      >> >>>>         description it receives as the 
> answer, and MUST
>                >     ignore any
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>
> 
>                >     <mailto:[email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>> for questions on current sip
>                >     Use [email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> 
> <mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>>> for new developments of core SIP
> 
>                >
>                >
>                >
>                > 
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> for questions on current sip
> 
>                > Use [email-masked] 
> <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> for new 
> developments of core SIP
> 
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 19:05:31 -0400

Inline.

[email-masked] wrote:
> But in your case, UAC would have a indeterminate early media, depending 
> on which SDP is the one it first receives.

Yes, finally using the SDP in the first reliable response *would* make
this case determinate. However, that has consequences - one of the
following:

- if the SDP from an unreliable response is used initially,
  and then a different SDP from a reliable response is received,
  there will be need to "switch" from the earlier to the later.
  This switching (and even parsing of the SDP) is extra cost
  that is unnecessary if the UAS behaves correctly and does not
  change the SDP.

- the SDP from the unreliable responses might be ignored, so as
  to avoid the need to switch. Instead simply wait for the reliable
  response. For one, this is not permitted by the exiting text
  (though it can be achieved by pretending to lose the unreliable
  responses.) More important, this will delay the setup and use of
  the media streams. This can be unacceptable.

All this is simply to provide determinacy for a non-conforming UAS. We
usually don't specify behavior in non-conforming cases. Rather we leave
it to implementations to decide.

> I don't catch this point. Could you say it more.

My point was that the interpretation that permits the UAS to send
changed values of the SDP in unreliable provisionals and then the
reliable response leads to indeterminacy. Its nonsensical to believe the
spec intended to be indeterminate here. So the interpretation is not a
valid one. Rather, it should be excluded, leaving only the
interpretation that the UAS MUST send the same SDP in unreliable
responses and the subsequent reliable response.

But I have in another message confronted yet another interpretation you
apparently obtained from someone you deal with. Lets cap off this thread
here and pick it up in that one.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 19:16:10 -0400

>> responses sent prior to the answer." means it adequately for me.

I think this is again getting into the realm of "how should the UAC 
behave if the UAS is non-conforming?"

We are not obligated to clarify that at all, though we *may* provide a 
suggestion if it seems important.

But I am opposed to expecting the UAC to detect the non-conformance in 
order to take specific remedial action. I think that is what "should UAC 
refresh the media plane by the real answer" is talking about.

*If* the UAC detects this non-conformance (the indeterminacy), then it 
*could* attempt to remedy it by "refreshing the media plane". But there 
may be indeterminacy that has not been detected. I guess that too could 
be remedied by doing an extra O/A to "refresh". But that would increase 
the number of messages in cases when there is no indeterminacy at all. 
And if the refresh were attempted using a reINVITE, it could simply lead 
to yet another indeterminacy.

So I prefer to say nothing about the "refresh" in this draft.

	Thanks,
	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 16 Apr 2010 23:25:34 -0700

Inline...

> I agree that this is a fair question to ask, and I am not yet settled on

Sure, it's fair to ask but IMHO it's wrong. The second clause in your 
first list above (saying SDP in an unreliable response is not the 
"official" answer) is not just an opinion. 3261 says:

Seems pretty clear: SDP in the unreliable response is to be *treated as* 
the answer although (based on the first sentence) it isn't actually the 
answer. Elsewhere it is said that the SDP can't change from unreliable 
to reliable response so you could say that the unreliable SDP *might as 
well* have been the answer. In my view that doesn't change the fact that 
the official answer is the one in the first reliable response.

So I agree with "we" and I see no need for any fixes.

Thanks,
Anders

---

From: Brett Tate <[email-masked]>
Date: Sat, 17 Apr 2010 09:26:31 -0700

Yes.

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 19 Apr 2010 13:59:45 +0900

Hi Paul,

You say in another message,
>  received and so "treated as the answer".

I agree this is the one and only *intended* meaning of
the text.

Regards,
Shinji

Paul Kyzivat <[email-masked]>
Fri, 16 Apr 2010 19:16:10 -0400

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 19 Apr 2010 18:07:05 +0900

Hi Paul,

Paul Kyzivat <[email-masked]>
Fri, 16 Apr 2010 18:14:28 -0400
>Are *we* all in agreement that this is the one and only *intended*

I agree.
And then

- UAS MAY include the same SDP as the answer into
  any provisional responses before sending the answer.

- UAS MUST NOT include the different SDP from the answer into
  any provisional responses before sending the answer.

- UAS MUST NOT include the any SDP into any provisional
  responses after sending the answer.

we agree all of the above, don't we?

>ambiguous and will require normative changes to fix.

Even though I do not have the conviction to fill the
precondition of the proof by contradiction...

At that time if UAC sends an UPDATE with new offer, UAS probably
rejects it with 500 response.

Is it a contradiction?

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 11:20:52 +0200

Hi,

Do we really need 3 bullets to say that all SDPs included in the responses have to be the same???

Wording like "different SDP from the answer into before sending the answer" is also very confusing.

Why not simply say something like:

- A UAS MAY insert a SDP body that is identfical to the SDP answer, in a response before and after the SDP answer has been sent. The UAS MUST NOT insert a SDP body that is not identical to the SDP answer.

Regards,

Christer 

> Sent: 19. huhtikuuta 2010 12:07
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Is SDP in an unreliable response "the 
> answer" ???
> 
> Hi Paul,
> 
> >>  > Could you please show the text in 3261 which says that 
> the SDP in 
> >> an  > unreliable response is the SDP answer?
> >> 
> specification, that is
> >> And, considering UAS send SDP in unreliable response before the 
> >> answer, then the SDP would be the *the first session*
> >I agree that this is a fair question to ask, and I am not 
> yet settled 
> >on an answer to it.
> >
> At that time if UAC sends an UPDATE with new offer, UAS 
> probably rejects it with 500 response.
> 
> Is it a contradiction?
> 
> Regards,
> Shinji
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 19 Apr 2010 20:16:25 +0900

Christer,

I wanted to describe the condition strictly.
But my wording was not strict and not simple. I'm sorry.

However IMO we need 3 statements.

- An UAS MAY insert a SDP body that is identical to the SDP
  answer, in an unreliable provisional response before the SDP
  answer has been sent.

- The UAS MUST NOT insert a SDP body that is not identical to
  the SDP answer, in an unreliable provisional response before
  the SDP answer has been sent.

- The UAS MUST NOT insert a SDP body in any response after the
  SDP answer has been sent.

Regards,
Shinji

Christer Holmberg <[email-masked]>
Mon, 19 Apr 2010 11:20:52 +0200
>- A UAS MAY insert a SDP body that is identfical to the SDP answer, in a response before and after the SDP answer has been 
>sent. The UAS MUST NOT insert a SDP body that is not identical to the SDP answer.
>
>Regards,
>
>Christer 
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 13:32:12 +0200

Hi, 

>   SDP answer has been sent.

I don't think we can have the last bullet as MUST NOT, because there are implementations doing it, and I don't think there is any existing specification which forbids it. 

Regards,

Christer

> Christer Holmberg <[email-masked]> Mon, 19 
> Apr 2010 11:20:52 +0200
> >
> >Hi,
> >
> >Wording like "different SDP from the answer into before 
> sending the answer" is also very confusing.
> >
> >- A UAS MAY insert a SDP body that is identfical to the SDP 
> answer, in 
> >a response before and after the SDP answer has been sent. 
> The UAS MUST NOT insert a SDP body that is not identical to 
> the SDP answer.
> >
> >Regards,
> >
> >Christer
> >
> >> Subject: Re: [Sipping] Is SDP in an unreliable response 
> "the answer" 
> >> ???
> >> 
> >> Hi Paul,
> >> 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> >> 
> >[email-masked] for questions on current sip Use 
> >[email-masked] for new developments of core SIP

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 19 Apr 2010 20:50:18 +0900

Christer,

I don't intend to be strongly particular about the last "MUST NOT".

But RFC3261 say,
      o  Once the UAS has sent or received an answer to the initial

What do the above statements forbid?

Regards,
Shinji

Christer Holmberg <[email-masked]>
Mon, 19 Apr 2010 13:32:12 +0200
>I don't think we can have the last bullet as MUST NOT, because there are implementations doing it, and I don't think there is 
>any existing specification which forbids it. 
>
>Regards,
>
>Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 13:55:26 +0200

Hi,

The text talks about generating additional offers, but not about including a copy of previously sent ones.

Regards,

Christer 

> Sent: 19. huhtikuuta 2010 14:50
> To: [email-masked]
> Apr 2010 13:32:12 +0200
> >I don't think we can have the last bullet as MUST NOT, because there 
> >are implementations doing it, and I don't think there is any 
> existing specification which forbids it.
> >
> >Regards,
> >
> >Christer
> >
> >
> Apr 2010 
> >> 11:20:52 +0200
> >> The UAS MUST NOT insert a SDP body that is not identical 
> to the SDP 
> >> answer.
> >> >
> >> >Regards,
> >> >
> >> >Christer
> >> >

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 19 Apr 2010 13:55:41 +0200

>  the SDP answer has been sent.
This is terribly confusing. Very probabe that noone will get it right.
Triple negation. And talking about sending and answer before  the
answer has been sent. ???

>  SDP answer has been sent.
This means that you can't send it again after you've send it in an
unreliable provisional response. Do you want tto say that?

/Hans Erik van Elburg

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 15:09:10 +0200

Hi,

I'm afraid we're over-engineering this whole thing, and we'll end up with something which is even more complicated than what we are trying to clarify :)

Regards,

Christer 

> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 19. huhtikuuta 2010 14:56
> To: OKUMURA Shinji
> Cc: [email-masked]
> Triple negation. And talking about sending and answer before  
> the answer has been sent. ???
> 
> 
> This means that you can't send it again after you've send it 
> in an unreliable provisional response. Do you want tto say that?
> 
> /Hans Erik van Elburg

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2010 10:26:37 -0400

> ambiguous and will require normative changes to fix.

I have now found the contradiction I was looking for:

If the UAC thought that receipt of the unreliable response with SDP 
meant it could now send another offer, in what message could it send 
that offer? The only messages where it could include an offer are:

- an INVITE. But it is forbidden from sending another INVITE until
   the current INVITE transaction is complete.

- an UPDATE. But RFC 3311 says

       o  If the UPDATE is being sent before completion of the initial
          INVITE transaction, and the initial INVITE contained an offer,
          the UPDATE can contain an offer if the callee generated an
          answer in a reliable provisional response, and the caller has
          received answers to any other offers it sent in either PRACK or
          UPDATE, and has generated answers for any offers it received in
          an UPDATE from the callee.

   (note that this language itself is non-normative and is justified as
   a corollary of 3261.)

   This rules out sending the new offer in an UPDATE.

- a PRACK. But a PRACK can only be sent in response to a reliable
   provisional. The assumption here is that the answer has not been sent
   in a reliable provisional yet. So the PRACK would only be an option
   if a reliable provisional *without* SDP was sent after sending an
   answer in an unreliable provisional. This is a very weird case.

- in a response. But the only case where an offer is permitted in a
   response is in the response to INVITE, which isn't a possibility here.

I think the above is enough to debunk this interpretation.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2010 10:36:09 -0400

Christer,

There are multiple things to do here:

1) decide what is correct

2) explain what is correct in a way that is understandable
    to implementors and testers.

3) explain *why* it is correct, based on the existing RFCs,
    in sufficient precision to convince the doubters.

What is in this mail thread is a combination of the three.

The draft needs to address both (2) and (3). But if it is organized 
carefully, the part addressing (3) which is probably the most confusing 
part, can perhaps be segregated from (2) which is the part most readers 
will be interested in.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 19 Apr 2010 09:40:19 -0500

>   answer in an unreliable provisional. This is a very weird case.

Is this even allowed? I would think that once an answer has been sent in
an unreliable provisional response, the identical answer MUST be
included in (at least) the first reliable provisional response if one is
sent. Allowing any sort of reliable response that does not contain an
identical copy of the answer that was sent in an unreliable response
seems like a recipe for disaster.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Brett Tate <[email-masked]>
Date: Mon, 19 Apr 2010 07:54:08 -0700

> What do the above statements forbid?

Very little since from UAC perspective, the SDP MUST be ignored.  Thus if UAS places a modified SDP within a subsequent response, it isn't an offer SDP or an updated answer SDP.

---

From: Brett Tate <[email-masked]>
Date: Mon, 19 Apr 2010 10:51:56 -0700

> I'm afraid we're over-engineering this whole thing, and we'll 
> end up with something which is even more complicated than what 
> we are trying to clarify :)

I agree.  I think that the complication is less about the RFC ambiguity and more about vendors attempting to find ways to interop when some devices don't support (or disabled support of) the following: 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.

Devices which don't support the above 3 items usually need work-a-rounds which are not compliant to SIP's offer/answer rules.  Thus fixing potential RFC ambiguity does little to fix the real problem beyond highlighting that most/all of the work-a-rounds are non compliant or not desirable.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2010 14:14:18 -0400

> seems like a recipe for disaster.

Its hard to imagine why the UAS would do such an odd thing. But AFAIK it 
is not *forbidden* from sending a reliable provisional without the answer.

I don't see it as a recipe for disaster if the UAC is carefully 
constructed. But based on the range of behavior in the wild, I think 
this might have a high probability of working unpredictably.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2010 14:22:58 -0400

> I agree.  I think that the complication is less about the RFC ambiguity and more about vendors attempting to find ways to interop when some devices don't support (or disabled support of) the follow…

You may be right about this.

> Devices which don't support the above 3 items usually need work-a-rounds which are not compliant to SIP's offer/answer rules.  Thus fixing potential RFC ambiguity does little to fix the real proble…

I'm not sure what point you are making here.

In cases where implementations are doing the wrong thing because they 
don't understand what the right thing is, better specification of 
expected behavior will reduce the cases where work arounds are required. 
Of course it won't fix things immediately - only as implementations are 
corrected. It will certainly help in *disputes* about the correct behavior.

The cases where the existing text calls for things to be ignored, rather 
than checked, can actually facilitate interop where one end isn't quite 
right. But only for certain types of incorrectness.

	Thanks,	
	Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 19 Apr 2010 12:32:29 -0700

> > I agree.  I think that the complication is less about the RFC
> ambiguity and more about vendors attempting to find ways to interop
> when some devices don't support (or disabled support of) the following:
> 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.
> 
> > Devices which don't support the above 3 items usually need work-a-
> rounds which are not compliant to SIP's offer/answer rules.  Thus
> fixing potential RFC ambiguity does little to fix the real problem
> beyond highlighting that most/all of the work-a-rounds are non
> compliant or not desirable.
> 

I think that the real problem is that some devices don't support (or disable support of) the following: 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.  I was mainly just attempting to encourage vendors to support these 3 items so that all the non-complaint or not-desirable work-arounds can be deprecated more quickly.  However I doubt that the need for such work-arounds will go away any time soon.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 22:54:52 +0200

Hi,

>this might have a high probability of working unpredictably.

I agree. This is a problem I have seen over the years, and it's not only related to SDP: implementations make assumptions about the presence of information elements, even if the presence/non-presence is not required, and even if the implementation doesn't need the information for anything.

Now, we can always blame implementors for not reading the specs carefully enough, but the fact that we are working on the offer/answer clarification draft, and the re-INVITE clarification draft, shows that SDP offer/answer for SIP is a mess - and the CapNeg vulcano hasn't even erupted yet :)

Regards.

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 20 Apr 2010 15:11:36 +0900

Hi Christer, Brett,

This bullet might mean what you say.

Overall I can understand it. But reading the specs carefully,
I'm confused a little.

IMO The first statement in this bullet is not necessary, it is
the cause of trouble more than the explanation.

Lets get the discussion back to the 3rd bullet, I think it is
necessary, but "should not" is better than "MUST NOT".

Regards,
Shinji

Christer Holmberg <[email-masked]>
Mon, 19 Apr 2010 13:55:26 +0200
>The text talks about generating additional offers, but not
>about including a copy of previously sent ones.

Brett Tate <[email-masked]>
Mon, 19 Apr 2010 07:54:08 -0700
>Very little since from UAC perspective, the SDP MUST be ignored.
>Thus if UAS places a modified SDP within a subsequent response,
>it isn't an offer SDP or an updated answer SDP.

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 20 Apr 2010 17:42:34 +0900

Hi,

Before sending an answer,
- An UAS MAY send unreliable provisional responses with a SDP.
- And the SDP MUST be identical to an answer SDP.

After sending an answer,
- The UAS should not insert a SDP in any response.

Is this OK?

Hans Erik van Elburg <[email-masked]>
Mon, 19 Apr 2010 13:55:41 +0200

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Apr 2010 12:27:33 +0200

Hi,

>- The UAS should not insert a SDP in any response.

That text still doesn't say what an SDP inserted after sending the answer means, only that it should not be sent.

I still don't see why we need to make a separation about SDP sent before and after the answer, because in both cases the SDP must be identical to the answer.

And, again, I know there are many implementations that send a copy of the SDP after the SDP answer has been sent, so instead of saying that it should not be done I think it is much more important to say that, if it is done, it must be identical to the SDP answer. In other words, to make it clear that the UAS can not send a NEW offer (or updated answer) in a subsequent response after the SDP answer has been sent.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 20 Apr 2010 19:42:02 +0900

Brett,

I think nobody has been discussing on the assumption that UA
does not support those 3 items. (At least me, Gao, Paul)

Such workarounds is out of scope in this draft as you no doubt
know.

Regards,
Shinji

Brett Tate <[email-masked]>
Mon, 19 Apr 2010 12:32:29 -0700
>I think that the real problem is that some devices don't support
>(or disable support of) the following:
>I was mainly just attempting to encourage vendors to support
>these 3 items so that all the non-complaint or not-desirable
>work-arounds can be deprecated more quickly.  However I doubt
>that the need for such work-arounds will go away any time soon.

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 20 Apr 2010 20:36:40 +0900

Christer,

Christer Holmberg <[email-masked]>
Tue, 20 Apr 2010 12:27:33 +0200
>That text still doesn't say what an SDP inserted after sending
>the answer means, only that it should not be sent.

The SDP means nothing. it is neither an offer nor an answer.

>I still don't see why we need to make a separation about SDP
>sent before and after the answer, because in both cases the
>SDP must be identical to the answer.

1. RFC3261 says that UAS MAY send it before the answer and
   doesn't say nothing after the answer.
2. The SDP MUST be ignored by UAC. it is meaningless.
3. if another o/a exchange is occured (using UPDATE or PRACK),
   it is not even a confirmation.

>And, again, I know there are many implementations that send
>a copy of the SDP after the SDP answer has been sent, so
>instead of saying that it should not be done I think it is
>much more important to say that, if it is done, it must be
>identical to the SDP answer. In other words, to make it clear
>that the UAS can not send a NEW offer (or updated answer)
>in a subsequent response after the SDP answer has been sent.

Since UAC MUST ignored it, there is no problem on a interworking.
Why must it be identical to the SDP answer?

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Apr 2010 14:46:40 +0200

Hi, 

>>That text still doesn't say what an SDP inserted after sending the 
>>answer means, only that it should not be sent.
> 

Exactly. In my opinion that is what is important - not whether the UAS inserts SDP or not.
 
>>I still don't see why we need to make a separation about SDP sent 
>>before and after the answer, because in both cases the SDP must be 
>>identical to the answer.
> 

That is one reason why we are writing the draft - to clarify things which may not be clear in the specs.

>2. The SDP MUST be ignored by UAC. it is meaningless.

I agree, and that is what we must be clear about. Because, as we know, some people want to send a NEW offer (or updated answer) in a subsequent response, and that is not allowed.

>3. if another o/a exchange is occured (using UPDATE or PRACK), it is not even a confirmation.
> 
>a copy of the SDP after the SDP answer has been sent, so instead of 
>saying that it should not be done I think it is much more important to 
>say that, if it is done, it must be identical to the SDP answer. In other 
>words, to make it clear that the UAS can not send a NEW offer (or 
>updated answer) in a subsequent response after the SDP answer has been sent.
> 

Well, if you look at it that way, fine. But, then the important thing is that the UAC must ignore it - not that the UAS should not send it.

Regards,

Christer

> >Regards,
> >
> >Christer
> >
> >Hans Erik van Elburg <[email-masked]> Mon, 19 Apr 2010 
> >13:55:41 +0200
> >>> - An UAS MAY insert a SDP body that is identical to the 
> SDP  answer, 
> >>> in an unreliable provisional response before the SDP  answer has 
> >>> been sent.
> >>>
> >>> - The UAS MUST NOT insert a SDP body that is not 
> identical to  the 
> >>> SDP answer, in an unreliable provisional response before  the SDP 
> >>> answer has been sent.
> >>>
> >>> - The UAS MUST NOT insert a SDP body in any response 
> after the  SDP 
> >>> answer has been sent.
> >>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 20 Apr 2010 15:08:54 +0200

Do remember that there are certain cases where the UAC will not ignore it. These are the cases where the message containing original answer has not yet arrived or been lost, and the protocol has not yet recovered from that.

regards

Keith

> Sent: Tuesday, April 20, 2010 1:47 PM
> To: OKUMURA Shinji; [email-masked]
> That is one reason why we are writing the draft - to clarify 
> things which may not be clear in the specs.
> 
> I agree, and that is what we must be clear about. Because, as 
> we know, some people want to send a NEW offer (or updated 
> answer) in a subsequent response, and that is not allowed.
> 
> 
> a copy of 
> >the SDP after the SDP answer has been sent, so instead of 
> saying that 
> >it should not be done I think it is much more important to 
> say that, if 
> >it is done, it must be identical to the SDP answer. In other 
> words, to 
> >make it clear that the UAS can not send a NEW offer (or 
> updated answer) 
> Well, if you look at it that way, fine. But, then the 
> important thing is that the UAC must ignore it - not that the 
> UAS should not send it.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > >Regards,
> > >
> > >Christer
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Apr 2010 09:47:58 -0400

Here is my attempt at summarizing the discussion conclusions:

Normative things (stated or implied in existing RFCs):

- If the UAC sent an offer in the INVITE, then after it receives SDP 
(the answer) in a reliable response to the INVITE, any SDP in subsequent 
responses to the INVITE MUST be ignored.

- Further, if SDP is received in an unreliable response to the invite 
prior to receiving SDP in a reliable response, then it MUST be treated 
as the answer for purposes of media processing, but not for purposes of 
determining when another offer may be sent or received.

- if the UAS receives an offer in the INVITE, it MUST NOT include SDP in 
any response it sends until it has determined the intended answer SDP to 
the offer.

- once the intended answer SDP is determined, it MUST be sent in a 
reliable response to the INVITE. It MAY be sent in one or more 
*preceding* unreliable provisional responses.

Non-normative, best practice suggestions:

- if the UAS receives an offer in the invite, once it has sent the 
answer in a reliable response, it should not send any SDP in subsequent 
responses to the INVITE.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 20 Apr 2010 09:00:50 -0500

> answer in a reliable response, it should not send any SDP in subsequent

I think you've got it, yes.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Apr 2010 10:04:45 -0400

> Do remember that there are certain cases where the UAC will not ignore it. These are the cases where the message containing original answer has not yet arrived or been lost, and the protocol has no…

Hmm. Can you say more?

Are you thinking of a case where the answer has been sent in a reliable 
provisional, but the PRACK has not yet been received? And then that 
*some* SDP is included in a subsequent unreliable provisional, or 2xx?

That is an interesting case. The one that would be least wierd is:

	UAC                UAS
	 |  INVITE (SDP1)   |
	 |----------------->|
	 |  1xx REL (SDP2)  |
	 |   X--------------|
	 |  2xx (no SDP)    |
	 |<-----------------|

I think that implies a different best practice:

If the UAS has sent an answer in a reliable provisional, if it sends a 
2xx before receiving a prack of the answer, it should include the answer 
in the 2xx as well.

(If the UAS intends to initiate another o/a it MUST await the prack, so 
if the 1xx is lost it will be retransmitted.)

	Thanks,
	Paul

	 |                  |
	 |<-----------------|
	 |                  |
	 |                  |
	 |----------------->|
	 |                  |
	 |<-----------------|
	 |                  |
	 |                  |
	 |----------------->|
	 |                  |
	 |<-----------------|
	 |                  |
	 |                  |
	 |----------------->|
	 |                  |
	 |<-----------------|
	 |                  |
	 |                  |
	 |----------------->|
	 |                  |
	 |<-----------------|
	 |                  |

---

From: Brett Tate <[email-masked]>
Date: Tue, 20 Apr 2010 07:42:57 -0700

> I think nobody has been discussing on the assumption that 
> UA does not support those 3 items. (At least me, Gao, Paul)
> 
> Such workarounds is out of scope in this draft as you no 
> doubt know.

I agree.  However some of the workarounds are why a UAS does silly things like sending a modified SDP within 18x/2xx which must be ignored.  It allows a compliant UAC to ignore it while a non compliant UAC potentially treats it as an updated answer SDP (as a workaround for lack of support/use of 100rel, UPDATE, and/or forking) instead of sticking head in the sand until SIP's offer/answer rules allow for proper subsequent renegotiation.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 20 Apr 2010 17:55:42 +0200

Yep, thinking through this is probably the only case. I thought originally there might be some more.

So I guess this is just a minor justification for repeating the answer (unchanged) in subsequent messages, including the final response.

(It is also a reason against trying to implement changing it in subsequent messages, as there is no guarantee what order these will arrive in)

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, April 20, 2010 3:05 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; OKUMURA Shinji; [email-masked]
> > Do remember that there are certain cases where the UAC will 
> not ignore it. These are the cases where the message 
> containing original answer has not yet arrived or been lost, 
> and the protocol has not yet recovered from that.
> 
> Hmm. Can you say more?
> 
> Are you thinking of a case where the answer has been sent in 
> a reliable provisional, but the PRACK has not yet been 
> received? And then that
> If the UAS has sent an answer in a reliable provisional, if 
> it sends a 2xx before receiving a prack of the answer, it 
> should include the answer in the 2xx as well.
> 
> (If the UAS intends to initiate another o/a it MUST await the 
> prack, so if the 1xx is lost it will be retransmitted.)
> 
> 	Thanks,
> 	Paul
> 
> 
> 
> 
> 	 |                  |
> 	 |<-----------------|
> 	 |                  |
> 	 |                  |
> 	 |----------------->|
> 	 |                  |
> 	 |<-----------------|
> 	 |                  |
> 	 |                  |
> 	 |----------------->|
> 	 |                  |
> 	 |<-----------------|
> 	 |                  |
> 	 |                  |
> 	 |----------------->|
> 	 |                  |
> 	 |<-----------------|
> 	 |                  |
> 	 |                  |
> 	 |----------------->|
> 	 |                  |
> 	 |<-----------------|
> 	 |                  |
> 
> > regards
> > 
> > Keith
> > 
> >> That is one reason why we are writing the draft - to 
> clarify things 
> >> which may not be clear in the specs.
> >>
> >> I agree, and that is what we must be clear about. Because, as we 
> >> know, some people want to send a NEW offer (or updated
> important thing 
> >> is that the UAC must ignore it - not that the UAS should 
> not send it.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 20 Apr 2010 12:13:39 -0700

On 4/20/2010 7:04 AM, Paul Kyzivat wrote:
>> Do remember that there are certain cases where the UAC will not ignore
>> it. These are the cases where the message containing original answer
>> has not yet arrived or been lost, and the protocol has not yet
>> recovered from that.
>
> Hmm. Can you say more?
>

This is not a valid case. It's explicitly ruled out by 3262:

    If the UAS had placed a session description in any reliable
    provisional response that is unacknowledged when the INVITE is
    accepted, the UAS MUST delay sending the 2xx until the provisional
    response is acknowledged.  Otherwise, the reliability of the 1xx
    cannot be guaranteed, and reliability is needed for proper operation
    of the offer/answer exchange.

Thanks,
Anders

>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Christer Holmberg
>>> Subject: Re: [Sipping] Is SDP in an unreliable response "the answer" ???
>>>
>>>
>>> Hi,
>>> know, some people want to send a NEW offer (or updated answer) in a
>>> subsequent response, and that is not allowed.
>>>
>>>
>>> Well, if you look at it that way, fine. But, then the important thing
>>> is that the UAC must ignore it - not that the UAS should not send it.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 20 Apr 2010 21:53:17 +0200

On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <[email-masked]> wrote:
> - If the UAC sent an offer in the INVITE, then after it receives SDP (the
> answer) in a reliable response to the INVITE, any SDP in subsequent
> - Further, if SDP is received in an unreliable response to the invite prior
> to receiving SDP in a reliable response, then it MUST be treated as the
> answer for purposes of media processing, but not for purposes of determining
> when another offer may be sent or received.
>
[HE] I miss what the UAC should do in this case for subsequent
responses, does the following hold as well:
"If the UAC sent an offer in the INVITE, then after it receives SDP
(the answer) in an unreliable response to the INVITE, any SDP in
subsequent responses to the INVITE MUST be ignored/granted/... ." ?

Regardless what the correct behaviour is, it is missing in your summary.

> - if the UAS receives an offer in the INVITE, it MUST NOT include SDP in any
> response it sends until it has determined the intended answer SDP to the
> offer.
>
> - once the intended answer SDP is determined, it MUST be sent in a reliable
> response to the INVITE. It MAY be sent in one or more *preceding* unreliable
> provisional responses.
>
> - if the UAS receives an offer in the invite, once it has sent the answer in
> a reliable response, it should not send any SDP in subsequent responses to
> the INVITE.

---

From: [email-masked]
Date: Wed, 21 Apr 2010 09:36:19 +0800

Hi Paul,

Before I get back to this thread, I find there has been many discussion 
here.

Please see inlines.

Thanks,

Gao

Paul Kyzivat <[email-masked]> 写于 2010-04-17 06:14:28:

> >  > Could you please show the text in 3261 which says that the SDP in 
an
> >  > unreliable response is the SDP answer?
> > 
answer, 

[Gao] Yes.

> I agree that this is a fair question to ask, and I am not yet settled on

[Gao] Mee too.

> ambiguous and will require normative changes to fix.

[Gao] Yes. And thanks for your ratiocination.

> correction to address it.

[Gao] I suggest do inconsistency analysis first, to avoid normative 
correction if it is unnecessary.

---

From: [email-masked]
Date: Wed, 21 Apr 2010 10:26:06 +0800

Hi Paul,

Please see inlines.

Thanks,

Gao

[Gao] Yes.

> determining when another offer may be sent or received.

[Gao] Mee too. But I am not sure the clarification of this part "but not 
for purposes of 
determining when another offer may be sent or received".

IMO, permissibility of sending another Offer is signalling relating issue. 
So, I guess it might be better to saying "finishing of the ini-O/A 
transaction". 

Then, does the clarfication of receiving SDP in an unreliable response(to 
the invite prior to receiving SDP in a reliable response) not "finishing 
of the ini-O/A transaction" need normative correction or not? I am not 
sure about this point.

> the offer.

[Gao] Yes, it can avoid sending different SDP in reliable and unreliable 
response.

[Gao] Yes.

[Gao] Yes.

---

From: [email-masked]
Date: Wed, 21 Apr 2010 11:17:15 +0800

Hi Paul,

I still think UAS MUST NOT send the copy of SDP in any response after the 
ini-O/A.

By RFC3262:
The UAS MAY send a final response to the initial request before
   having received PRACKs for all unacknowledged reliable provisional
   responses, unless the final response is 2xx and any of the
   unacknowledged reliable provisional responses contained a session
   description.  In that case, it MUST NOT send a final response until
   those provisional responses are acknowledged. 

If the 1xx REL has SDP and the final response is 2xx, UAS MUST wait it get 
the PRACK, that is the UAC MUST has gotten the 1xx REL.

Thanks,

Gao

[email-masked] 写于 2010-04-20 22:04:45:

> > Do remember that there are certain cases where the UAC will not 
> ignore it. These are the cases where the message containing original
> answer has not yet arrived or been lost, and the protocol has not 
> yet recovered from that.
> 
> Hmm. Can you say more?
>

---

From: [email-masked]
Date: Wed, 21 Apr 2010 11:18:43 +0800

Yes. There's another description in RFC3262 has the same meaning:

> >> Do remember that there are certain cases where the UAC will not 
ignore

---

From: [email-masked]
Date: Wed, 21 Apr 2010 11:34:03 +0800

Hi Paul,

I also attempted to do the same search. Thanks for your exposure.

By the finding, we CAN say that the problem is not a urgent one, as such 
implementation is not lawful.

But as I said in one previous mail, permissibility of sending another 
Offer is signalling relating issue. So, whether it is the mark of 
"finishing of the ini-O/A transaction" is still not clear. But it has been 
downgraded as pure academic issue now(by your finding, there's no 
engineering issue nowadays).

Thanks,

Gao

---

From: [email-masked]
Date: Wed, 21 Apr 2010 11:58:04 +0800

Using Paul's classify, I think this one is the point. From the long 
thread, *we* are almost have the same attitude towards the current RFCs. 

But facing with doubters, we really need sufficient and precise 
clarification for some dark points.

Thanks,

Gao

[email-masked] 写于 2010-04-20 03:32:29:

> I think that the real problem is that some devices don't support (or
> disable support of) the following: 1) interactions with forking 
> proxies, 2) rfc3262, or 3) rfc3311.  I was mainly just attempting to
> encourage vendors to support these 3 items so that all the non-
> complaint or not-desirable work-arounds can be deprecated more 
> quickly.  However I doubt that the need for such work-arounds will 
> go away any time soon.
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 21 Apr 2010 14:15:04 +0900

Paul,

Paul Kyzivat <[email-masked]>
Tue, 20 Apr 2010 09:47:58 -0400
>*preceding* unreliable provisional responses.

I agree. But I think one more sentence is necessary.
- And the SDP in a *preceding* unreliable provisional responses
  to the INVITE MUST be identical to an answer SDP.

>answer in a reliable response, it should not send any SDP in subsequent 

I agree. And I add one more reason why it is necessary.

4. To avoid misunderstanding that UAS is sending new offer.

Regards,
Shinji

>> I agree, and that is what we must be clear about. Because,
>> as we know, some people want to send a NEW offer (or updated
>> Well, if you look at it that way, fine. But, then the important
>> thing is that the UAC must ignore it - not that the UAS should
>> not send it.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>>> - An UAS MAY insert a SDP body that is identical to the SDP  answer, 
>>>>>> - The UAS MUST NOT insert a SDP body that is not identical to  the 
>>>>>> - The UAS MUST NOT insert a SDP body in any response after the  SDP 
>>>>>> answer has been sent.
>>>>>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 21 Apr 2010 14:44:47 +0900

Hi,

Hans Erik van Elburg <[email-masked]>
Tue, 20 Apr 2010 21:53:17 +0200
>subsequent responses to the INVITE MUST be ignored/granted/... ." ?

I agree. And it's certainly "ignored".

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 12:23:39 +0200

Hi,

<Dean Willis hat on>

Offer/answer is a mess. Instead, let's regard media as an application on top of SIP, and use an Info Package for negotiating the media. There is no connection to the SIP transactions, which means we don't need complicated rules on when and where to insert SDP, and we don't need to describe how offer/answer works for re-INVITEs etc.

<Dean Willis hat off>

I don't disagree with what people are saying, but trying to read it from a I-am-a-new-implementor-and-I-would-like-to-get-it-right-from-the-beginning perspective I don't think anything is clarified. Eg. talking about that an SDP sent after the answer would be "missunderstood as a new offer" is confusing. The important thing is not whether the UAS includes the UAS answer in subsequent responses or not, because the UAC still has to handle such situation. What is important is that the UAS MUST NOT send a *new* offer.

Regards,

Christer

> Sent: 21. huhtikuuta 2010 8:45
> To: [email-masked]
> Hans Erik van Elburg <[email-masked]> Tue, 20 Apr 
> 2010 21:53:17 +0200
> >> (the
> >> prior to receiving SDP in a reliable response, then it MUST be 
> >> treated as the answer for purposes of media processing, 
> but not for 
> >> purposes of determining when another offer may be sent or received.
> >>
> >> - if the UAS receives an offer in the INVITE, it MUST NOT 
> include SDP 
> >> in any response it sends until it has determined the 
> intended answer 
> >> SDP to the offer.
> >>
> >> answer in a reliable response, it should not send any SDP in 
> >> subsequent responses to the INVITE.

---

From: [email-masked]
Date: Wed, 21 Apr 2010 18:33:43 +0800

Hi Christer,

What's the meaning of hat on/off? 

And why about Dean Willis?

Thanks,

Gao

2010-04-21 18:23

收件人
OKUMURA Shinji <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
Re: [Sipping] Is SDP in an unreliable response "the answer" ???

Hi,

<Dean Willis hat on>

Offer/answer is a mess. Instead, let's regard media as an application on 
top of SIP, and use an Info Package for negotiating the media. There is no 
connection to the SIP transactions, which means we don't need complicated 
rules on when and where to insert SDP, and we don't need to describe how 
offer/answer works for re-INVITEs etc.

<Dean Willis hat off>

I don't disagree with what people are saying, but trying to read it from a 
I-am-a-new-implementor-and-I-would-like-to-get-it-right-from-the-beginning 
perspective I don't think anything is clarified. Eg. talking about that an 
SDP sent after the answer would be "missunderstood as a new offer" is 
confusing. The important thing is not whether the UAS includes the UAS 
answer in subsequent responses or not, because the UAC still has to handle 
such situation. What is important is that the UAS MUST NOT send a *new* 
offer.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 12:51:07 +0200

Hi, 

>And why about Dean Willis? 

Don't worry about it - let's just try to clarify offer/answer :)

Regards,

Christer

	2010-04-21 18:23 

		收件人
		OKUMURA Shinji <[email-masked]>, "[email-masked]" <[email-masked]> 
		抄送
		
		主题

	Hi,
	
	<Dean Willis hat on>

	<Dean Willis hat off>

	Regards,
	
	Christer

---

From: [email-masked]
Date: Wed, 21 Apr 2010 19:21:50 +0800

[email-masked] 写于 2010-04-21 18:23:39:

> 
> Hi,
> 
> <Dean Willis hat on>
> 
> Offer/answer is a mess. Instead, let's regard media as an 
> application on top of SIP, and use an Info Package for negotiating 
> the media. There is no connection to the SIP transactions, which 
> means we don't need complicated rules on when and where to insert 
> SDP, and we don't need to describe how offer/answer works for re-INVITEs 
etc.
> <Dean Willis hat off>

As SIP is widely deployed, the radical way mentioned above is not proper. 
So, I prefer this moderate way.

> I don't disagree with what people are saying, but trying to read it 
> from a I-am-a-new-implementor-and-I-would-like-to-get-it-right-from-
> the-beginning perspective I don't think anything is clarified. Eg. 
> talking about that an SDP sent after the answer would be 
> "missunderstood as a new offer" is confusing. 

I guess "missunderstood as a new offer" issue is clear:
If the session-id of o= line is the same the ANSWER, UAC can treate it as 
just COPY of the answer; 
If the session-id is higher than the ANSWER's session-id, the UAC can 
treate it as *new* offer. As the UAC MUST ignore any SDP after ANSWER, it 
is OK for UAC doing nothing. But if UAC checks the SDP and find it is 
*new* offer and violation of O/A rules then terminate the session, I also 
think it is also OK(UAS do bad behavior at first).

>The important thing is
> not whether the UAS includes the UAS answer in subsequent responses 
> or not, because the UAC still has to handle such situation. 

IMO, UAC can just ignore any SDP from UAS after the ANSWER. So, the UAC 
MAY NOT has to handle it.

>What is 
> important is that the UAS MUST NOT send a *new* offer.

YES.

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 21 Apr 2010 20:38:57 +0900

Christer,

I understand that this is a very rare case,

        A                                 B
        |                                 |
        |INVITE (offer)                   |
        |================================>|
        |                  1xx-rel(answer)|
        |<===========\  /=================|
        |             \/                  |
        |             /\ 18x-norel(answer)|
        |<===========/  \=================|
        |PRACK                            |
        |-------------------------------->|
        |                                 |

IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert new
offer into PRACK.

To avoid this situation UAS should not ...

Regards,
Shinji

Christer Holmberg <[email-masked]>
Wed, 21 Apr 2010 12:23:39 +0200
>application on top of SIP, and use an Info Package for
>negotiating the media. There is no connection to the SIP
>transactions, which means we don't need complicated rules on
>when and where to insert SDP, and we don't need to describe
>how offer/answer works for re-INVITEs etc.
>
><Dean Willis hat off>
>
>I don't disagree with what people are saying, but trying to
>read it from a I-am-a-new-implementor-and-I-would-like-to-
>get-it-right-from-the-beginning perspective I don't think
>anything is clarified. Eg. talking about that an SDP sent
>after the answer would be "missunderstood as a new offer"
>is confusing. The important thing is not whether the UAS
>includes the UAS answer in subsequent responses or not,
>because the UAC still has to handle such situation.
>What is important is that the UAS MUST NOT send a *new* offer.
>
>Regards,
>
>Christer
>
>> Hans Erik van Elburg <[email-masked]> Tue, 20 Apr 2010 21:53:17 +0200
>> >> treated as the answer for purposes of media processing, but not for 
>> >> - if the UAS receives an offer in the INVITE, it MUST NOT include SDP 
>> >> in any response it sends until it has determined the intended answer 
>> >> SDP to the offer.
>> >>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 13:44:45 +0200

Hi, 

>	If the session-id of o= line is the same the ANSWER, UAC can treate it as just COPY of the answer; 
>	If the session-id is higher than the ANSWER's session-id, the UAC can treate it as *new* offer. As the UAC MUST ignore any SDP after ANSWER, it is OK for UAC doing nothing. But if UAC checks the SDP and find it is 
>	*new* offer and violation of O/A rules then terminate the session, I also think it is also OK(UAS do bad behavior at first). 

I am not talking about the UAC procedure. I fully support saying that the UAC ignores the SDP.

My problem is to say that the UAS shall not include SDP, because the UAC could "missunderstand it as a new offer". All we need to say is that the UAS MUST NOT include a new SDP.
	
Regards,

Christer

---

From: [email-masked]
Date: Wed, 21 Apr 2010 19:48:16 +0800

Hi,

Yes. As Paul's conclusion of BCP, UAS should not include SDP after sending 
the ANSWER.

My talking is , even UAS violate the BCP suggestion, there's no normative 
problem.

Thanks,

Gao

2010-04-21 19:44

收件人
"[email-masked]" <[email-masked]>
抄送
OKUMURA Shinji <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [Sipping] Is SDP in an unreliable response "the answer" ???

Hi, 

>                If the session-id of o= line is the same the ANSWER, UAC 
can treate it as just COPY of the answer; 
>                If the session-id is higher than the ANSWER's session-id, 
the UAC can treate it as *new* offer. As the UAC MUST ignore any SDP after 
ANSWER, it is OK for UAC doing nothing. But if UAC checks the SDP and find 
it is 
>                *new* offer and violation of O/A rules then terminate the 
session, I also think it is also OK(UAS do bad behavior at first). 

I am not talking about the UAC procedure. I fully support saying that the 
UAC ignores the SDP.

My problem is to say that the UAS shall not include SDP, because the UAC 
could "missunderstand it as a new offer". All we need to say is that the 
UAS MUST NOT include a new SDP.
 
Regards,

Christer

                 > > >> - If the UAC sent an offer in the INVITE, then 
after it 
                 > > receives SDP 
                 > > >> (the
                 > > >> answer) in a reliable response to the INVITE, any 
SDP in 
                 > > >> - Further, if SDP is received in an unreliable 
response to 
                 > > the invite 
                 > > >Regardless what the correct behaviour is, it is 
missing in 
                 > > your summary.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 13:55:15 +0200

Hi, 

>IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert 
>new offer into PRACK.

You now seem to be suggesting that an SDP answer can be transported unreliably. I strongly disagree to such statement.

A copy of the SDP answer can be sent unreliably, and the UAC can use it, but the "real" SDP answer must still be sent reliably.

Maybe "ignore" is the wrong wording. The UAC cannot ignore the fact that the reliable response contains the SDP answer, because THAT SDP finishes the offer/answer transaction, but it does not need to parse it.

Regards,

Christer

> Christer Holmberg <[email-masked]> Wed, 21 
> Apr 2010 12:23:39 +0200
> >Hi,
> >
> ><Dean Willis hat on>
> >
> application 
> >on top of SIP, and use an Info Package for negotiating the 
> media. There 
> >is no connection to the SIP transactions, which means we don't need 
> >complicated rules on when and where to insert SDP, and we 
> don't need to 
> >describe how offer/answer works for re-INVITEs etc.
> >
> ><Dean Willis hat off>
> >
> >from a I-am-a-new-implementor-and-I-would-like-to-
> anything is 
> >clarified. Eg. talking about that an SDP sent after the 
> answer would be 
> >"missunderstood as a new offer"
> includes the 
> >UAS answer in subsequent responses or not, because the UAC 
> still has to 
> >handle such situation.
> "the answer" ???
> >> >> - If the UAC sent an offer in the INVITE, then after it 
> receives 
> >> >> SDP (the
> >> >> answer) in a reliable response to the INVITE, any SDP in 
> >> >> subsequent responses to the INVITE MUST be ignored.
> >> >>
> >> >> - Further, if SDP is received in an unreliable response to the 
> >> >> invite prior to receiving SDP in a reliable response, 
> then it MUST 
> >> >> be treated as the answer for purposes of media 
> processing, but not 
> >> >> for purposes of determining when another offer may be 
> sent or received.
> >> >>
> >> >> - if the UAS receives an offer in the INVITE, it MUST 
> NOT include 
> >> >> SDP in any response it sends until it has determined 
> the intended 
> >> >> answer SDP to the offer.
> >> >>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 14:09:55 +0200

Hi, 
	
>Yes. As Paul's conclusion of BCP, UAS should not include SDP after sending the ANSWER. 
>	
>My talking is , even UAS violate the BCP suggestion, there's no normative problem. 

Exactly.

So, the important thing is to make clear, that IF the UAS sends SDP after sending the answer, it CAN NOT send a new offer.

Personally I have never seen any problems caused if there is SDPs in additional responses - since most applications will ignore them. 

The problem is when someone claims that the SDP can't be ignored, because it contains a new offer. And, again, THAT is what we need to clarify: the UAS cannot send a new offer.

Regards,

Christer

	2010-04-21 19:44 

		收件人
		"[email-masked]" <[email-masked]> 
		抄送
		OKUMURA Shinji <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
		主题
		RE: [Sipping] Is SDP in an unreliable response "the answer" ???

	Hi, 

	
	                
	Regards,
	
	Christer

---

From: [email-masked]
Date: Wed, 21 Apr 2010 20:08:09 +0800

Hi,

[email-masked] 写于 2010-04-21 19:55:15:

> You now seem to be suggesting that an SDP answer can be transported 
> unreliably. I strongly disagree to such statement.
> 
> A copy of the SDP answer can be sent unreliably, and the UAC can use
> it, but the "real" SDP answer must still be sent reliably.

I agree with Christer. And this is the same point we reached, even I think 
in some point, we need more proof.

> 
> Maybe "ignore" is the wrong wording. The UAC cannot ignore the fact 
> that the reliable response contains the SDP answer, because THAT SDP
> finishes the offer/answer transaction, but it does not need to parse it.

This is the point I talked in mail to Paul. I prefer the ini-O/A 
transaction finished until UAC get the answer in reliable response.

But, whether it(the SDP treated as answer in unreliable response) is the 
mark of "finishing of the ini-O/A transaction" is still not clear. But 
from engineering level, Paul has found proof that UAC and UAS can not send 
subsequent O/A using current defined request.

Thanks,

Gao

---

From: [email-masked]
Date: Wed, 21 Apr 2010 20:14:26 +0800

Christer Holmberg <[email-masked]> 写于 2010-04-21 
20:09:55:

> So, the important thing is to make clear, that IF the UAS sends SDP 
> after sending the answer, it CAN NOT send a new offer.
> 
> Personally I have never seen any problems caused if there is SDPs in
> additional responses - since most applications will ignore them. 
> 
> The problem is when someone claims that the SDP can't be ignored, 
> because it contains a new offer. And, again, THAT is what we need to
> clarify: the UAS cannot send a new offer.

Exactly. And I think RFC3261 has such words of the meaning: the UAS cannot 
send a new offer (in subsequent response):

         to the initial INVITE.

Thanks,

Gao

>       OKUMURA Shinji <[email-masked]>, "sipping@ietf.
> org" <[email-masked]>, "[email-masked]" <sipping-
> [email-masked]> 
>       主题
>    >> from a 
I-am-a-new-implementor-and-I-would-like-to-get-it-right-from-

>    >                 If the session-id of o= line is the same the 
> ANSWER, UAC can treate it as just COPY of the answer; 
>    >                 If the session-id is higher than the ANSWER's 
> session-id, the UAC can treate it as *new* offer. As the UAC MUST 
> ignore any SDP after ANSWER, it is OK for UAC doing nothing. But if 
> UAC checks the SDP and find it is 
>    >                 *new* offer and violation of O/A rules then 
> terminate the session, I also think it is also OK(UAS do bad 
> behavior at first). 
> 
>    My problem is to say that the UAS shall not include SDP, because 
> the UAC could "missunderstand it as a new offer". All we need to say
> is that the UAS MUST NOT include a new SDP.
> 
>    Regards,
> 
>    Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    > > >> - Further, if SDP is received in an 
> unreliable response to 
>                    > > the invite 
>                    > > >Regardless what the correct behaviour is, it
> is missing in 
>                    > > your summary.
>                    > > >
> contained in this mail is solely property of the sender's 
> organization. This mail communication is confidential. Recipients 
> named above are obligated to maintain secrecy and are not permitted 
> to disclose the contents of this communication to others.
> confidential and intended solely for the use of the individual or 
> entity to whom they are addressed. If you have received this email 
> in error please notify the originator of the message. Any views 
> expressed in this message are those of the individual sender.
system.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 21 Apr 2010 14:23:25 +0200

> A copy of the SDP answer can be sent unreliably, and the UAC can use it, but the "real" SDP answer must still be sent reliably.

If you say it like that, can a UAC ignore the "real" SDP answer, if it
received a precursor of the SDP answer in an unreliable response?

Imagining that I am such
I-am-a-new-implementor-and-I-would-like-to-get-it-right-from-the-beginning:
- What answer shall the UAC take if they are different?

I would expect that the rule be lenient on what you receive and be
strict in what you send out also applies here, so just killing the
session is not an option. Intuitively I would say take the "real"
answer as that is probably the best you can get?

/Hans Erik van Elburg

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 14:33:51 +0200

Hi, 

>>A copy of the SDP answer can be sent unreliably, and the 
>>UAC can use it, but the "real" SDP answer must still be sent reliably.
> 
>If you say it like that, can a UAC ignore the "real" SDP 
>answer, if it received a precursor of the SDP answer in an 
>unreliable response?

It depends on what we mean by "ignore".

It can ignore the SDP CONTENT, but it cannot ignore the fact that it now receives the SDP answer in a reliable response, that terminates the offer/answer transaction.

I know it sounds messy, and that's why I wouldn't like to say anything else than the SDP in a unrelaible resposne is a copy of the SDP answer - nothing more. It's a copy of the answer, the UAC can assume it is identical to the answer, but it is NOT the answer :)

As soon as we start talking about sending SDP answer in unreliable responses people may think that it finishes the offer/answer transaction, and then we need lots of text saying that is not the case... Confuses it does.

Regards,

Christer

---

From: [email-masked]
Date: Wed, 21 Apr 2010 20:52:24 +0800

Hi,

> - What answer shall the UAC take if they are different?

In engineering level, I know some UAC using the answer they treated as 
answer in unreliable response and DO not modify the media plane by the 
*real* answer. I think this is correct behavior under current RFC.

And some UAC do more. Some ones is lenient, and changing it's media plane 
by the *real* answer.(some even listen on both the two different answers). 

Some UACs is strict, after parsing the SDP, it termate the session.

ONLY the first behavior is normative. The second one is interesting, it is 
friendly(especially when UAC listen on both the answers), but real 
violation of normative text. The last one is violation of normative text, 
but it is UAS who violate normative text firstly.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Apr 2010 09:08:34 -0400

Anders,

Thanks for identifying this. I should have remembered.

So that is a case we don't have to cope with.

	THanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Apr 2010 09:22:15 -0400

> So, the important thing is to make clear, that IF the UAS sends SDP after sending the answer, it CAN NOT send a new offer.

There is a subtlety here. What you say is correct: the UAS *can not*
send a new offer, which is stronger than saying it *may not*. It matters
not whether it *thinks* it is sending an offer - it never will be an offer.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Apr 2010 09:34:53 -0400

>   to the INVITE MUST be identical to an answer SDP.

At first I thought your addition to be redundant.
But looking more closely, I guess it is not. My statements did not 
forbid sending sdp other than the answer.

I think there must be a better way to state these things.
But at least we are settling on the necessary behavior, and that it is 
already implicit in the existing RFCs.

	Thanks,	
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Apr 2010 09:39:28 -0400

Gao - inline...

[email-masked] wrote:
> IMO, permissibility of sending another Offer is signalling relating 
> issue. So, I guess it might be better to saying "finishing of the 
> ini-O/A transaction".

ok, I agree with that.

> Then, does the clarfication of receiving SDP in an unreliable 
> response(to the invite prior to receiving SDP in a reliable response) 
> not "finishing of the ini-O/A transaction" need normative correction or 
> not? I am not sure about this point.

IMO it does not. We have evidence of intent, even when lacking explicit
normative language, as well as proof that alternative interpretations do
not work. So I propose we call this settled, write it up as a
*clarification*, and declare victory.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 19:31:48 +0200

Hi,

>not whether it *thinks* it is sending an offer - it never will be an offer.

Correct. That's why "can not" is also better than "must not", since it is by definition not even technically possible to send a new offer.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2010 19:41:54 +0200

Hi,

>From my experience the 200 OK will NOT be delayed, and that might be one reason why people include the SDP answer in the 200 OK, even if it has been sent reliably earlier - at least if the response in which the SDP answer was sent has not been acknowledged when the 200 OK is to be sent.

I am not sure we would need to describe this, since the behavior breaks 3262. However, it does happen, and it is a reason why people include SDP in 200 OK, so maybe a Note could be useful? 

Regards,

Christer

---

From: [email-masked]
Date: Thu, 22 Apr 2010 08:40:56 +0800

Hi,

OK. Then, let's go head.

And I am looking forward to the new version of O/A text now :)

Thanks,

Gao

2010-04-21 21:39

收件人
[email-masked]
抄送
OKUMURA Shinji <[email-masked]>, "[email-masked]" 
<[email-masked]>, Christer Holmberg <[email-masked]>
主题
Re: [Sipping] Is SDP in an unreliable response "the answer" ???

Gao - inline...

>  > prior to receiving SDP in a reliable response, then it MUST be 
treated

ok, I agree with that.

                 Thanks,
                 Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 22 Apr 2010 12:40:05 +0900

Christer,

Christer Holmberg <[email-masked]>
Wed, 21 Apr 2010 13:55:15 +0200
>You now seem to be suggesting that an SDP answer can be
>transported unreliably. I strongly disagree to such statement.

NO. An SDP answer transported unreliably is only a "preview" of
the true answer.
I know it well.

>A copy of the SDP answer can be sent unreliably, and the UAC can
>use it, but the "real" SDP answer must still be sent reliably.
>
>Maybe "ignore" is the wrong wording. The UAC cannot ignore
>the fact that the reliable response contains the SDP answer,
>because THAT SDP finishes the offer/answer transaction,
>but it does not need to parse it.

That's right. "ignore" confuse me. Another clarification is
necessary.

If 18x-norel has no SDP, this confusion can not be occured.
Because offer/answer rules are complicated enough,
somening unnecessary should not exist.

It's "Best" Current Practices, I think.

Regards,
Shinji

>> >> >> invite prior to receiving SDP in a reliable response, then it MUST 
>> >> >> be treated as the answer for purposes of media processing, but not 
>> >> >> for purposes of determining when another offer may be sent or received.
>> >> >>
>> >> >> - if the UAS receives an offer in the INVITE, it MUST NOT include 
>> >> >> SDP in any response it sends until it has determined the intended 
>> >> >> answer SDP to the offer.
>> >> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Apr 2010 09:57:16 -0400

I agree with Shinji below. But there are three things going on in this 
draft:

- collecting together and clarifying the rules as they are,
   including various inferences that are not apparent to
   all readers.

- best practices wneh sending messages.
   If these best practices are followed, certain
   problems are avoided

- best practices when receiving messages.
   This helps address the problem situations that
   may arise if the sender is doing something
   *valid* but which does not follow the best
   practices for sending.

Having a best practice for sending that avoids a problem doesn't 
eliminate the value is documenting a best practice for coping with that 
problem.

	Thanks,
	Paul