On 6/24/10 7:25 PM, goutam kumar wrote: > 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] <mailto:[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 <http://host.atlanta.example.com/> > >> s= > >> c=IN IP4 host.atlanta.example.com > <http://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 <http://host.biloxi.example.com/> > >> s= > >> c=IN IP4 host.biloxi.example.com > <http://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 <http://host.atlanta.example.com/> > >> s= > >> c=IN IP4 host.atlanta.example.com > <http://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 <http://host.biloxi.example.com/> > >> s= > >> c=IN IP4 host.biloxi.example.com > <http://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] > <mailto:[email protected]> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >
If you are coding Alice' UA, you can always delay attachment of codec to the RTP stream until the first payload has been received. You do not need to pre-allocate the codec prior (which would require a bit more resource). In this case you do not need to reINVITE. This would ensure you better interoperability than relying on the reINVITE to pin down one specific codec. There are a lot of ITSPs that, although required by the RFC, do not support reINVITEs well. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
