Re: [Sipping] About offeranswer draft:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry,

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

OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
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
>
>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, 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
>_______________________________________________
>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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux