4 Oct 2004 07:43
4 Oct 2004 10:38
RE: [Serdev] NAT traversal for RTP stream
Bernie Hoeneisen <bhoeneis <at> switch.ch>
2004-10-04 08:38:22 GMT
2004-10-04 08:38:22 GMT
Hi Linda! Have you tried to use the SER "mediaproxy" module instead of "nathelper"? This is an alternative implementaion for SER to overcome NAT problems, and it can handle more than one media line in an SDP. I use it mostly for audio/video sessions and it works just fine. cheers, Bernie On Fri, 24 Sep 2004, Linda Xiao wrote: > > Yes. This is the root cause. > > It seems that it is the limitation for nathelper. But nowadays, it is easy > to get multi-line media descriptions in SDP, even for a single media type > transmission. An example is for those UAs that support RFC3264. The line can > be divided by different ptime. > > Regards/Linda > > -----Original Message----- > From: Andrei Pelinescu-Onciul [mailto:pelinescu-onciul <at> fokus.fraunhofer.de] > Sent: Thursday, September 23, 2004 12:15 AM > To: Linda Xiao > Cc: 'sip-implementors <at> cs.columbia.edu'; 'serdev <at> iptel.org' > Subject: Re: [Serdev] NAT traversal for RTP stream > >(Continue reading)
4 Oct 2004 13:39
RFC 3857 - Is "all-resources" the only legal string?
Anat Angel <anatang <at> radvision.com>
2004-10-04 11:39:45 GMT
2004-10-04 11:39:45 GMT
Hi all, RFC 3857 states: "However, the Request URI can contain a URI that identifies any set of subscriptions, including the subscriptions to a larger collection of resources. For example, sip:all-resources <at> example.com might be defined within example.com to refer to all resources." Is "all-resources" the only string that can be used to indicate a set of subscriptions, or are there other strings? If so - what are they? Thanks in advance, Anat.
4 Oct 2004 13:57
Re: 'C' RTP stack
SiM <face2faceonlinux <at> yahoo.co.in>
2004-10-04 11:57:32 GMT
2004-10-04 11:57:32 GMT
Hi Vinod,
You can find some RTP stacks written in C here,
http://www.pernau.at/kd/voip/bookmarks-sip-rtp-ua.html
Hope that helps.
Cheers.
Simith
vinodk <vinodk <at> multitech.co.in> wrote:
Hello,
Please suggest me any good RTP stack which is written in C.
Thank you
Vinod Kagalkar
_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Yahoo! India Matrimony: Find your life partneronline.
4 Oct 2004 15:23
RFC 3857 - transient states definition.
Anat Angel <anatang <at> radvision.com>
2004-10-04 13:23:34 GMT
2004-10-04 13:23:34 GMT
Hi all, RFC 3857 states that in certain cases, watcherinfo notifications SHOULD NOT be sent for any transient states. Are there other cases of transient states besides the fetch operation that is given as an example in the RFC? Is there a definition somewhere of these transient states? And also - the RFC states that in the Fetch example, no notifications will be sent at all because all the states are transient. The meaning is that no notifications will be sent besides the full state Notify that is the result of the normal Fetch operation, right? Thanks in advance, Anat.
4 Oct 2004 17:06
Final response and overload
Cedric Barret <cedric.barret <at> ferma.fr>
2004-10-04 15:06:30 GMT
2004-10-04 15:06:30 GMT
Hi all, I am looking for the best non 200 final response a server should return in case of overload. I don't like very muche 500 Server Internal Error because it seems the server is out of service, whereas it just refuses some requests because the bandwith is limited for licensing reasons. I'd like to know the best practises in this case. Thanks in advance, Cédric.
4 Oct 2004 23:26
RFC 3265 Subscribe-Notify Question
Sachin Vidwans <sachinvidwans <at> gmail.com>
2004-10-04 21:26:31 GMT
2004-10-04 21:26:31 GMT
Hello Folks, I am new to the Subscribe/Notify RFC. Have a couple of questions. 1. The id parameter in the Event Header of the Subscribe message is optional. If a UA sends a SUBSCRIBE within an existing dialog without the id parameter. It then sends another SUBSCRIBE within the same dialog without an id parameter. Is the second subscribe considered a subscribe-refresh of the first subscribe. Or is this a new subscription within the same dialog. Or do we match the Event Header along with the id parameter to check if this is a subscribe-refresh or a new Suscribe? 2. If a notify request fails i.e. the response times out or it gets an error response, the subscription is removed. Does this also result in Dialog termination if appropriate ? (i.e no other subscriptions or INVITE requests prending etc.). Thank You. -- -- Have A Better One Sachin Vidwans Listen To The Color Of Your Dreams - John Lennon
5 Oct 2004 05:12
RE: Final response and overload
<srivastava.vivek <at> wipro.com>
2004-10-05 03:12:01 GMT
2004-10-05 03:12:01 GMT
Hi Cédric, In case of overload server can return 503(service unavailable) response with Retry-After header requesting client to retry after the time mentioned in Retry-After header. Vivek -----Original Message----- From: sip-implementors-bounces <at> cs.columbia.edu [mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Cedric Barret Sent: Monday, October 04, 2004 8:37 PM To: sip-implementors <at> cs.columbia.edu Subject: [Sip-implementors] Final response and overload Hi all, I am looking for the best non 200 final response a server should return in case of overload. I don't like very muche 500 Server Internal Error because it seems the server is out of service, whereas it just refuses some requests because the bandwith is limited for licensing reasons. I'd like to know the best practises in this case. Thanks in advance, Cédric.(Continue reading)
5 Oct 2004 14:03
RFC 3856 - Missing "Event" header in the example.
Anat Angel <anatang <at> radvision.com>
2004-10-05 12:03:47 GMT
2004-10-05 12:03:47 GMT
Hi All, I've noticed that in the example message flow in RFC 3856, the 200 response for the SUBSRIBE does not contain "Event:" header. In the last draft before changing status to RFC (draft-ietf-simple-presence-10) this header appeared. Can anyone tell me the reason for this change? Thanks in advance. Anat.
5 Oct 2004 15:33
RE: RFC 3856 - Missing "Event" header in the example.
Brett Tate <brett <at> broadsoft.com>
2004-10-05 13:33:10 GMT
2004-10-05 13:33:10 GMT
> I've noticed that in the example message > flow in RFC 3856, the 200 response for the > SUBSRIBE does not contain "Event:" header. > > In the last draft before changing status to RFC > (draft-ietf-simple-presence-10) this header appeared. > > > > Can anyone tell me the reason for this change? Per RFC 3265, the Event header is not present within responses.
RSS Feed