Re: About offeranswer draft:

OKUMURA Shinji <[email protected]> Thu, 15 Apr 2010 17:20:09 +0900
Newsgroups gmane.ietf.sipping
Message-ID <[email protected]>
Hi Eric,

Eric wang <[email protected]>
Thu, 15 Apr 2010 13:29:41 +0800
>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.

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

>BR
>Eric
>
>Paul Kyzivat wrote
>> 
>> 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.
>> > So I believe different SDPs(compare with the answer) can exist in
>> > non-reliable response and final 2xx response.
>> 
>> 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
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP