On Wed, Sep 24, 2008 at 3:57 PM, Dale Worley <[EMAIL PROTECTED]> wrote: > 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 > > >
If I send an ACK with no body when I see a 200 OK coming back from the iTSP in response to the RE-INIVITE previously sent to it, with SDP that does NOT include G711 ( which is what our park server wants ), what does that signify? sipXbridge re-INVITE ( no sdp ) ---> ITSP sipXbridge <---- ITSP ( OK G729 ) sipXbridge ----> ACK (no SDP) I ask because I have also come across another flavor of ITSP that sends me sipXbridge re-INVITE ( no sdp ) ---> ITSP sipXbridge <---- ITSP ( OK no SDP ) Which I assume is a protocol error (or is it?). Thanks. Ranga -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
