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
===================================
Zip : 210012
Tel : 87211
Tel2 :(+86)-025-52877211
e_mail : gao.yang2@xxxxxxxxxx
===================================
| OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2010-04-09 10:13 |
|
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
-------------------------------------------------------- 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
