Just on the side, besides the source port, the source ip address is also unspecified in the SDP - so besides the src port being different, can the source ip also be different ?
----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Toshihiko Maeda" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 29, 2002 11:03 AM Subject: Re: [Sip-implementors] SDP Description > > > 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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
