On Wed, 2008-09-24 at 15:07 -0400, M. Ranganathan wrote: > I am working on testing against an ITSP. When I go to transfer a call > to our park server, I send a re-INVITE with no SDP. The endpoint on > the ITSP side returns the previously negotiated codec in the OK rather > than the list of codecs that it supports. In this case, it returns > G729 which is the codec that it negotiated on the initial call. Is > this a valid response. Does this mean that the ITSP simply does not > support codec renegotiation?
I think that it's valid, strictly speaking, but it's not the best practice, because it prevents the answerer from being able to choose among the possible codecs. The internet draft draft-ietf-sipping-sip-offeranswer-08 is in the queue to be published as an RFC. In it, it says: 5.2.2. Responding with an Offer when the Initial INVITE has no Offer When a UAS has received an initial INVITE without an offer, it must include an offer in the first reliable response to the INVITE. It has largely the same options as when sending an initial INVITE with an offer, but there are some differences. [...] In regard to an INVITE with an offer: 5.2.1. Sending an Initial INVITE with Offer When a UAC sends an initial INVITE with an offer, it has complete freedom to choose which media type(s) and media format(s) (payload types in the case of RTP) it should include in the offer. [...] Including all supported media formats will maximize the possibility that the other party will have a supported format in common. But including many can result in an unacceptably large SDP body. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
