On 6/24/10 6:09 PM, Frank Shearar wrote: > On 2010/06/24 11:07, goutam kumar wrote: > >> Hi, >> >> I am trying to implement the offer-answer model as per RFC 3264. When I went >> through RFC 4317 to see the various scenarios of this negotiation I found >> this: >> >> " 2.2. Audio and Video 2 >> >> Alice can support PCMU, PCMA, and iLBC codecs, but not more than one >> at the same time. Alice offers all three to maximize chances of a >> successful exchange, and Bob accepts two of them. An audio-only >> session is established in the initial exchange between Alice and Bob, >> using either PCMU or PCMA codecs (payload type in RTP packet tells >> which is being used). Since Alice only supports one audio codec at a >> time, a second offer is made with just that one codec, to limit the >> codec choice to just one. >> >> [Offer] >> >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> m=audio 49170 RTP/AVP 0 8 97 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:97 iLBC/8000 >> m=video 51372 RTP/AVP 31 32 >> a=rtpmap:31 H261/90000 >> a=rtpmap:32 MPV/90000 >> [Answer] >> >> v=0 >> o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com >> s= >> c=IN IP4 host.biloxi.example.com >> t=0 0 >> m=audio 49172 RTP/AVP 0 8 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:8 PCMA/8000 >> m=video 0 RTP/AVP 31 >> a=rtpmap:31 H261/90000 >> >> [Second-Offer] >> >> v=0 >> o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> m=audio 51372 RTP/AVP 0 >> a=rtpmap:0 PCMU/8000 >> m=video 0 RTP/AVP 31 >> a=rtpmap:31 H261/90000 >> >> [Second-Answer] >> >> v=0 >> o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com >> s= >> c=IN IP4 host.biloxi.example.com >> t=0 0 >> m=audio 49172 RTP/AVP 0 >> a=rtpmap:0 PCMU/8000 >> m=video 0 RTP/AVP 31 >> a=rtpmap:31 H261/90000 >> >> " ----RFC 4317 >> >> My doubt is, whether its mandatory to send the second offer to ensure that >> media is exchanged using that codec. Can't we start sending media using PCMU >> (in this case) after receiving the first answer, since the list of codecs is >> already arranged according to preference in the offer and answer?? In case >> the second offer is not sent, what problems may arise during the call?? >> > Without the second offer, there's nothing stopping Bob from sending both > PCMU and another codec. Alice would then break. > > frank > ______________________________________________ > >
Even if Bob sent two codecs in the answer, Bob will end up only using one of the two (with an equal pledge that it would accept and decode what Alice would choose to send between the two). Whatever codec that is can be deduced via the payload type that Alice would receive and would be an unknown until the first rtp packet from Bob hits Alice. Alice not knowing what Bob would send in advance may send a reINVITE to ensure that what Bob would transmit in the session update request would be the same codec Alice would be sending to Bob to ensure synchronized codecs in rx and tx. Is the reINVITE mandatory? No it is not. Assuming Alice can't support non-synchronized codec, will Alice break if it did not send a reINVITE? It may or it may not since by mere probability, there is a 25% chance that both of them will be choosing the same codec. Joegen _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
