Dear Dan, Thank you for your reply, #1, there is no method to specify the source port in SDP. And, they cannot know its number until the first packet are sent. So, what number client uses is based on its implementation, isn't it? (I think it use dynamic port usually)
BTW, the same mail are sent from others, please discard it. My co-worker sent it by mistake... Thanks, Toshihiko >From: <[EMAIL PROTECTED]> >To: Toshihiko Maeda <[EMAIL PROTECTED]> >CC: <[EMAIL PROTECTED]> >Subject: Re: [Sip-implementors] SDP Description >Date: Wed, 29 May 2002 18:03:34 +0300 (EEST) > > > > 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 _________________________________________________________________ ウィルスメール、迷惑メール対策なら MSN Hotmail http://www.hotmail.com/JA/ _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
