Goutam, After the Re-INVITE's offer/answer exchange there will be one one common codec that both Alice and Bob will agree upon. You need to start the decoder of that particular codec alone.And starting the coder/decoder beforehand or afterhand is truly implementors wish, I am not sure of the impacts on starting the coder/decore beforehand or afterhand.
Regards, Ayyanar -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of goutam kumar Sent: Thursday, June 24, 2010 4:56 PM To: [email protected] Cc: [email protected] Subject: Re: [Sip-implementors] SIP: deciding a particular codec inoffer-answer negotiation 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 Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
