Re: [Sipping] About offeranswer draft:

[gao.yang2@xxxxxxxxxx]

Hi Eric,

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

And some comments inlines.

Thanks,

Gao

sipping-bounces@xxxxxxxx 写于 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.
> So I believe different SDPs(compare with the
answer) can exist in 
> non-reliable response and final 2xx response.

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.

>  
> 
> 
>  
> 2010/4/14 OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
> 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
> 
> gao.yang2@xxxxxxxxxx
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >sipping-bounces@xxxxxxxx 写于 2010-04-12 10:55:47:
> >
> >> 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.
> >
> >[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*.
> >
> >>
> >> I'm confused.
> >> 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.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> gao.yang2@xxxxxxxxxx
> >> 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
> >> >
> >> >OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
> >> >发件人:  sipping-bounces@xxxxxxxx
> >> >2010-04-09 16:30
> >> >
> >> >收件人
> >> >sipping@xxxxxxxx
> >> >抄送
> >> >
> >> >主题
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >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
> >> >
> >> >gao.yang2@xxxxxxxxxx
> >> >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
> >> >>
> >> >>OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
> >> >>发件人:  sipping-bounces@xxxxxxxx
> >> >>2010-04-09 14:23
> >> >>
> >> >>收件人
> >> >>sipping@xxxxxxxx
> >> >>抄送
> >> >>
> >> >>主题
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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 ...
> >> >>>1. terminate the session.
> >> >>>2. keep using the SDP in a non-reliable response.
> >> >>>3. change to the SDP in a reliable response.
> >> >>
> >> >>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
> >> >>
> >> >>gao.yang2@xxxxxxxxxx
> >> >>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 
> earlymedia 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 <shinji.okumura@xxxxxxxxxxxx>
> >> >>>发件人:  sipping-bounces@xxxxxxxx
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>收件人
> >> >>>sipping@xxxxxxxx
> >> >>>抄送
> >> >>>
> >> >>>主题
> >> >>>Re: [Sipping] About offeranswer draft:
> >> >>>
> >> >>>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
> >> >>>
> >> >>>gao.yang2@xxxxxxxxxx
> >> >>>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
> >> >>>>   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, Ithink 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
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> Use sip@xxxxxxxx for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> Use sip@xxxxxxxx for new developments of core SIP
--------------------------------------------------------
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.

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP