Or more precisely:
http://lmgtfy.com/?q=sip+communicator+download
Alex Balashov wrote:
> Fail.
>
> romal patel wrote:
>
>> Hi,
>>
>> I want to get source code of sip communicator.
>>
>> Please help me my friend.
>>
>> Regards,
>>
>> Romal Patel
>> __
Fail.
romal patel wrote:
> Hi,
>
> I want to get source code of sip communicator.
>
> Please help me my friend.
>
> Regards,
>
> Romal Patel
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.e
Hi,
I want to get source code of sip communicator.
Please help me my friend.
Regards,
Romal Patel
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
On Mon, Apr 20, 2009 at 3:29 PM, Kevin Spencer
wrote:
> Dave,
> Thanks, thats clear from the point of view of the arbitrary binary body.
> Vikram,
> But in the case where no offer is made in the initial INVITE surely there is
> no need to indicate a content-type at that stage (it may not be known
El Martes, 21 de Abril de 2009, Attila Sipos escribió:
> the presence of rport means definitely symmetric.
> the lack of it means you can't tell
>
> Anyway, You can try forcing rport and it might work.
> If you don't force rport, it won't work in a lot of cases too.
> In the real world, forcing rpo
El Martes, 21 de Abril de 2009, Vikram Chhibber escribió:
> Yes, in all these cases, the R-URI should be considered for
> identifying the target resource, but I am not sure what the "To
> header" is doing in RFC 3842 as pointed out by Brett.
>
>If the Request-URI or To header in a message-summa
>>Why do you afirm that the UAC demans it?
because Ranga said:
>>However, a JAIN-SIP user brought up that his UAC does not function
>>unless I add an rport to the via header of the response regardless of
>>whether the inbound request has an rport prameter.
it's not clear - the text seems to jus
Yes, in all these cases, the R-URI should be considered for
identifying the target resource, but I am not sure what the "To
header" is doing in RFC 3842 as pointed out by Brett.
If the Request-URI or To header in a message-summary subscription
corresponds to a group or collection of individu
Dave,
Thanks, thats clear from the point of view of the arbitrary binary body.
Vikram,
But in the case where no offer is made in the initial INVITE surely there is
no need to indicate a content-type at that stage (it may not be known at
that point?), for example the "Session via Redirect and Proxy
El Martes, 21 de Abril de 2009, Brett Tate escribió:
> My specific questions are how to interpret the following upon receipt of
> SUBSCRIBE at example.com (notifier) where user1, group1, and known-user are
> known and unknown-user is unknown at example.com.
>
> 1) To: us...@example.com and request-
Greetings,
RFC 3842 briefly discusses both request-uri and To. However I'm not sure how
to interpret meaning of request-uri as it relates to the To header.
The examples reflect the request-uri being the account (i.e. subscribe's
request-uri is same as notify's message-account); however the not
On Mon, 2009-04-20 at 16:21 +0100, Kevin Spencer wrote:
> Does anyone have any suggestions as to under what circumstances you would
> consider including a Content-Type: header when your Content-Length: is zero?
> 3261 gives the following example in section 20.15:
I don't know of any current applic
On Sun, 2009-04-19 at 14:00 +0530, Ashwath Kumar wrote:
> These two are distinguised by only one parameter that is
> branch=z9hG4bK-22034-1-1
> in via header.
>
> Now how the proxy will consider this ?
> Will Proxy treat it as loop ?
> or will it treat as an INVITE from some other UA , as in case
In general, the best analysis that has been done in RFC 5057.
On Fri, 2009-04-17 at 10:06 +0100, Attila Sipos wrote:
> Questions on some strange multiple dialog possibilities...
>
> Scenario 1
> --
>
> INVITE/OK/ACK> - INVITE creates dialog1
> SUBSCRIBE/OK-
El Lunes, 20 de Abril de 2009, Attila Sipos escribió:
> What I don't understand is that the UAC in question isn't stating rport
> support but demands it anyway!! That's nonsensical.
Why do you afirm that the UAC demans it?
What I think is that the UA uses symmetric SIP but doesn't implement the
Answering myself:
ReTurn states to be RFC 5389 compliant.
http://www.resiprocate.org/ReTurn_Overview
regards
klaus
Klaus Darilion schrieb:
> Hi!
>
> Are there any open source STUN server which support RFC 5389?
>
> I only know stund (sourceforge) and mystun (berlios), but they are
> rather
You will carry Conent-Type with 0 Content-Length when you say "I am
carrying 0 length XYZ Content-Type", which is different then saying "I
am carrying no body with an type". Typical scenario would be INVITE
without offer sdp. You still need to have Conent-Type as
"application/sdp". If you remove Co
Sanjay is absolutely right. But I would like to add below for
consideration while using UPDATE instead of re-INVITE
RFC-3311
5.1 Sending an UPDATE
The UPDATE request is constructed as would any other request within
an existing dialog, as described in Section 12.2.1 of RFC 3261. It
MAY b
IMHO,
Going by the reference in Section 16.3 Page -95 as listed below
4. Optional Loop Detection check
An element MAY check for forwarding loops before forwarding a
request. If the request contains a Via header field with a sent-
by value that equals a value placed into pre
Hi,
Does anyone have any suggestions as to under what circumstances you would
consider including a Content-Type: header when your Content-Length: is zero?
3261 gives the following example in section 20.15:
"If the body is empty, and a Content-Type header field is present, it
indicates that the bod
>>Because rport should be included in original RFC 3261, in fact,
>>it shouldn't exist, and "received" parameter should also append
>>the received port.
Just to clarify - the above is not reality - it shouldn't be implemented.
It is just an opinion on what could've been (I agree but...)
What I d
2009/4/20 Attila Sipos :
> If the rport is important to the UAC, it should signify this by
> including rport in its via.
> Why doesn't his UAC just add an rport in its request?
Because rport should be included in original RFC 3261, in fact, it
shouldn't exist, and "received" parameter should also
>> The question I have is what is the UAS supposed to do when the
inbound
>>request does NOT have an rport parameter? Is it legal ( or illegal )
>>to attach an rport parameter in the response when the request does
not have it?
It's technically illegal.
If a UAC receives the rport when it didn't
Hello,
>From RFC 3581 :
If this Via header field value contains an "rport" parameter
with no value, it MUST set the value of the parameter to the source
port of the request. This is analogous to the way in which a server
will insert the "received" parameter into the topmost Via header
Hi Vipul
Check this I-D :
http://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic
-icb-00 . Here I try to address this issue by proposing a new SIP Reason
header protocol value to be included in outgoing BYE message to indicate
to SIP server that the call is unwanted and the calle
First there should be checked if the call is malicious. If checked an confirmed
malicious, "403 Forbidden" should be a good response.
Acoording to the draft-kuthan-sip-derive-00. If a caller could not be verified
correctly "434 Suspicious call" should be send. Based on verified identity a
call
2009/4/20 Rastogi, Vipul (Vipul) :
> In case, called party (SIP endpoint) identifies, that current active
> call is malicious, what message should it's B2Bua send to caller party
> side (assuming to SIP end-point) ?
The first question I'd do is: how does the called party inform its
B2BUA about tha
Hi everybody,
I need some information about wireless mesh network support by SIP,
1-can we handle network establishing if every node in network is a
cell phone? due to sip proxy server processing consume.
2- How amount of processing does SIP proxy server consume?
___
In case, called party (SIP endpoint) identifies, that current active
call is malicious, what message should it's B2Bua send to caller party
side (assuming to SIP end-point) ?
Also for next call from same caller (to same called party), what failure
error code be send back.
Thanks,
Vipul
___
29 matches
Mail list logo
