Re: [Sipping] Hi Paul //About draft-ietf-sipping-sip-offeranswer-11

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

 





gao.yang2@xxxxxxxxxx wrote:

I just find a potential problem of draft-ietf-sipping-sip-offeranswer-11. I am not sure will you want have a new version, so I send this discussion offline.

I am working on another version. I am including sipping in my response so others have the opportunity to comment. (I trust that is ok.)

Section 5.2.5. of draft-ietf-sipping-sip-offeranswer-11:
When the new offer is sent in response to an offerless (re)INVITE,
   *all codecs supported by the UA are to be included*, not just the ones
   that were negotiated by previous offer/answer exchanges.  *The same is*
*   true for media types* - so if UA A initially offered audio and video
   to UA B, and they end up with only audio, and UA B sends an offerless
   (re)INVITE to UA A, A's resulting offer should re- attempt video, by
   reusing the zeroed m-line used previously.


While Re-INVITE without Offer:
For codecs, I think the UAS should include as many codecs that the UA is willing(section 14.2 of RFC3261) to support. I think we should let the UA has the right to decide which codecs can be use or not for this current call. At the same time, the UAS should be with responsibility for failure of session if it cut down the number of codecs. UAS's willing of codecs can be implemented as local policy or some other forms of configuration.

Yes, this just requires minor tweak to wording.
Its consistent with the recommendations on sendonly/...

For media types, it is almost the same as codecs, about UA's willing. But I think we should emphasize on avoiding of introducing new media types without user's permission, such as just introducing new media types by equipment or software. Beacause I have met such charging arguement from users in some operating telecom-network.(If you want the detail of the charging arguement, I'd like to share it with you). So, if there is no indication of permission of introducing new media types from the end user, UAS should just include current using media types. And if the other side(user of UAC) want to add media types, it can using another new Offer.

I get your point and agree. Its the same concept - include everything the UA would be willing to use, not just that which it thinks the peer wants to use.

	Thanks,
	Paul

Thanks,

Gao

Section 14.2 of RFC3261:
A UAS providing an offer in a 2xx (because the INVITE did not contain
   an offer) SHOULD construct the offer as if the UAS were making a
   brand new call, subject to the constraints of sending an offer that
   updates an existing session, as described in [13] in the case of SDP.
   Specifically, this means that it SHOULD include as many media formats
   and media types that the UA *is willing to support*.  The UAS MUST
   ensure that the session description overlaps with its previous
   session description in media formats, transports, or other parameters
   that require support from the peer.  This is to avoid the need for
the peer to reject the session description.
===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@xxxxxxxxxx
===================================

--------------------------------------------------------
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

[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