I should qualify this by saying that if the media is being implemented by the specific vendor as symetrical RTP (Sending to the remote host using the listening port as the source port), otherwise the source port could be some other random port, in the event that the vendor implements asymetrical RTP.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher A. Martin Sent: Wednesday, May 29, 2002 1:54 PM To: 'Medhavi Bhatia'; [EMAIL PROTECTED]; 'Toshihiko Maeda' Cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] SDP Description The source port (relative to which side of the intiation you are on) will be in the response, such as 200 ok, or in the case of early mediea for instance, in the 18x message...as examples. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Medhavi Bhatia Sent: Wednesday, May 29, 2002 12:40 PM To: [EMAIL PROTECTED]; Toshihiko Maeda Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] SDP Description 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 _______________________________________________ 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
