> Dear folks, > > I hope this is correct to talk, > > #1) I would like to know how to determine the source port by SDP > negotiation. My understanding is; clients can specify a port they receive > RTP packet from by 'm' attribute. > > For example, > A : INVITE ... m=audio 49170 RTP/AVP 0 > B : 200 OK ... m=audio 50123 RTP/AVP 0 > > Then, <From A to B> > - source port of A : ??? > - destination port of B : 50123 > > <From B to A> > - source port of B : ??? > - destination port of A : 49170 > > In this case, how is each source port determined? In addition, are they > able to specify the port clearly with SDP description? > Source port is not included in SDP offers/answers. A receiver can learn the source port of the sender when it receives the first RTP packet from the sender and no sooner than that. The 'recvfrom()' function can fill a transport address structure with the transport address of the sender (source_ip+source_port).
NOTE: There is no constrait of sending on the port used for receiving. So, after SDP exchange (it is NOT a NEGOTIATION; a negotiation requires three steps) one cannot know the source port. > #2) How is information of 'packetization interval' exchanged in SDP? I > guess 'a=ptime' attribute can be used for it. Is this correct > understanding? If correct, then, how should the callee determine it if > there is no 'a=ptime' in description? 'a=ptime' may be used but, as you have noticed, it is not mandatory. The callee may try to include 'a=ptime' in its answer in order to force the caller to use the specified ptime when trasnmitting. But there is no warranty that the caller will interpret the ptime SDP line (again, ptime is not mandatory; it is suggested). Some of the RTP creators claim that a RTP implementation should be ptime independent. This is ok..this can be done. But if you want to know the RTP stream parameters (ptime/codec), in order to do bandwidth reservasion and QoS stuff, before the RTP flow starts... this cannot be easily done. So, they should consider ENFORCING ptime to MANDATORY, because assuring QoS is very important issue. And QoS for voice can be done if you can say 'I need X bytes at every Y miliseconds' BEFORE the RTP flow starts. If there are others who run into this problem, they should speak up. What is more important: being compatible with incomplete implementations or making a serious step towards QoS ? > > Any help is highly appreciated. > >Sincerely yours, Toshihiko Dan Firac, Software Engineer, Redline Communications, Romania. PS: should I add that H.245 really negotiates a fixed ptime? But I am sure there are good reasons not to this in SDP. If somebody knows them, please speak. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
