Yeah.. that's the catch here. In case Alice dosent send the reINVITE to lock-down a particular codec, she has no way of knowing beforehand what RTP payload Bob will be sending. She would get that info only when the first RTP packet reaches her. So, should we start two decoders simultaneously after getting the answer from Bob or wait for the first rtp packet and then start the corresponding decoder by identifying the payload type??
I know this is a bit off-track but its a related doubt which needs to be sorted out before I implement any logic. Thanks for the help. Gotham On Thu, Jun 24, 2010 at 4:19 PM, Joegen E. Baclor <[email protected]>wrote: > 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 > -- Luv n Laf g...@m _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
